להבין קוד שלא אתם כתבתם

כשנכנסים לפרויקט קיים, השאלה אינה מה כל פונקציה עושה אלא איפה נמצא הלב, מה זורם לאן, ומה ישבור דברים אם ייגעו בו. הפרומפט הזה מבקש בדיוק את השלושה האלה, וגם מבקש לסמן את מה שנראה כמו החלטה מכוונת שאסור לבטל בלי להבין. הפרומפט כתוב באנגלית ומוכן להעתקה, מתוך ספריית הפרומפטים של כליקס. מה שבסוגריים מרובעים הוא מה שאתם ממלאים לפני ההדבקה. עדיף כלי עם גישה לקבצים. הדבקה של קבצים בודדים תיתן תמונה חלקית.

קוד ומפתחים · קוד · הבנה · פרויקט · onboarding

I need to understand this codebase well enough to make a change safely. I did not write it.

[point at the repository, or paste the key files]

Give me:

1. The one-paragraph story: what this project does, for whom, and what the main flow is from entry point to output.

2. The map: the five to eight files that matter most, and one line each on what they own. Ignore config, generated files, and boilerplate.

3. The data flow for the main use case: what enters, what transforms it, where state lives, and what leaves.

4. Danger zones: what is easy to break from the outside. Shared state, implicit ordering, things that look duplicated but are not, and anything where a small change has wide blast radius.

5. Deliberate decisions: places where the code looks odd but seems intentional. Quote the comment or the evidence. I want to know what not to "clean up".

6. What I should read first if I have twenty minutes.

Rules:
- Do not summarize every file. I want the shape, not an index.
- If something is unclear from the code alone, say so instead of inferring intent.
- Point to actual file paths and line numbers so I can verify each claim.

איך להשתמש בזה נכון