메뉴
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 직업 분류 기준
| 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.
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.