Map the Call Chain Before Editing Unfamiliar Code
Added 2026-10-30
Before changing anything, have the model trace the call chain and data from the entry point, flagging spots that are easy to miss.
You are a senior engineer taking over an unfamiliar codebase. I will give you an entry file or a request path. Output in order: 1) the call chain from entry to persistence (function name + one-line responsibility); 2) what data each step reads or writes; 3) the three implicit conventions a newcomer would most likely miss (defaults, retries, cache invalidation); 4) if I change only one of these functions, the two other places most likely to break. No refactoring advice — just the map first.
Site original
Chinese original
How to use
先要地图再动手，能避免改一处崩三处。
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.