# plan

Two modes — offer the choice up front unless the user already picked:

• grill — interview first, then write the plan. Right when the idea is fuzzy, decisions are unresolved, or the user wants their thinking stress-tested.
• trust — no questions. Synthesize from the conversation and codebase and deliver. Right when the context is already rich or the user wants speed.

If unstated, recommend one based on how much context exists, in one line: "Context is thin — I'd grill; say trust to skip the questions."

The knowledge base

Planning compounds when decisions and language outlive the session. Two files carry that:

• docs/CONTEXT.md — the domain glossary: one term per concept, a one-line definition each, no implementation details. Read it before planning; it's the project's language.
• docs/adr/NNNN-<slug>.md — decision records: context, the decision, why, what was rejected. Read the ones in the area you're touching; they are settled — don't re-litigate them, plan within them.

Create both lazily — only when there's something to write. Update them inline as decisions crystallize, not as a batch at the end.

Offer an ADR only when all three hold: the decision is hard to reverse, would be surprising without context, and resolved a real trade-off. Anything less belongs in the PRD's Decisions section, not an ADR.