45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
# Repository Exploration
|
|
|
|
## Purpose
|
|
|
|
Rapidly build accurate context before implementation, debugging, or planning by identifying the right files, flows, conventions, and constraints in the repository.
|
|
|
|
## When to use
|
|
|
|
- Starting in an unfamiliar repository
|
|
- Locating the right implementation area for a request
|
|
- Understanding current architecture before proposing changes
|
|
- Reducing ambiguity in a vague task
|
|
|
|
## Inputs to gather
|
|
|
|
- Repository layout, entrypoints, and key modules
|
|
- Build, test, and dependency configuration
|
|
- Existing patterns for similar features or workflows
|
|
- Any local instructions, docs, or conventions already in the repo
|
|
|
|
## How to work
|
|
|
|
- Start broad, then narrow quickly to the files and flows relevant to the task.
|
|
- Favor authoritative sources in the repo such as configs, types, interfaces, docs, and existing implementations.
|
|
- Identify where decisions are already made by the codebase so you do not reinvent them.
|
|
- Summarize findings in terms of how they affect the next action.
|
|
- Stop exploring once the path to execution is clear enough.
|
|
|
|
## Output expectations
|
|
|
|
- Concise map of the relevant code paths and conventions
|
|
- Recommended starting points for changes or further investigation
|
|
- Key unknowns that still require validation
|
|
|
|
## Quality checklist
|
|
|
|
- Exploration answers practical implementation questions rather than producing generic architecture prose.
|
|
- Findings are tied to concrete files, modules, or workflows.
|
|
- Enough context is gathered to act confidently without over-reading the entire repo.
|
|
|
|
## Handoff notes
|
|
|
|
- Mention the most relevant files, commands, and repo conventions discovered.
|
|
- Flag ambiguous areas where multiple plausible implementation paths exist.
|