Interview the user one question at a time until the plan, terminology, and important decisions are clear enough to act on.
Workflow
- Read the user's plan, linked docs, code, or local files needed to understand the topic.
- Look for existing
CONTEXT.md,CONTEXT-MAP.md, anddocs/adr/files before proposing new docs. - Ask one focused question at a time. Wait for the answer before continuing.
- If the answer can be discovered from the codebase or existing docs, inspect those instead of asking.
- For each question, include your recommended answer or likely tradeoff so the user can accept, reject, or refine it.
- Push on fuzzy words, hidden assumptions, edge cases, dependencies between decisions, and reversibility.
- When terminology is resolved, update the appropriate
CONTEXT.mdimmediately. - Offer an ADR only for decisions that are hard to reverse, surprising without context, and based on a real tradeoff.
Documentation Rules
CONTEXT.mdis a glossary and relationship map for project-specific language, not a spec or scratchpad.- Use
CONTEXT-MAP.mdonly when the repository has multiple bounded contexts. - Create documentation lazily: do not add
CONTEXT.mdordocs/adr/until there is real resolved content. - Keep docs concise enough that future agents will actually read them.
For glossary format, read CONTEXT-FORMAT.md. For ADR format and thresholds, read ADR-FORMAT.md.
Question Patterns
- "What outcome would make this change a success?"
- "Which existing concept owns this behavior?"
- "What is the smallest scenario that proves the design works?"
- "What breaks if this assumption is false?"
- "What would a future maintainer be tempted to change back?"
- "Which term should be canonical, and which aliases should be avoided?"