Know the repository before the change.
A file tree is a starting point, not an explanation of a system. Ask your coding assistant to trace one real request from its entry point through the relevant modules. The resulting map should say what each boundary owns and where the evidence lives.
Trace one path
Choose a representative operation: loading an account, saving a document, or running a build. Identify its entry point, configuration, implementation, and closest tests. Record file paths and symbol names so another person can inspect the same evidence. Separate application code from generated output.
Mark what is unknown
Configuration loaded at runtime may change the apparent route. List missing environment values by name without copying secrets. Flag unavailable services and code you have not inspected. A useful map makes uncertainty visible instead of describing every folder with equal confidence.
Checkpoint
- Entry point and owning module identified
- Generated and vendored paths marked
- Closest meaningful test located
Read-only transmission
Read only. Trace how this repository handles [operation]. Cite file paths and symbols. Identify configuration dependencies, generated files, and the closest test. Separate observed facts from open questions. Do not edit files.
Refresh the map when the branch or checkout changes. A map belongs to a particular repository state; it is not permanent documentation by default.
Next: Remote context