菜单
Use when the user explicitly asks to be grilled, stress-test a plan/idea/design, or sharpen vague thinking through relentless interview. Do not invoke unless explicitly asked by the user.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use only when the user explicitly asks or allows delegating implementation to a Codex worker — launch Pi running openai-codex/gpt-5.6-sol (xhigh) as a visible sidecar implementer that this session orchestrates over AMQ. Write exact task specs, dispatch with --kind todo, validate the results yourself, then iterate, resume, respawn, or launch another worker. Never invoke on your own initiative.
Use only when the user explicitly allows or asks for this skill to be invoked to pair with a second agent harness — launch a sidecar, get a second opinion from another agent, have one harness drive another, or review work with another agent over AMQ. Otherwise, never invoke it.
first step of planning
convert structure outline into a detailed implementation plan
Create a Product Requirements Document with inline mockups
generate research questions based on a task, spec, or ticket
| name | grill-me |
| description | Use when the user explicitly asks to be grilled, stress-test a plan/idea/design, or sharpen vague thinking through relentless interview. Do not invoke unless explicitly asked by the user. |
| disable_model_invocation | true |
| disable-model-invocation | true |
| effort | max |
Interview the user relentlessly about every aspect of their plan or idea. Walk down each branch of the decision tree, resolving dependencies between decisions one by one.
If a question can be answered by exploring the codebase, explore the codebase instead of asking.
Do not accept vague answers. Push for specifics. When the user says "I think maybe X," ask why X and not Y. When the user says "it depends," ask on what.
When all branches are resolved, summarize the decisions reached and save to ai_docs/grills/YYYY-MM-DD-description.md.
Before wrapping up, ask one final round about cross-cutting design preferences — code organization style (classes vs functions, module cohesion), naming conventions, error handling approach, or any other stylistic constraints the user wants applied uniformly across the task. These aren't per-decision choices — they're preferences that affect how every module is written. Capture them in a dedicated "Design Preferences" section at the end of the grill document. (The design discussion skill will also ask about these — capturing them here gives them an early anchor.)
