Menu
A relentless interview to sharpen a plan or design, which also creates docs (ADRs and glossary) as we go.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Compact the current conversation into a handoff document so a fresh agent can continue the work.
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating spec/PRD asked for?). Use when the user wants to review a branch, work-in-progress changes, or asks to "review since X".
Turn the current conversation into a spec, saved to `.plan/` — no interview, just synthesis of what you've already discussed.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, saved to `.plan/`.
| name | grill-with-docs |
| description | A relentless interview to sharpen a plan or design, which also creates docs (ADRs and glossary) as we go. |
| disable-model-invocation | true |
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.
Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
If a fact can be found by exploring the codebase or project files, look it up rather than asking me. The decisions, though, are mine — put each one to me and wait for my answer.
Throughout the session, apply the domain-modeling skill: challenge my terms against the glossary in CONTEXT.md, sharpen fuzzy language into canonical terms, stress-test relationships with concrete edge-case scenarios, and update CONTEXT.md and docs/adr/ inline as terms and decisions crystallise — creating those files lazily if they don't exist yet.
Do not enact the plan until I confirm we have reached a shared understanding.
