interrogate-plan

name	interrogate-plan
description	Interrogation session that challenges a spec or plan against the codebase and existing domain model, sharpens terminology, and updates the plan and project context (CONTEXT.md, AGENTS.md, README.md, ADRs) inline as decisions crystallise. Use when the maintainer wants to stress-test a plan against their project's language and documented decisions.

Interview me about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions. For each question, provide your recommended answer.

Ask 1-3 questions at a time with the system's "ask user questions" tool (if available), waiting for feedback on each question before continuing.

• If a question can be answered by exploring the codebase, explore the codebase instead.
• Do not waste time with trivial or unimportant questions. Focus on the critical path of the design.
• Provide the maintainer with a sense of progress so the process doesnt feel open-ended and never-ending.
• General rubric: more than 20 questions is likely too many; fewer than 10 is likely too few.

Domain awareness

During codebase exploration, also look for existing documentation:

File structure

Most repos have a single context:

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

If a CONTEXT-MAP.md exists at the root, the repo has multiple contexts. The map points to where each one lives:

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

Create files lazily — only when you have something to write. If no CONTEXT.md exists, create one when the first term is resolved. If no exists, create it when the first ADR is needed.