メニュー
Use when encountering any bug, failing test, flaky behavior, or unexpected result before proposing fixes. Keeps debugging lightweight but root-cause driven.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Stress-test a plan, design, decision, or idea through a one-question-at-a-time interview. Use when the user invokes /grill, says grill me, asks to be challenged, 拷问, 压力测试, or wants a plan stress-tested; also use when progress is blocked by an unresolved user-owned decision whose alternatives materially change the outcome after high-risk classification is ruled out. Do not use merely because work is complex, high-risk, new, or spans multiple files.
Use when the user explicitly requests Brainstorming, a design spec, Spec Gate, or the full Superpowers workflow; also use automatically for costly-to-reverse high-risk work involving architecture or service boundaries, public-contract compatibility, authentication or authorization, persistent data/schema migration, or irreversible external side effects. Do not use for ordinary behavior changes or merely because work is new, complex, or spans multiple files.
Chinese workflow for surfacing systematic fact, evidence, context, and blind-spot gaps before, during, and after agentic work. Use when the user explicitly asks for a blind-spot scan, unknown unknowns, prototypes, reference mapping, implementation notes, explainers, or quizzes; when phrases like "I'll know it when I see it" or "teach me this domain" expose unstated assumptions; or when safe progress is blocked by evidence gaps that require multiple low-cost probes. Do not use merely because work is complex, high-risk, long-running, or spans multiple files.
Use when starting or routing a non-trivial task in this workflow harness, when the user references Superpowers, or when deciding which skill, command, rule, or agent should govern the work. Establishes skill invocation discipline: check relevant process skills before acting, follow user/project instructions first, and verify before completion.
Use when you have a spec or requirements for a multi-step task, before touching code
用于功能验收、回归验证、确认修复是否生效，以及需要用真实界面、视频或日志证据判断用户流程是否正常的任务。适用于“验收一下”“测一下”“确认修复”“给我可复核证据”等请求。
| name | systematic-debugging |
| description | Use when encountering any bug, failing test, flaky behavior, or unexpected result before proposing fixes. Keeps debugging lightweight but root-cause driven. |
Use this skill when implementation or verification reveals a bug, failing test, flaky behavior, or unexpected result.
The goal is not to make debugging heavy. The goal is to stop guessing. Complete the four phases in order, then return to the active task or plan.
Do not propose or apply a fix until Phase 1 identifies a credible root cause and Phase 3 has tested the hypothesis with the smallest useful check.Output: one sentence naming the likely root cause and the evidence for it.
Output: the smallest affected scope and any similar files that should or should not change.
Output: confirmed hypothesis or reason for returning to investigation.
Output: root cause, fix summary, commands run, result, and remaining risk.
After the fix is verified, return to the original task:
