grill-with-docs

name grill-with-docs description Grilling interview that stress-tests a plan against the project's existing domain language and documented decisions, sharpening terminology and updating CONTEXT.md and ADRs inline as decisions crystallise. Use when user says "grill me with docs", "grill on the design", "challenge this against our context", or invokes /grill-with-docs. Purpose Drive a relentless interview that challenges the user's plan against the project's existing domain model: the glossary in CONTEXT.md and the architectural decisions in docs/adr/ . Sharpen fuzzy terms, surface contradictions between the plan and the code, and update the docs inline as terms and decisions resolve — capturing them as they happen, not in a batch at the end. Workflow Locate the Domain Documentation Look at the repo root and the area being discussed for existing docs IF: CONTEXT-MAP.md exists at the root → the repo has multiple contexts; read the map to find which context the topic belongs to IF: only a root CONTEXT.md exists → single-context repo, use it IF: neither exists → no docs yet; create them lazily later (only when the first term or decision crystallises) Also look for docs/adr/ to see what decisions are already recorded Expected layout for a single-context repo: / ├── CONTEXT.md ├── docs/ │ └── adr/ │ ├── 0001-event-sourced-orders.md │ └── 0002-postgres-for-write-model.md └── src/ Expected layout for a multi-context repo (decisions live per-context, system-wide decisions live at the root): / ├── CONTEXT-MAP.md ├── docs/adr/ ← system-wide decisions ├── src/ │ ├── ordering/ │ │ ├── CONTEXT.md │ │ └── docs/adr/ ← context-specific decisions │ └── billing/ │ ├── CONTEXT.md │ └── docs/adr/ IF: multiple contexts exist and the relevant one is unclear → ask the user which context the topic belongs to Interview One Question at a Time Walk each branch of the design tree, resolving dependencies between decisions one by one Exactly one question per turn — never batch Pair each question with your recommended answer so the user can react quickly Wait for the user's reply before moving on IF: a question can be answered by exploring the codebase → explore the code instead of asking the user, then report the finding Example: "I see OrderService.cancel() deletes the row outright. My recommended answer: cancellation is a hard delete. Is that what you mean, or do you want a soft cancelled state?" Challenge Against the Glossary When the user uses a term that conflicts with the existing language in CONTEXT.md , call it out immediately Quote the existing definition and ask which meaning they intend Example: "Your glossary defines 'cancellation' as removing the order from the queue, but you seem to mean refunding a paid order. Which is it — and should the glossary entry change?" Sharpen Fuzzy Language When the user uses vague or overloaded terms, propose a precise canonical term Make the alternatives explicit so the user can pick Example: "You're saying 'account' — do you mean the Customer (a person who places orders) or the User (a login identity)? Those are different things in your domain." Stress-Test With Concrete Scenarios When domain relationships are being discussed, invent specific scenarios that probe edge cases and force precision about the boundaries between concepts Use scenarios to surface assumptions the user hasn't articulated yet Example: "Say a customer cancels half an order after one item has shipped. Is that one Order in two states, or two Orders? Your answer will dictate the cancellation model." Cross-Reference With Code When the user states how something works, check whether the code agrees IF: you find a contradiction between the stated plan and the actual code → surface it directly Example: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?" Update CONTEXT.md Inline When a Term Resolves When a term is resolved, update CONTEXT.md right there in the same turn — do not batch these up IF: CONTEXT.md does not exist yet → create it lazily the moment the first term resolves IF: multi-context repo → write to the CONTEXT.md of the relevant context, not the root Format: see ./references/CONTEXT-FORMAT.md Hard rule : CONTEXT.md is a glossary and nothing else. It must be totally devoid of implementation details. Do not treat it as a spec, a scratch pad, or a repository for implementation decisions. Example: User confirms "Customer = person or org that places orders; Client and Buyer are aliases to avoid." → immediately add a **Customer** entry to CONTEXT.md with that definition and the avoided aliases. Offer ADRs Only When All Three Tests Pass Only offer to create an ADR when ALL of the following are true: Hard to reverse — the cost of changing your mind later is meaningful Surprising without context — a future reader will wonder "why did they do it this way?" The result of a real trade-off — there were genuine alternatives and you picked one for specific reasons IF: any one of the three is missing → skip the ADR IF: an ADR is warranted and docs/adr/ does not exist → create the directory lazily, scan for the highest existing number, and use the next one Format and numbering: see ./references/ADR-FORMAT.md Example: User decides to use event sourcing for the write model. All three tests pass (hard to reverse, surprising, real trade-off vs. CRUD) → offer to create docs/adr/0003-event-sourced-write-model.md . Example: User decides to name a variable customerId instead of userId . Easy to reverse and not surprising → skip the ADR; this is a glossary concern, not an ADR concern. References CONTEXT.md format and rules IF: writing or updating a CONTEXT.md entry, deciding what belongs in the glossary vs. an ADR, or working out the structure of a multi-context repo THEN: Read ./references/CONTEXT-FORMAT.md EXAMPLES: "what does a CONTEXT.md entry look like?" "single context or multi-context — how do I tell?" "should this term go in the glossary?" ADR format and when to record IF: deciding whether a decision deserves an ADR, drafting an ADR, or numbering a new one THEN: Read ./references/ADR-FORMAT.md EXAMPLES: "is this decision ADR-worthy?" "what sections does an ADR need?" "what number should this ADR be?" Works well with Optional collaborators — grill-with-docs runs standalone and these degrade gracefully if absent. grill-me — the plain interview without the docs layer; use that when the project has no CONTEXT.md /ADRs to sharpen against. setup-toolbox-context — scaffolds the CONTEXT.md and docs/adr/ this skill reads and writes; run it first on a new project. living-plan — this skill writes the ADRs; a living plan then links them as back-references and speaks the same CONTEXT.md vocabulary. tdd / improve-codebase-architecture — both consume the CONTEXT.md glossary and ADRs this skill produces.