Grill with docs
Run the interview in this session. Compose two owned disciplines:
grilling — design-tree + frontier rounds (one frontier per round; facts via tools, decisions via the user)
domain-modeling — glossary, CONTEXT.md, ADRs for hard-to-reverse choices
Use codebase-design only when the conversation reaches a module, interface, or seam. Architecture DAGs still use the OpenCode plan agent, not this skill.
Goal
Leave the repo with:
CONTEXT.md — problem, decisions, open questions, glossary
- ADRs under
docs/adr/ (or adr/ if that already exists) for hard-to-reverse choices
Rules
- You gather facts. The user makes decisions.
- One question at a time when the answer branches. Batch only factual checks. A grilling frontier round may batch independent questions.
- Use the project's words. When a term is overloaded, resolve it and write it into the glossary.
- Do not implement code in this skill.
- If Codebase Memory has no project for cwd, skip it and use repo files.
- Architecture DAGs use the OpenCode plan agent, not this skill.
- Ordinary writes stay in-session after the interview.
- Stop when you can implement or write
to-spec without inventing decisions.
Loop
- Read
CONTEXT.md, existing ADRs, and enough of the repo to speak the domain.
- State the frontier: what you believe, what is undecided, what would change the design.
- Ask the next question (or independent frontier) that most reduces that frontier.
- After each answered decision, update
CONTEXT.md. If the decision is hard to reverse, write an ADR.
- Repeat until the stop condition.
CONTEXT.md shape
# <feature or system>
## Problem
## Decisions
## Open questions
## Glossary
Grill with docs
Run the interview in this session. Do not delegate to missing Matt interview primitives.
Goal
Leave the repo with:
CONTEXT.md — problem, decisions, open questions, glossary
- ADRs under
docs/adr/ (or adr/ if that already exists) for hard-to-reverse choices
Rules
- You gather facts. The user makes decisions.
- One question at a time when the answer branches. Batch only factual checks.
- Use the project's words. When a term is overloaded, resolve it and write it into the glossary.
- Do not implement code in this skill.
- If Codebase Memory has no project for cwd, skip it and use repo files.
- Stop when you can implement or write
/to-spec without inventing decisions.
Loop
- Read
CONTEXT.md, existing ADRs, and enough of the repo to speak the domain.
- State the frontier: what you believe, what is undecided, what would change the design.
- Ask the next question that most reduces that frontier.
- After each answered decision, update
CONTEXT.md. If the decision is hard to reverse, write an ADR.
- Repeat until the stop condition.
CONTEXT.md shape
# <feature or system>
## Problem
## Decisions
## Open questions
## Glossary
## Sources
ADR shape
# ADR <nnn>: <title>
Status: accepted
Date: <ISO date>
## Context
## Decision
## Consequences
After
Tell the user the paths you wrote. If the work is multi-session or they asked for tickets, offer /to-spec then /to-tickets. Otherwise they can implement in this session or type /implement.
1---2name: grill-with-docs3description: Relentless interview to sharpen a plan. Writes CONTEXT.md, a glossary, and ADRs as you go. Use when a feature still needs a plan, the user wants grilling, or they ask for /grill-with-docs.4---56<!-- opencode-bestfriend-overlay:grill-with-docs -->78# Grill with docs910Run the interview in this session. Compose two owned disciplines:1112- `grilling` — design-tree + frontier rounds (one frontier per round; facts via tools, decisions via the user)13- `domain-modeling` — glossary, CONTEXT.md, ADRs for hard-to-reverse choices1415Use `codebase-design` only when the conversation reaches a module, interface, or seam. Architecture DAGs still use the OpenCode plan agent, not this skill.1617## Goal1819Leave the repo with:2021- `CONTEXT.md` — problem, decisions, open questions, glossary22- ADRs under `docs/adr/` (or `adr/` if that already exists) for hard-to-reverse choices2324## Rules2526- You gather facts. The user makes decisions.27- One question at a time when the answer branches. Batch only factual checks. A grilling frontier round may batch independent questions.28- Use the project's words. When a term is overloaded, resolve it and write it into the glossary.29- Do not implement code in this skill.30- If Codebase Memory has no project for cwd, skip it and use repo files.31- Architecture DAGs use the OpenCode plan agent, not this skill.32- Ordinary writes stay in-session after the interview.33- Stop when you can implement or write `to-spec` without inventing decisions.3435## Loop36371. Read `CONTEXT.md`, existing ADRs, and enough of the repo to speak the domain.382. State the frontier: what you believe, what is undecided, what would change the design.393. Ask the next question (or independent frontier) that most reduces that frontier.404. After each answered decision, update `CONTEXT.md`. If the decision is hard to reverse, write an ADR.415. Repeat until the stop condition.4243## CONTEXT.md shape4445```markdown46# <feature or system>4748## Problem4950## Decisions5152## Open questions5354## Glossary55```56<!-- grokbuild-overlay:grill-with-docs -->5758# Grill with docs5960Run the interview in this session. Do not delegate to missing Matt interview primitives.6162## Goal6364Leave the repo with:6566- `CONTEXT.md` — problem, decisions, open questions, glossary67- ADRs under `docs/adr/` (or `adr/` if that already exists) for hard-to-reverse choices6869## Rules7071- You gather facts. The user makes decisions.72- One question at a time when the answer branches. Batch only factual checks.73- Use the project's words. When a term is overloaded, resolve it and write it into the glossary.74- Do not implement code in this skill.75- If Codebase Memory has no project for cwd, skip it and use repo files.76- Stop when you can implement or write `/to-spec` without inventing decisions.7778## Loop79801. Read `CONTEXT.md`, existing ADRs, and enough of the repo to speak the domain.812. State the frontier: what you believe, what is undecided, what would change the design.823. Ask the next question that most reduces that frontier.834. After each answered decision, update `CONTEXT.md`. If the decision is hard to reverse, write an ADR.845. Repeat until the stop condition.8586## CONTEXT.md shape8788```markdown89# <feature or system>9091## Problem9293## Decisions9495## Open questions9697## Glossary9899## Sources100```101102## ADR shape103104```markdown105# ADR <nnn>: <title>106107Status: accepted108Date: <ISO date>109110## Context111112## Decision113114## Consequences115```116117## After118119Tell the user the paths you wrote. If the work is multi-session or they asked for tickets, offer `/to-spec` then `/to-tickets`. Otherwise they can implement in this session or type `/implement`.