菜单
Live-system triage — read-only evidence first, establish what/since-when/how-wide, correlate onset with changes, trace one failing request, mitigate reversibly before root-causing. Use when production is broken now, or before restarting/redeploying/deleting as a first move.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).
Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.
When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.
Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.
Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.
Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.
| name | incident-diagnosis |
| description | Live-system triage — read-only evidence first, establish what/since-when/how-wide, correlate onset with changes, trace one failing request, mitigate reversibly before root-causing. Use when production is broken now, or before restarting/redeploying/deleting as a first move. |
Code debugging optimizes for finding the cause. Incident work optimizes for restoring service safely — the cause can wait; making things worse cannot. Different discipline, different order.
The strong first move is read-only. Restarts, redeploys, cache flushes, and deletes destroy the evidence AND can compound the failure (a restart storm on an overloaded dependency; a redeploy on top of a bad migration). Every state-changing action needs the evidence to support THAT action specifically — "a restart usually fixes it" is pattern-matching, not evidence.
Most incidents are caused by a change. Diff the world at onset time: deploys, config changes, dependency/provider incidents, certificate expiries, cron jobs that fired, data that crossed a threshold (disk full, quota, integer/ID rollover, date boundaries). "Nothing changed" usually means "nothing I know about changed" — widen the search (adjacent teams, provider status, OS/infra auto-updates).
Pick ONE concrete failing request/job and trace it through the layers (edge → LB → service → dependency → data), checking at each hop: did it arrive, what did it return, how long did it take? The failure lives at the first layer where behavior diverges from normal. Resist diagnosing from aggregate dashboards alone — averages hide the failing path.
If users are hurting and a reversible mitigation exists — rollback, feature-flag off, failover, rate-limit, scale up — propose/apply it BEFORE completing root-cause analysis. Note what evidence to capture pre-mitigation (logs, a core dump, a copy of bad state) so the trail survives. Rollback of the correlated change is the mitigation with the best prior.
Mitigations must be reversible and understood: never "fix" by deleting data or forcing state you can't restore.
After service is restored, the investigation becomes ordinary root-cause-debugging (reproduce, bisect, falsifiable hypothesis). An incident closed at "restarted it and it went away" WILL reoccur — say so explicitly if that's where things stand, and record what instrumentation would catch it earlier next time.
Timeline (times + facts, no speculation mixed in), current impact, what's confirmed vs suspected, actions taken (with before/after evidence), next action. Update as facts land. Never present a hypothesis as a finding — mislabeled confidence misroutes everyone downstream of your report.
