domain-model

> Legacy: prefer `/grill-with-docs`. Keep only for backward compatibility with local three-hat workflow. # Domain Model Grill + document. Three-hat adversarial review PLUS institutional memory captured inline as CONTEXT.md + ADRs. ## Step 1: Interview Walk every branch of decision tree. Resolve dependencies one-by-one. Each question, give recommended answer. One at time. If question answerable by exploring codebase, explore first. ## Light DDD -- Document, Don't Prescribe USE: Ubiquitous Language | Bounded Contexts | ADRs SKIP: Entities | Value Objects | Aggregates | Domain Events Goal = "just enough docs" make codebase navigable. Language into software, not patterns into software. ## Domain Awareness During codebase exploration, look for existing docs: ### Single context (most repos) / ├── CONTEXT.md ├── docs/adr/ │ ├── 0001-event-sourced-orders.md │ └── 0002-postgres-for-write-model.md └── src/ ### Multi-context (if CONTEXT-MAP.md exists at root) / ├── CONTEXT-MAP.md ├── docs/adr/ <- system-wide decisions ├── src/ │ ├── ordering/ │ │ ├── CONTEXT.md │ │ └── docs/adr/ <- context-specific decisions │ └── billing/ │ ├── CONTEXT.md │ └── docs/adr/ Create files lazy -- only when first term resolved or first ADR needed. ## Step 2: Domain Grill **Challenge glossary**: Term conflict with CONTEXT.md? Call out now. **Sharpen language**: Vague or overloaded term? Propose precise canonical term. "You say 'account' -- Customer or User? Different things." **Concrete scenarios**: Stress-test relationships with edge cases. Force precision on boundaries. **Cross-reference code**: User state how something works -> verify code agrees. Surface contradictions. ## Step 3: Three-Hat Fan-Out (parallel) Once user present coherent plan + terms resolved, spawn three reviewers **in parallel** (single message, multiple Agent tool calls): - **`plan-product-hat`**: persona, pain, success metric, scope, reversibility, TTV - **`plan-engineering-hat`**: architecture, error paths, perf, security, test strategy, rollback - **`plan-design-hat`**: flow, a11y, copy, visual consistency, states (empty/loading/error) Each emit `{reviewer, status, findings[], must_answer[]}` per findings-schema.md. ## Step 4: Merge + Document Consolidate all `must_answer` questions into single list, deduped. Surface to user. User answer each. Plan updated inline. **Update CONTEXT.md inline**: Term resolved or scope clarified -> update now. No batch. See [CONTEXT-FORMAT.md](CONTEXT-FORMAT.md). **Offer ADRs sparingly**: Only when ALL three true: hard reverse, surprising without context, result of real trade-off. See [ADR-FORMAT.md](ADR-FORMAT.md). Any reviewer return `status: BLOCKED` -> plan no advance until blocking finding addressed or user override. ## Step 5: Approve All hats return `APPROVED` or user override specific findings -> plan approved -> Phase 3 (Implement). ## Skip Gate Skip three-hat fan-out only if: - Trivial bug fix, AND - <3 tasks in plan, AND - No architectural / product / UX decisions Else, fan-out mandatory. For a light grill without DDD docs, use `/grill-me` instead.