メニュー
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to be grilled about a plan, wants a decision stress-tested, or when requirements are fuzzy before a spec is written.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | grilling |
| description | Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to be grilled about a plan, wants a decision stress-tested, or when requirements are fuzzy before a spec is written. |
| version | 1.0.0 |
| source | mattpocock/skills@1.1.0 (grilling) |
Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one.
If a fact can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The decisions, though, are mine — put each one to me and wait for my answer.
Number every question sequentially across the interview (Q1, Q2, …) so answers and later references stay unambiguous.
When you can offer multiple concrete candidate answers, present them as a lettered list: reasoning and tradeoffs first, then the question itself, then the options, with your recommended one first and marked "(Recommended)". When a question is too open-ended to enumerate candidate answers, ask it openly instead — still one question at a time, still with your recommended answer.
When my answer contains a question or remark of my own, answer it before (or instead of) asking the next question; never let a new question bury the reply.
When a decision needs empirical evidence rather than debate, propose /prototype for it; when it hinges on facts living in external docs or sources, propose /research.
The interview is done when every branch of the decision tree is resolved. Close with a single sentence stating that shared understanding is reached — no summary — then recommend the next step as a flow pointer (presentation) and wait for my go-ahead:
/spec (user-invoked) when the outcome is a feature worth a written contract — in this session, since it synthesizes the interview; implementation then starts fresh./implement (user-invoked) directly when it's a small fix that needs no spec — in this session, which already carries the context./prototype when an unresolved question survived the interview and needs empirical evidence — in this session, feeding the verdict back here./research when an unresolved question needs facts from primary sources — it runs in the background while this session continues.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.
Scan the session for compound-worthy learnings, then commit the working tree with a repo-appropriate, value-communicating message.
Garbage-collect the knowledge stores — audit docs/solutions/ and AGENTS.md against the current code.
Capture this session's durable learnings and route each to the right knowledge store, every write user-gated. Use at loop end when /commit's opening scan finds candidates, when /diagnosing-bugs closes out a fix, or when the user wants to capture, remember, or write down a learning, convention, gotcha, or preference.
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
Compact the conversation into a handoff document a fresh session can resume from.