---
name: grill-docs
description: >-
  Docs-aware grilling: interrogates the user's plan one question at a time AND
  maintains the domain glossary (CONTEXT.md) and architecture decision records
  (docs/adr/) inline as decisions crystallise. Used to stress-test a plan
  against the project's language and documented decisions; for a plain interview
  that writes no files, use grill. Activates when the user writes "grill-docs",
  "grill with docs", "grill and update the glossary", "grill and write ADRs",
  "stress-test against CONTEXT.md", "challenge my plan and capture decisions".
---

# Grill with docs

<what-to-do>

Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.

Use pi's `ask_user` tool for every user-facing question. Ask **one question at a time**, wait for the answer, and then continue. A later question usually depends on an earlier answer — resolve the branch in order, don't batch unrelated questions.

Each `ask_user` call should include:

```js
ask_user({
  question: "The single focused question to answer",
  context: "Short summary of known facts, glossary/ADR context, and why this decision matters.",
  options: [
    { title: "(Recommended) ...", description: "One-line rationale." },
    { title: "Alternative ...", description: "When this is better." },
  ],
  allowFreeform: true,
});
```

Use 2–4 options. Put the recommended answer first, labelled `(Recommended)`, and keep free-form input enabled.

If a question can be answered by exploring the codebase, explore the codebase instead.

The user input after `/skill:grill-docs` is the plan, design, or topic to grill. If it is empty, ask with `ask_user` what they want to be grilled on.

</what-to-do>

<supporting-info>

## Domain awareness

During codebase exploration, also look for existing documentation:

### File structure

Most repos have a single context:

```
/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/
```

If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:

```
/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/
```

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.

## 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 immediately. "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 scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.

### Cross-reference with code

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?"

### Update CONTEXT.md inline

When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [reference/CONTEXT-FORMAT.md](reference/CONTEXT-FORMAT.md).

`CONTEXT.md` should be devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.

### Offer ADRs sparingly

Only offer to create an ADR when all three are true:

1. **Hard to reverse** — the cost of changing your mind later is meaningful
2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons

If any of the three is missing, skip the ADR. Use the format in [reference/ADR-FORMAT.md](reference/ADR-FORMAT.md).

</supporting-info>

## Rules

- One `ask_user` call per question. Wait for the answer before moving on.
- Every question offers a recommended answer, listed first; the user may answer free-form.
- Capture terminology in `CONTEXT.md` and decisions in ADRs inline, lazily — create files only when there is something to write.
- End the session by summarising the resolved decisions and confirming what was written to `CONTEXT.md` and `docs/adr/`.
- For a plain interview without documentation maintenance, use `/skill:grill`.
- Language: match the user's language, or follow the project-level definition in `AGENTS.md` / `CLAUDE.md` when present.