Variables:
<Topic>: feature, workflow, module, or behavior to investigate.<Expectation>: optional expected behavior or understanding to validate against.
Investigate <Topic> in the repository and produce a grounded current-state report.
If <Expectation> is provided, explicitly compare the observed implementation against it and call out matches, mismatches, and unresolved areas.
Objectives
- Determine the current implementation status of
<Topic>.
- Trace the main code paths, data flow, configuration, and relevant tests.
- Identify whether the feature is implemented, partial, stubbed, deprecated, broken, or inconsistent.
- Compare the actual implementation to
<Expectation> if provided.
- Produce a concise evidence-based report that another engineer can trust without relying on chat history.
Operating rules
- Inspect code, tests, docs, configs, and relevant history indicators before concluding.
- Ground every important claim in repository evidence.
- Prefer direct code evidence over comments or outdated docs when they disagree.
- Distinguish clearly between:
- confirmed behavior
- likely behavior inferred from code structure
- missing evidence / unknowns
- Trace the end-to-end path when relevant:
- entry points
- domain logic
- persistence
- API surface
- UI integration
- configuration / feature flags
- tests
- Do not propose redesigns unless asked. Focus first on what exists today.
- Call out stale docs, dead code, partial migrations, feature flags, TODOs, and test gaps.
Investigation checklist
For the topic under investigation, inspect as relevant:
- entry points and callers
- core implementation files
- domain/model logic
- API handlers or controllers
- UI or client integration
- persistence/schema/migrations
- config, env vars, and feature flags
- tests and fixtures
- docs, ADRs, and backlog references
Required output
Produce a report with these sections:
Conclusion
- current status in 3-6 bullets
What exists today
- what is implemented
- where it lives
- how it is wired together
Comparison against expectation
- matches
- mismatches
- ambiguous / unverified points
Evidence
- relevant files and symbols
- short explanation of what each proves
Gaps and risks
- missing behavior
- stale docs
- test gaps
- partial or fragile implementation areas
Open questions
- only questions that could not be resolved from the repo
Quality bar
- Do not say a feature is implemented unless code paths and integration evidence support it.
- Do not say a feature is missing if partial support exists; describe the actual boundary precisely.
- Do not rely on a single file when the behavior spans multiple layers.
- Be explicit when a conclusion is an inference rather than directly proven.
1---2name: investigate3description: Investigates the current implementation state of a feature, traces how it works in code and docs, and compares findings against an expected understanding.4---56Variables:7- `<Topic>`: feature, workflow, module, or behavior to investigate.8- `<Expectation>`: optional expected behavior or understanding to validate against.910Investigate `<Topic>` in the repository and produce a grounded current-state report.1112If `<Expectation>` is provided, explicitly compare the observed implementation against it and call out matches, mismatches, and unresolved areas.1314## Objectives15161. Determine the current implementation status of `<Topic>`.172. Trace the main code paths, data flow, configuration, and relevant tests.183. Identify whether the feature is implemented, partial, stubbed, deprecated, broken, or inconsistent.194. Compare the actual implementation to `<Expectation>` if provided.205. Produce a concise evidence-based report that another engineer can trust without relying on chat history.2122## Operating rules23241. Inspect code, tests, docs, configs, and relevant history indicators before concluding.252. Ground every important claim in repository evidence.263. Prefer direct code evidence over comments or outdated docs when they disagree.274. Distinguish clearly between:28 - confirmed behavior29 - likely behavior inferred from code structure30 - missing evidence / unknowns315. Trace the end-to-end path when relevant:32 - entry points33 - domain logic34 - persistence35 - API surface36 - UI integration37 - configuration / feature flags38 - tests396. Do not propose redesigns unless asked. Focus first on what exists today.407. Call out stale docs, dead code, partial migrations, feature flags, TODOs, and test gaps.4142## Investigation checklist4344For the topic under investigation, inspect as relevant:45- entry points and callers46- core implementation files47- domain/model logic48- API handlers or controllers49- UI or client integration50- persistence/schema/migrations51- config, env vars, and feature flags52- tests and fixtures53- docs, ADRs, and backlog references5455## Required output5657Produce a report with these sections:58591. **Conclusion**60 - current status in 3-6 bullets61622. **What exists today**63 - what is implemented64 - where it lives65 - how it is wired together66673. **Comparison against expectation**68 - matches69 - mismatches70 - ambiguous / unverified points71724. **Evidence**73 - relevant files and symbols74 - short explanation of what each proves75765. **Gaps and risks**77 - missing behavior78 - stale docs79 - test gaps80 - partial or fragile implementation areas81826. **Open questions**83 - only questions that could not be resolved from the repo8485## Quality bar8687- Do not say a feature is implemented unless code paths and integration evidence support it.88- Do not say a feature is missing if partial support exists; describe the actual boundary precisely.89- Do not rely on a single file when the behavior spans multiple layers.90- Be explicit when a conclusion is an inference rather than directly proven.
joheredi