$npx -y skills add flutter/agent-plugins --skill grill-with-docsGrilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
| 1 | <what-to-do> |
| 2 | |
| 3 | Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. |
| 4 | |
| 5 | Ask the questions one at a time, waiting for feedback on each question before continuing. |
| 6 | |
| 7 | If a question can be answered by exploring the codebase, explore the codebase instead. |
| 8 | |
| 9 | </what-to-do> |
| 10 | |
| 11 | <supporting-info> |
| 12 | |
| 13 | ## Domain awareness |
| 14 | |
| 15 | During codebase exploration, also look for existing documentation: |
| 16 | |
| 17 | ### File structure |
| 18 | |
| 19 | Most repos have a single context: |
| 20 | |
| 21 | ``` |
| 22 | / |
| 23 | ├── CONTEXT.md |
| 24 | ├── docs/ |
| 25 | │ └── adr/ |
| 26 | │ ├── 0001-event-sourced-orders.md |
| 27 | │ └── 0002-postgres-for-write-model.md |
| 28 | └── src/ |
| 29 | ``` |
| 30 | |
| 31 | If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives: |
| 32 | |
| 33 | ``` |
| 34 | / |
| 35 | ├── CONTEXT-MAP.md |
| 36 | ├── docs/ |
| 37 | │ └── adr/ ← system-wide decisions |
| 38 | ├── src/ |
| 39 | │ ├── ordering/ |
| 40 | │ │ ├── CONTEXT.md |
| 41 | │ │ └── docs/adr/ ← context-specific decisions |
| 42 | │ └── billing/ |
| 43 | │ ├── CONTEXT.md |
| 44 | │ └── docs/adr/ |
| 45 | ``` |
| 46 | |
| 47 | Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed. |
| 48 | |
| 49 | ## During the session |
| 50 | |
| 51 | ### Challenge against the glossary |
| 52 | |
| 53 | When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?" |
| 54 | |
| 55 | ### Sharpen fuzzy language |
| 56 | |
| 57 | 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." |
| 58 | |
| 59 | ### Discuss concrete scenarios |
| 60 | |
| 61 | When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts. |
| 62 | |
| 63 | ### Cross-reference with code |
| 64 | |
| 65 | When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?" |
| 66 | |
| 67 | ### Update CONTEXT.md inline |
| 68 | |
| 69 | When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md). |
| 70 | |
| 71 | Don't couple `CONTEXT.md` to implementation details. Only include terms that are meaningful to domain experts. |
| 72 | |
| 73 | ### Offer ADRs sparingly |
| 74 | |
| 75 | Only offer to create an ADR when all three are true: |
| 76 | |
| 77 | 1. **Hard to reverse** — the cost of changing your mind later is meaningful |
| 78 | 2. **Surprising without context** — a future reader will wonder "why did they do it this way?" |
| 79 | 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons |
| 80 | |
| 81 | If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md). |
| 82 | |
| 83 | </supporting-info> |