菜单
Respond to a production incident, outage, or regression in the wild: establish the timeline, assess blast radius, and reconstruct what happened with cited evidence. Use this when something is failing in production and you need to understand it before fixing it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Check a built unit goal-backward: classify every brief acceptance criterion COVERED / PARTIAL / MISSING with concrete evidence, so you know what is truly done. Use when: verify N, check whether unit N is done, confirm the goals for roadmap unit N are met.
Turn a numbered roadmap unit into a single brief — why + what + spec — so implementation is unambiguous. Use when: brief N, write the brief for N, capture requirements for roadmap unit N before building.
"Execute a plan in dependency-ordered waves — run independent steps concurrently in isolated worktrees, one atomic, quality-gated commit per step. Use when: build N, execute the plan for N, run the build for roadmap unit N."
Pre-mission discovery: discuss and think out candidate directions for the next feature mission, converge on one concrete proposal, and capture the reasoning as a durable artifact that /mission later reads as its seed. Use when: ideate, what should the next mission be, explore options before committing to a charter. Does not start or mutate any mission — it stops at a proposal.
Start or switch to a named feature mission and capture its purpose, constraints, and numbered roadmap, so every later step shares the same context. Use this to begin a new feature cycle or update its direction — it drives bin/godmode-mission, maintains the project-global .planning/PROJECT.md, and writes the mission's .planning/missions/<mission_id>/ROADMAP.md.
Turn a brief into an ordered, dependency-aware tactical plan plus a per-criterion verification plan, so building is mechanical. Use when: plan N, break down the brief for N, produce the build plan for roadmap unit N.
| name | triage |
| description | Respond to a production incident, outage, or regression in the wild: establish the timeline, assess blast radius, and reconstruct what happened with cited evidence. Use this when something is failing in production and you need to understand it before fixing it. |
| user-invocable | true |
Respond to a live production incident — an outage, a regression, or unexpected behavior reported from the field. Establish what happened and how bad it is BEFORE touching code. This skill triages; it does not write the fix.
Auto Mode suppresses confirmation prompts and proceed-pauses — not the one
clarifying question that can matter here: when it started, when it was last
known-good, or who reported it is unknown, don't ask blank — lead with your
best-inferred answer to override (e.g. "I'll take the incident start as the
first error at 14:02 UTC — correct me if it began earlier"), since triaging the
wrong incident wastes the whole effort. This clarifying question follows the
shared recommendation convention (godmode:recommend-convention) defined in
rules/godmode-recommend.md. Once the symptom is anchored, proceed: reconstruct
the timeline, assess blast radius, and route the fix without pausing. Treat
course-corrections as normal input.
@incident-responderDo NOT skip to the fix. Understand the incident first.
Output: "Symptom [X] first seen at [time]. Last known-good [time]. Changed in window: [Y]."
Output: "Affected: [scope]. Severity: [level]. Status: [ongoing/resolved]."
@incident-responder)Spawn @incident-responder (read-only) to reconstruct the timeline against the
code and recommend remediation with cited evidence. It investigates; it does
not change code.
file:line
evidenceOutput: "Root cause hypothesis: [cause] at [file:line]. Remediation: [options]."
The triage itself does not write the fix. Once a code fix is confirmed:
@debugger for a minimal targeted
fix plus regression test.@writer.Output: "Routed [fix] to [@debugger / @writer]."
@incident-responder is read-only — it reconstructs and recommends, it never
edits code.@debugger or @writer.file:line evidence.| Step | Agent | Purpose |
|---|---|---|
| RECONSTRUCT | MUST spawn @incident-responder (subagent_type: claude-godmode:incident-responder) | Read-only reconstruction of the timeline + remediation with cited evidence |
| ROUTE | @debugger (small defect) or @writer (larger change) | Apply the confirmed code fix — the triage skill never writes it inline |
Rule: Never reconstruct the incident inline when @incident-responder can
do it read-only with cited evidence. Never write the fix from this skill.
This is an on-demand helper, invoked when an incident lands. It is not part of
the routine spine and records no workflow state — run it, route the fix, and
hand off to @debugger or @writer.
Close the run with one consolidated result block. The per-step **Output:** lines above narrate timeline → blast radius → reconstruct → route as you go; this block is the single legible summary the user reads at the end — it leads with the terminal state, summarizes the incident, and names one next move:
file:line evidence."Incident triaged. Root-cause hypothesis: [cause] at [file:line]. Affected [scope], severity [level], [ongoing/resolved]. Routed the fix to
@debugger. Run/debugto verify the fix, then/brief Nif it warrants a tracked work unit."
Spine: off-spine helper — triage the incident and route the fix, then resume the spine at /brief N if the fix warrants a tracked work unit.