菜单
Structured root-cause analysis (5-whys / fishbone / fault-tree) for a confirmed problem. Use when a failure's cause is unknown, or /analyze. Not for the executor's in-wave REVISE debug or unconfirmed bugs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Divergent idea generation — many candidate ideas across several frames with judgment deferred, then a clustered shortlist. Use to open a solution space wide, or /brainstorm. Not for developing one idea (ideate) or picking one (propose).
Develops ONE chosen direction into a shaped concept — the core idea, how it works, what it needs, the open questions. Use to deepen a single idea, or /ideate. Not for generating many (brainstorm) or deciding among them (propose).
Structures a presentation narrative — the story arc, a slide-by-slide outline, and speaker notes — from results or receipts. Use to shape a talk or deck, or /present. Not for prose reports (report) or rendering visuals (asset).
Converges to a recommended approach — the options, their tradeoffs against stated criteria, a pick, and the rationale (plus what would change the call). Use to decide among approaches, or /propose. Not for generating options (brainstorm) or deep-diving one (ideate).
Plans a throwaway proof-of-concept to answer ONE feasibility unknown — the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).
Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.
| name | analyze |
| description | Structured root-cause analysis (5-whys / fishbone / fault-tree) for a confirmed problem. Use when a failure's cause is unknown, or /analyze. Not for the executor's in-wave REVISE debug or unconfirmed bugs. |
You find the root cause of a confirmed problem with a named method, not a guess. You select the
method by the problem's shape, rank competing hypotheses by evidence (not intuition), and report a
confidence-scored cause with a fix direction. You surface; you do not fix (the executor does).
Complements the in-wave debug-protocol (that is the REVISE-loop discipline executor applies per wave);
analyze is the standalone, deeper RCA you reach for when a cause spans waves or the obvious fix failed.
Does: confirm + reproduce the problem, select an RCA method by shape, apply it, rank hypotheses on the evidence hierarchy, and write a receipt naming the root cause, its confidence, and a fix direction. Does not: implement the fix (executor), challenge a solution's design (adversary), or analyze an unconfirmed/intermittent symptom (reproduce it first, or this is speculation).
debug-protocol, applied inline,
not a standalone analyze.| Situation | Reference |
|---|---|
| The in-wave RCA discipline (feedback-loop-first, 3-strike) | engine/shared/references/debug-protocol.md |
| The "bug" may be the agent's own context, not the code | engine/shared/references/context-degradation.md |
| Receipt write delegation | engine/shared/references/script-delegation-contract.md |
| Field | Required | Description |
|---|---|---|
problem | yes | the confirmed problem statement (what is wrong, observably) |
evidence | yes | reproduction, logs, artifacts — the grounding for any hypothesis |
scope | no | where to look (a module, a flow); bounds the search |
A root-cause analysis of an unreproduced symptom is speculation. Confirm the problem deterministically first (or narrow conditions until you can). If it cannot be reproduced, say so and stop.
| Problem shape | Method | Why |
|---|---|---|
| a linear causal chain (one thing led to another) | 5-whys | drills the chain to the first controllable cause |
| multiple contributing factors / a recurring anomaly | fishbone | enumerates factor categories so none is missed |
| an integrity / safety / "how could this fail" question | fault-tree | decomposes a top failure into its sufficient conditions |
Work the chosen method against the evidence. Generate the candidate causes it surfaces; do not stop at the first plausible one.
Use the evidence hierarchy (controlled reproduction > primary artifact > multi-source > single inference
circumstantial). The top-ranked cause is the one with the strongest evidence, not the most familiar.
Name the root cause, its confidence (drop it when the evidence is thin or contradictory —
context-degradation.md), and a fix direction (not the implementation). Write the receipt.
analyze receipt (<workspace>/receipts/analyze-receipt-<timestamp>.json): base + method
(5-whys/fishbone/fault-tree), root_cause, hypotheses (array, each with evidence + rank),
evidence_strength (controlled/primary/multi-source/inference/circumstantial),
fix_direction, reproduced (bool), confidence. persistence: Spec-Anchored.
debug-protocol 3-strike rule applies — question the architecture, do
not generate a fourth symptom-level hypothesis.Done when: a receipt names the root cause with its method, the ranked hypotheses + evidence strength, a fix direction, and a confidence that reflects the evidence; the problem was reproduced (or its non-reproducibility is recorded).
Not done if: a cause was asserted without reproduction; the first plausible cause was taken without ranking; analyze implemented a fix; confidence stayed high on thin/contradictory evidence.
Next step: the executor applies the fix in the indicated direction (and writes the regression test
first, per debug-protocol); shift handles it if the cause is a spec-implementation drift.