Grill With Docs
Stress-test a plan or direction against your knowledge base and project vocabulary before you commit build time.
Overview
Grill With Docs is an agent skill most often used in Validate (also Build, Ship) that interviews you through your plan’s decision tree and aligns terminology with documented project vocabulary.
Install
npx skills add https://github.com/haowjy/creative-writing-skills --skill grill-with-docsWhat is this skill?
- Walks the decision tree one branch at a time with recommended answers each turn
- Cross-checks terms against kb/vocab.md, domain vocab, CLAUDE.md, work/, and prior decisions
- Surfaces assumptions treated as given and dependency order between choices
- Loads intent-modeling when not already active for shared understanding
- Keeps turns small—one unresolved branch or related cluster per author reply
Adoption & trust: 1 installs on skills.sh; 241 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
You have a direction or plan full of vague terms, implicit assumptions, and unresolved branches that could derail implementation the moment you start building.
Who is it for?
Solo builders refining specs, creative direction, or technical plans when a kb/, CLAUDE.md, or work/ notes already exist to anchor vocabulary.
Skip if: Skipping when the plan is already approved, signed off, and frozen—use execution or review skills instead; also not a substitute for legal/compliance review of commitments.
When should I use this skill?
Use when challenging a plan—grills the author against documented decisions and sharpens terminology.
What do I get? / Deliverables
You and the agent reach a shared, precise understanding of decisions and vocabulary—ready to freeze scope or hand off to planning skills such as writing-plans once branches are resolved.
- Resolved decision-branch notes
- Aligned terminology against project vocabulary
- Shared understanding summary for the author
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the skill exists to sharpen scope and decisions before full implementation—not to ship code or run growth campaigns. Scope is where ambiguous plans, undefined terms, and hidden dependencies hurt most; grilling branches and terminology here prevents expensive rework downstream.
Where it fits
Grill a feature scope doc against kb/vocab.md before you estimate or prototype.
Walk an implementation plan’s branches so API vs UI sequencing is explicit before the agent writes tasks.
Challenge a release plan’s terminology so ‘beta’ and ‘GA’ match prior launch decisions in work/ notes.
Pressure-test a positioning draft so audience terms match CLAUDE.md and do not contradict competitor research notes.
How it compares
Structured adversarial Q&A against your docs—not a one-shot “critique my idea” chat or a passive linter.
Common Questions / FAQ
Who is grill-with-docs for?
Solo and indie builders (and small teams) who document decisions in a repo and want an agent to challenge plans before coding or shipping narrative work.
When should I use grill-with-docs?
During Validate to tighten scope; during Build PM when an implementation plan needs dependency order; during Ship review when a proposed change set still has ambiguous terms; anytime you are about to commit after a brainstorm but vocabulary is fuzzy.
Is grill-with-docs safe to install?
It is a procedural interview skill that reads project files you point it at; review the Security Audits panel on this Prism page before installing and limit access to sensitive kb paths in your repo.
Workflow Chain
Requires first: intent modeling
Then invoke: writing plans
SKILL.md
READMESKILL.md - Grill With Docs
# Grill With Docs Load `/intent-modeling` if it isn't already loaded. Interview the author relentlessly about every aspect of their plan until you reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one by one. Keep each turn to the next unresolved branch or a small cluster of related questions the author can answer in one reply, then wait. Provide your recommended answer for each question. ## Starting the Session Read the plan or proposed direction the author provides. Identify: - **Decision branches** — choices that gate other choices - **Dependency order** — which decisions must resolve first - **Terms needing precision** — vague, overloaded, or undefined vocabulary - **Assumptions** — things treated as given that may not be Start with the highest-leverage unresolved dependency — the earliest branch point that unblocks the most downstream decisions. ## Challenging Terminology Check every significant term against the project's existing vocabulary where it exists: 1. Vocabulary pages in the kb — `kb/vocab.md` for project-wide terms, `kb/<domain>/vocab.md` for domain-specific ones. 2. Project conventions in `CLAUDE.md` — established names and labels. 3. Active work notes in `work/` — terms already defined for the current effort. 4. Prior decisions — terms established by earlier choices. When the author's language conflicts with documented terms, call it out immediately. Name the conflict: "You said X, but the kb defines Y for this concept — which should we use?" Sharpen vague or overloaded terms into canonical terms. Use concrete scenarios and edge cases to force precise boundaries — "Does 'sync' here mean the timeline beat, the character's realization, or something new?" See `/shared-dao` for the vocabulary discipline. ## Gathering Evidence When answering requires cross-referencing project materials beyond what is already in context, read the specific files directly, or spawn a focused subagent to gather evidence so your own context stays on the grilling conversation. Scope each lookup to one question and target specific files or directories — chapters, kb entries, outlines, prior decisions. Frame the lookup as an evidence-seeking question with file/path targets. Act on findings to sharpen your next question or to challenge the author's assumptions with evidence. ## Updating Documentation Update artifacts inline as decisions crystallize. Reasoning flattens the longer you wait — capture it in the moment. ### Active work notes Record decisions in `work/` as they stabilize — the decision, the reasoning, and any constraints that emerged. Keep open questions visible. ### KB vocabulary When the session produces a new canonical term or refines an existing one, update the appropriate vocabulary page: `kb/vocab.md` for cross-cutting terms, `kb/<domain>/vocab.md` for domain-specific ones. Follow `/kb-management` for page structure. ### Durable decisions Create durable decision records sparingly — only when the choice is hard to reverse, surprising without context, and involves a real tradeoff. Record it in the relevant kb page. Keep provisional decisions in `work/` until they prove durable. ## Session Rhythm Each cycle through a decision branch: 1. State the branch and why it matters now (dependency context). 2. Ask focused questions with your recommended answer for each. 3. Wait for the author's response. 4. If the answer raises a sub-question, drill into it before moving on. 5. If the answer can be verified against project materials, check the relevant files and use what you find to confirm or challenge. 6. When the branch resolves, update the relevant documentation surface immediately. 7. Advance to the next branch. The session ends when all branches of the decision tree are resolved and the