القائمة
Use when a production incident has occurred — structured blameless post-incident analysis that reconstructs timeline, assesses impact, finds root causes, and produces concrete action items.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when building any UI, HTML component, slide, document, or design asset that will represent SBP visually — applies the Schuberg Philis visual brand identity (colors, typography, logo, stylization, grids, photography, iconography) to ensure brand-consistent output without manual reminders.
Use when conducting a security review, reducing dependency surface, or when dependencies may pose supply-chain, bloat, or maintainability risks.
Use when deploying to production — verifies rollback readiness, monitoring, and change communication against mission-critical criteria and produces a go/no-go decision.
Use when verifying monitoring, alerting, and logging coverage — checks the four pillars (metrics, logs, traces, alerts), produces a coverage matrix with gaps, severity ratings, and recommended actions, and applies the 3 AM test to every component.
Use when existing code needs to change shape before a feature, or when code drift is making further work expensive — improves structure and readability without changing observable behavior.
Use when generating operational runbooks from code and infrastructure — produces runbooks that work at 3 AM, covering common failure scenarios with specific diagnosis and resolution steps, copy-pasteable commands, and clear escalation paths.
| name | sbp-incident-review |
| description | Use when a production incident has occurred — structured blameless post-incident analysis that reconstructs timeline, assesses impact, finds root causes, and produces concrete action items. |
| metadata | {"domain":"platform","lifecycle":"run"} |
Conduct a blameless post-incident review. The purpose is learning, not blame. Systems fail; the question is what we change so they fail less or recover faster.
Build a detailed, timestamped sequence of events. This is the foundation — get it right before analyzing anything.
Use UTC timestamps. Note the gap between each phase — long gaps reveal process problems.
Format the timeline as:
HH:MM UTC — [Event description] (Source: alert/person/log)
Call out any point where information was missing, misleading, or delayed. These are as important as the events themselves.
Quantify the impact. Vague impact statements lead to vague prioritization of fixes.
Use the "5 Whys" approach. Keep asking why until you reach a systemic cause, not a human action.
Distinguish between:
Bad root cause: "Engineer deployed a bad config." Good root cause: "Config validation did not check for invalid values in the rate-limit field, allowing a zero value that caused all requests to be rejected. The deploy pipeline had no canary stage to catch this before full rollout."
The root cause should point to a system or process to fix, never to a person to blame.
What conditions made this incident possible, worse, or longer to resolve beyond the direct root cause?
Consider each category:
Explicitly capture what worked during the incident response. This is not optional — it is how you protect and reinforce good practices.
Be specific. "Good teamwork" is not useful. "On-call engineer used the database runbook to identify the lock contention within 8 minutes of the alert" is.
Every action item must be:
Format:
| # | Action item | Priority | Owner | Target date |
|---|---|---|---|---|
| 1 | Add config validation for rate-limit field (reject zero/negative values) | P1 | @name | YYYY-MM-DD |
| 2 | Add canary stage to deploy pipeline for config changes | P1 | @name | YYYY-MM-DD |
| 3 | Update runbook with rate-limit incident scenario | P2 | @name | YYYY-MM-DD |
Avoid vague items:
The final document should follow this structure, suitable for sharing with stakeholders:
Write in third person, past tense, blameless framing. Replace personal names in the narrative with roles ("the on-call engineer") unless the person specifically wants to be named. Keep names only in the action item owner column.