Grill With Docs Requiem

---
name: grill-with-docs-requiem
description: A high-judgment design interview that sharpens plans in useful batches and records settled domain language and ADRs as the conversation progresses.
disable-model-invocation: true
---

# grill-with-docs-requiem

Run a Requiem interview: press the design hard enough to expose real decisions, but do not make the user pay for questions an expert can infer. Use `/domain-modeling` throughout. Do not inherit `/grilling`'s one-question-at-a-time cadence for this skill; this skill batches questions because it is also maintaining docs and domain language.

## Invalid Behavior

Do not outsource obvious judgment to the user. A question is invalid when the answer is already clear from the scene, the existing docs, the codebase, or basic product sense.

Invalid question patterns:

- Asking whether a selected character should duplicate in its original seat and the center spotlight when the user already said the character moves.
- Asking a naming question where one option is ambiguous and the other names the domain concept clearly.
- Asking one tiny fork at a time when the next five forks are independent and can be answered together.
- Asking for permission to create `CONTEXT.md` or an ADR after the skill rules already say when those files should be created.

## Operating Rule

Default to: "I lean toward X because Y. I am treating that as the working decision unless you correct it."

Ask only when the answer changes one of these:

- the domain model or ubiquitous language
- an ADR-worthy trade-off
- a player/user-facing behavior
- a data ownership boundary
- a risky implementation direction
- a scope boundary that would change what gets built

If the question would only confirm the obvious, infer the answer and keep moving.

## Question Tool Routing

When a real fork needs the user's answer, use the host's native question tool if one exists.

- Claude agents: use the `AskUserQuestion` tool.
- Any other agent with a native question or user-input tool: use that tool.
- If the tool supports multiple prompts, send the whole question batch in one call.
- If no native question tool exists, ask in prose using the batch shape below.

Do not use a question tool for inferred decisions. State the working decision and continue.

## Question Batches

Ask questions in sets of 3-7 when the answers can be considered independently. Keep each question short, but include the recommended answer and the reason it matters.

Use this shape:

```md
I am inferring these unless you correct me:

1. **{Decision name}**: I recommend {answer} because {reason}.
2. **{Decision name}**: I recommend {answer} because {reason}.

Real forks:

1. **{Decision name}**: I lean toward {answer} because {reason}. Is that the intended direction?
2. **{Decision name}**: I lean toward {answer} because {reason}. Is that the intended direction?
```

Do not ask more than 7 questions at once. If more forks exist, group them by theme and continue after the user answers the current batch.

## The Obviousness Gate

Before asking, run this check silently:

1. Can the codebase, existing docs, or user statement already answer it?
2. Is one answer clearly invalid, duplicative, impossible, or nonsense in the described product?
3. Would a competent product or domain designer infer the answer without bothering the user?
4. Would the answer fail to change docs, architecture, behavior, or scope?

If any answer is yes, do not ask. State the inference only if it helps the conversation or the docs.

## Domain Language

Names must be clear over terse. Do not suggest ambiguous ubiquitous-language terms just because they are shorter.

Good terms identify the thing at the level a future reader needs:

- **Saved Character Seat** is better than **Seat** when the concept is a persistent menu placement for a saved character.
- **Featured Mark** is better than **Center** when the concept is the presentation target for the selected character.
- **Featured Saved Character** is better than **Selected** when the concept is the saved character currently presented in the spotlight.

When proposing a glossary term:

- Name the concept, not the UI widget or implementation mechanism.
- Include `_Avoid_` terms for ambiguous alternatives.
- Reject names that could refer to multiple concepts in the same conversation.
- Prefer a longer precise term over a short term that future agents can misuse.

## Docs Cadence

Use the `/domain-modeling` skill's file rules and formats.

- Update `CONTEXT.md` immediately when a term is resolved.
- Create ADRs only for decisions that satisfy the ADR test: hard to reverse, surprising without context, and a real trade-off.
- Batch ADR questions by theme. Do not ask one ADR fork at a time unless one answer blocks every other question.
- Do not put implementation notes, animation timing, UI copy, or scratch decisions in `CONTEXT.md`.

## Final Check

Do not merely batch bad questions. Batching five obvious questions is still invalid.

Spend user attention only on decisions that need user judgment. Infer the rest, state the working decision when useful, and keep moving.