菜单
Use when the user has a rough idea, feature request, or decision and the requirements are not yet pinned down. Interviews the user relentlessly, one question at a time, before any spec or code is written. Also use when asked to "grill me", "interrogate me", or write a PRD from a vague description.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a question has a factual or best-practice answer but a single response might hallucinate, or when the user asks to "get consensus" or "sanity check this with multiple agents". Spawns N subagents on the same question with varied personas and tallies answer frequency.
Use when a question has real trade-offs and no single right answer: architecture choices, library selection, design direction. Runs a multi-round debate where agents see each other's positions across rounds, converge, and a synthesis is produced. For factual questions, use consensus instead.
Use when triaging an inbox: fetching unprocessed emails, classifying each into a label taxonomy, and applying labels via the provider's API. Provider-agnostic skeleton; scripts/label.py must be wired to your email provider before first use.
Use when a workflow built on an MCP server has stabilized and should become a production skill, or when the user says "convert this MCP workflow to a skill". Produces a skill with a bundled script that calls the underlying API directly, eliminating the per-session MCP token overhead.
Use when a PRD or spec exists and needs to become an executable backlog. Breaks the document into GitHub issues structured as vertical-slice tracer bullets, marks each as HITL or AFK, and files a final QA issue. Requires the gh CLI.
Use when implementing any task that should end in a commit. Encodes the definition of done: understand, implement with red-green-refactor for backend logic, run typecheck and tests until clean, then commit. Also the unit of work for autonomous loops.
| name | grill-me |
| description | Use when the user has a rough idea, feature request, or decision and the requirements are not yet pinned down. Interviews the user relentlessly, one question at a time, before any spec or code is written. Also use when asked to "grill me", "interrogate me", or write a PRD from a vague description. |
You are about to conduct a requirements interview. The user has an idea. Your job is to find every decision hiding inside it before a single line of spec or code exists. For a real feature, 30-50 questions is normal. Do not rush.
When the interview is done, write the result to a spec file (spec.md or wherever the project keeps them): decisions made, options rejected and why, open questions explicitly deferred. The spec contains no question marks except in the deferred section.
