تشغيل أي مهارة في Manus بنقرة واحدة

incident-postmortem

النجوم١

التفرعات١

آخر تحديث١٠ يونيو ٢٠٢٦ في ١٦:٠٢

Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

jnMetaCode

jnMetaCode/skillet

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

متخصصو إدارة المشاريعمهن الأعمال والعمليات المالية·SOC 13-1082

SKILL.md

readonly

name	incident-postmortem
description	Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.
version	1.0.0
license	MIT
keywords	["postmortem","incident","outage","sre","writing"]

incident-postmortem

A postmortem exists to change the system, not to assign blame or to perform remorse. Optimize for the engineer two years from now who hits something similar at 3am.

Procedure

Timeline first, from artifacts. Build it from logs, alerts, deploy records and chat timestamps — not memory. Every entry: time (with zone), what happened, what was known at that moment. Mark detection, diagnosis, mitigation, resolution.
Impact, quantified. Who/what/how long/how many: "checkout failed for 12 customers over 3h; all recovered" beats "some users were affected".
Root cause as a causal chain, not a single line. Use "because" links: webhooks dropped → because the endpoint 500'd on duplicates → because a unique-constraint violation was treated as fatal → because the handler assumed Stripe never retries. The last "because" is usually an assumption, and assumptions are what you fix.
Blameless mechanically: name systems and decisions, not people. "The deploy script allowed a config-less rollout" — not "X forgot the config". If a person had to be careful for the system to be safe, that's the finding.
What went well / what got lucky. Luck is a finding too ("we noticed only because someone happened to be watching dashboards").
Action items that would have prevented or shortened THIS incident, each with an owner and a date. Test each one: "would this have helped on the timeline above?" If not, cut it. 3–5 strong items beat 15 aspirational ones.

Skeleton

# 2026-04-02 — Payments webhook outage (3h, 12 failed checkouts)

**Summary** (3 sentences: what broke, impact, fix)
**Timeline** (timestamped, detection → resolution)
**Root cause** (causal chain, ending at the broken assumption)
**What went well / what got lucky**
**Action items** (owner · due date · "would it have helped?")

المزيد من هذا المستودع

نفس المستودع

self-evolve

jnMetaCode/skillet

Make the agent improve with every task — review the run, distill lessons into durable memory, and reinforce what worked. Use at the end of any non-trivial task, or when the user asks the agent to "learn from this".

2026-06-101

pr-description

jnMetaCode/skillet

Write a reviewer-first pull-request description from the actual branch diff. Use when opening a PR or asked to write/improve a PR description.

2026-06-101

systematic-debugging

jnMetaCode/skillet

Root-cause a bug with a hypothesis-driven loop instead of shotgun edits. Use when a bug isn't obvious after the first look, or when asked to "find out why" something fails.

2026-06-101

test-writing

jnMetaCode/skillet

Write tests that catch real regressions — behavior-focused, minimal mocking, edge cases chosen from the code's actual branches. Use when adding tests for new code or backfilling tests for a fix.

2026-06-101

changelog

jnMetaCode/skillet

Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…".

2026-06-101

conventional-commits

jnMetaCode/skillet

Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.

2026-06-101

incident-postmortem

A postmortem exists to change the system, not to assign blame or to perform remorse. Optimize for the engineer two years from now who hits something similar at 3am.

Procedure

Timeline first, from artifacts. Build it from logs, alerts, deploy records and chat timestamps — not memory. Every entry: time (with zone), what happened, what was known at that moment. Mark detection, diagnosis, mitigation, resolution.

Impact, quantified. Who/what/how long/how many: "checkout failed for 12 customers over 3h; all recovered" beats "some users were affected".

Root cause as a causal chain, not a single line. Use "because" links: webhooks dropped → because the endpoint 500'd on duplicates → because a unique-constraint violation was treated as fatal → because the handler assumed Stripe never retries. The last "because" is usually an assumption, and assumptions are what you fix.

Blameless mechanically: name systems and decisions, not people. "The deploy script allowed a config-less rollout" — not "X forgot the config". If a person had to be careful for the system to be safe, that's the finding.

What went well / what got lucky. Luck is a finding too ("we noticed only because someone happened to be watching dashboards").

Action items that would have prevented or shortened THIS incident, each with an owner and a date. Test each one: "would this have helped on the timeline above?" If not, cut it. 3–5 strong items beat 15 aspirational ones.

Skeleton

# 2026-04-02 — Payments webhook outage (3h, 12 failed checkouts) **Summary** (3 sentences: what broke, impact, fix) **Timeline** (timestamped, detection → resolution) **Root cause** (causal chain, ending at the broken assumption) **What went well / what got lucky** **Action items** (owner · due date · "would it have helped?")