Interrogate every aspect of the approach without leaving any corner untouched, walking through the design decision tree item by item until consensus is reached. As soon as a decision crystallizes during the interrogation, immediately capture it as a glossary entry and a decision record.
Before starting, first check whether there are existing materials: the root directory's CONTEXT.md or CONTEXT-MAP.md, as well as existing ADRs under docs/adr/ . If there are, read them, and use them to know which concepts and decisions have already been settled.
| Reference | When to read |
|---|---|
| references/context-md.md | When the first term is settled and it is time to actually write it into CONTEXT.md ; or when you need to determine whether the structure is single-context or multi-context |
| references/adr.md | When a decision has passed the three thresholds below and it is time to put pen to paper and write an ADR |
Core rules
Ask only one question at a time, and wait for the reply before asking the next. Throwing out multiple questions at once leaves people at a loss. For each question, give your recommended answer.
For facts that can be looked up from the codebase, look them up directly; do not ask. But the decision-making authority rests with the user — raise every decision and wait for the answer.
Do not begin executing the approach until the user has explicitly confirmed that consensus has been reached.
Actions during interrogation
Challenge against the glossary. When the user's wording conflicts with the definitions in CONTEXT.md , point it out immediately: "Your glossary defines 'cancel' as X, but what you seem to mean now is Y — which one is it?"
Sharpen vague expressions. When you encounter a vague or ambiguous word, propose a precise canonical term: "By 'account' you mean — is that Customer or User? These are two different concepts."
Stress-test with concrete scenarios. When discussing domain relationships, construct boundary scenarios to force out the precise boundaries between concepts.
Cross-validate with the code. When the user states how something works, go look at the code to see whether it is consistent, and expose any contradiction immediately: "Your code cancels the entire Order, but you just said partial cancellation is possible — which is right?"
Write immediately, do not batch up. As soon as a term is settled, update CONTEXT.md. Lazy creation: if the file does not exist, create it when the first term is determined.
ADR thresholds
Write an ADR only when all three hold:
- Hard to reverse — the cost of changing your mind in the future is substantial
- Confusing without context — future readers will be puzzled: "Why was it done this way?"
- Genuinely the result of a trade-off — real alternatives existed, and one was chosen for specific reasons