菜单
Relentlessly stress-test a plan, design, architecture, idea, or strategy until all critical decisions are resolved. Use when a plan, design, or decision needs adversarial stress-testing before committing to it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Stress-test a plan against the project's existing domain model by challenging terminology, surfacing contradictions with code, and updating CONTEXT.md and ADRs inline as decisions crystallise. Use when a plan or design needs to be checked against the project's documented domain model before implementation.
Compact the current conversation into a handoff document for another agent to pick up. Use when ending a session, switching agents, or preserving context before compaction.
Audit a project's dependencies for outdated and vulnerable packages and surface breaking-change notes for upgrades. Works with any ecosystem, including npm/pnpm/yarn, pip/Poetry/uv, Cargo, Go modules, Maven/Gradle, Bundler, Composer, and others. Use when checking a project's dependency health, planning upgrades, or responding to a vulnerability report.
Stress-test a plan against the project's existing domain model by challenging terminology, surfacing contradictions with code, and updating CONTEXT.md and ADRs inline as decisions crystallise. Use when a plan or design needs to be checked against the project's documented domain model before implementation.
Relentlessly stress-test a plan, design, architecture, idea, or strategy until all critical decisions are resolved. Use when a plan, design, or decision needs adversarial stress-testing before committing to it.
Compact the current conversation into a handoff document for another agent to pick up. Use when ending a session, switching agents, or preserving context before compaction.
| name | grill-me |
| description | Relentlessly stress-test a plan, design, architecture, idea, or strategy until all critical decisions are resolved. Use when a plan, design, or decision needs adversarial stress-testing before committing to it. |
| argument-hint | (optional) the plan, design, or idea to stress-test; paste it or point to a file |
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one by one.
If arguments were passed, treat them as the subject to grill. Otherwise, ask what to stress-test before starting. If a question can be answered by exploring the codebase or reading existing files, do that instead of asking.
NEVER use the AskUserQuestion tool; ask questions as plain text output.
ONE question per turn. Then STOP. Wait for reply. No lists. No "and also". No follow-ups. No bundled sub-questions. One ? per response. Violating this defeats the skill; the user needs space to think, not a wall of questions.
If a question leads to more nested branches, move those to a new question. Never nest question numbers.
Index each question as Q1, Q2, Q3, …
Explain why the question matters.
Ask exactly one question.
Present the options as labeled choices (A, B, C, …) covering the realistic alternatives. Mark your recommended option with ← recommended. Example:
A. Option one ← recommended B. Option two C. Option three
The user can reply with just a letter. If they pick a non-recommended option, acknowledge the tradeoff before moving on.
Produce a decision record covering:
