repository-discoverylisted

# Repository Discovery ## Purpose Understand the real codebase before proposing material changes. Build the **smallest useful repository map** that explains where the requested behavior lives, how nearby code is structured, how it is tested, and which local constraints must be preserved. This is brownfield discovery, not a request to read the whole repository. ## When to use Use this capability when: - implementing or debugging behavior in a repository you do not already understand; - the task may cross package, service, data, build, or deployment boundaries; - the user points to an outcome but not the responsible files; - repository conventions or existing patterns should determine the implementation approach. Keep it lightweight when the change is obviously local and the responsible code, tests, and conventions are already known. ## Core principle **Repository reality outranks generic preference.** Do not prescribe a new framework, folder structure, library, abstraction, or testing style until you have checked what the project already uses and whether it can satisfy the task. ## Method ### 1. Establish the task boundary Restate the requested outcome in one or two sentences. Separate: - what the user explicitly wants changed; - what must remain unchanged; - any named files, modules, services, routes, screens, commands, or data involved. Do not turn discovery into product requirements analysis. Hand unresolved behavior questions to `requirements-to-acceptance`