Repository Inspection
Definition
Build a clean map of the current project before changing it. Treat existing code as the primary source for architecture, vocabulary, dependency direction, tests, and conventions.
Questions To Ask
- What feature or bug is being delivered?
- Which documents describe the intended outcome?
- What entry points, modules, routes, commands, jobs, or screens already own related behavior?
- What tests or manual checks currently cover the area?
- Are there uncommitted changes, and which appear unrelated to this task?
Existing Project Comparison
- Inspect the file tree, package scripts, framework conventions, and domain folders.
- Compare
AGENT_GUARDRAILS.md, FEATURE_MAP.md, and FEATURE_DESIGN.md against current files when they exist.
- Identify deep modules, shallow modules, information leakage, pass-through layers, repeated logic, vague names, and hidden dependencies.
- Record the smallest owner area where the feature should land.
Suggestive Plan
- Read the request and any durable planning documents.
- Inspect project layout and likely entry points.
- Inspect related tests, fixtures, documentation, and config.
- Check current git state and mark unrelated changes.
- Write repository findings into
FEATURE_DELIVERY.md.
Example
For "add invoice resend", inspect billing routes, invoice service, notification jobs, email tests, API docs, and pending local changes before proposing edits.
Vocabulary
- Owner module: module responsible for a rule or behavior.
- Entry point: UI, API, command, job, or event handler that begins the feature.
- Information leakage: one design decision reflected across multiple modules.
- Unknown unknown: risk hidden because no inspected artifact reveals it yet.
Expected Outcome
Produce a repository map with relevant files, owner modules, current behavior, test coverage, documentation, git state, risks, and open questions.
1---2name: repository-inspection3description: Inspect an existing repository before implementing a feature. Use when a coding agent needs to understand project structure, current behavior, owner modules, tests, documentation, git state, and risk before planning code changes.4---56# Repository Inspection78## Definition910Build a clean map of the current project before changing it. Treat existing code as the primary source for architecture, vocabulary, dependency direction, tests, and conventions.1112## Questions To Ask1314- What feature or bug is being delivered?15- Which documents describe the intended outcome?16- What entry points, modules, routes, commands, jobs, or screens already own related behavior?17- What tests or manual checks currently cover the area?18- Are there uncommitted changes, and which appear unrelated to this task?1920## Existing Project Comparison2122- Inspect the file tree, package scripts, framework conventions, and domain folders.23- Compare `AGENT_GUARDRAILS.md`, `FEATURE_MAP.md`, and `FEATURE_DESIGN.md` against current files when they exist.24- Identify deep modules, shallow modules, information leakage, pass-through layers, repeated logic, vague names, and hidden dependencies.25- Record the smallest owner area where the feature should land.2627## Suggestive Plan28291. Read the request and any durable planning documents.302. Inspect project layout and likely entry points.313. Inspect related tests, fixtures, documentation, and config.324. Check current git state and mark unrelated changes.335. Write repository findings into `FEATURE_DELIVERY.md`.3435## Example3637For "add invoice resend", inspect billing routes, invoice service, notification jobs, email tests, API docs, and pending local changes before proposing edits.3839## Vocabulary4041- Owner module: module responsible for a rule or behavior.42- Entry point: UI, API, command, job, or event handler that begins the feature.43- Information leakage: one design decision reflected across multiple modules.44- Unknown unknown: risk hidden because no inspected artifact reveals it yet.4546## Expected Outcome4748Produce a repository map with relevant files, owner modules, current behavior, test coverage, documentation, git state, risks, and open questions.
harsh817