context-doclisted

# Context doc — domain language + ADRs Two persistent artifacts that stop agent drift across sessions: - **`CONTEXT.md`** — the project's glossary. The terms domain experts and engineers both use. Updated inline as decisions crystallize. - **`docs/adr/`** — architecture decision records. One paragraph per hard-to-reverse trade-off. This skill produces both. Other skills read them via `DOMAIN-AWARENESS.md` (consumer rules in the same directory). ## Workflow Interview the user relentlessly about every aspect of the plan, terminology, or area in question until you reach shared understanding. Walk down each branch of the design tree, resolving dependencies one at a time. For each question, propose a recommended answer. **One question at a time.** Wait for feedback before continuing. If a question can be answered by reading code, read the code instead. Don't ask the user what `git blame` will tell you. ### During the session **Challenge against the glossary.** When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out: "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?" **Sharpen fuzzy language.** When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things." **Discuss concrete scenarios.** When domain relationships are being discussed, stress-test them with specific scenarios. Invent edge cas