production-incident-analysis

Production Incident Analysis (Chinese Version)

When to Use

When you need to establish a timeline, contain impact, form evidence-based hypotheses, and drive recovery and retrospective in a production incident.
When you need to conduct a risk review of existing plans, results, or evidence, and form actionable improvement items.
When the input is incomplete, but a usable first version with assumptions and information gaps still needs to be provided first.

The default output is Markdown, suitable for review, execution, and continuous supplementation.
When the user requests a table, CSV, JSON, or ticket format, retain the same risk, evidence, priority, and boundary fields.
If the output will enter an automated process, first confirm the field schema, enum values, and required items.

First read and follow prompts/production-incident-analysis.md 's input, execution rules, minimum coverage checklist, and output order.
Supplement the scope, environment, version, constraints, evidence, and success criteria that truly affect judgment.
First perform an input audit, then distinguish confirmed facts, reasonable assumptions, and open questions.
Sort by risk and evidence strength, and produce results that can be directly executed, reviewed, or verified.
When information is insufficient, do not stop at asking questions: first deliver a constrained first version, and state which conclusions cannot yet hold.

Must read on every execution prompts/production-incident-analysis.md; it is the complete execution specification of this Skill.
When evaluating or regressing this Skill, read evals/eval.yaml and the matching evals/cases/ use cases.
Only read references/、examples/、scripts/ or output-formats.mdwhen the directory actually exists and the task requires it; do not assume assets that do not exist.

Recovery takes priority over complete root cause
Do not assign blame when evidence is insufficient
Write rollback and verification for every high-risk operation
Do not fabricate system behavior, fields, data, metrics, or root causes that do not exist in the input.
Key conclusions must be linked to evidence; when evidence is insufficient, mark them as assumptions and provide a verification method.
Priority must state the basis in business impact, likelihood of occurrence, or detectability.

Covered: impact scope, timeline, detection, changes, dependencies, mitigation effectiveness, evidence strength, recurrence risk.
Facts, assumptions, gaps, and recommendations are distinguished.
High-risk items have clear priority, evidence, owner, or next step.
The output contains verifiable judgment criteria, rather than vague generalities.
No unauthorized production write operations or destructive actions were performed.

Listing only checkpoints without stating input conditions, expected results, or evidence.
Marking everything as high priority, losing the value of trade-offs.
Replacing domain judgment with tool names or generic theory.
Directly refusing when the input is incomplete, or conversely pretending the conclusion is already certain.

Start from the path most likely to cause business loss, security issues, or release blockage.
Use the smallest verifiable experiment to reduce uncertainty, and record reproduction conditions.
Make the output directly executable and reviewable by another engineer.