[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M716TSEWQADSHP9T6Y650ES9":3,"skill-same:01M716TSEWQADSHP9T6Y650ES9":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M716TSEWQADSHP9T6Y650ES9","postmortem-writing",null,"Comprehensive guide to writing effective, blameless postmortems that drive organizational learning and prevent incident recurrence.","sapsapshen\u002Fai-memory-router","sapsapshen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20347959?v=4","01M6XDQEF1DP50DKF37H81J3J5","shenmian","01M6XDQEJPE41Y3DT2763X8ZJN",0,"MIT","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcursor\u002Fpostmortem-writing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38],"postmortem","postmortem writing","writing","community","incident","learning","unknown","2026","drive","guide","2026-11-10 10:12:30",false,"---\nname: postmortem-writing\ndescription: \"Comprehensive guide to writing effective, blameless postmortems that drive organizational learning and prevent incident recurrence.\"\nrisk: unknown\nsource: community\ndate_added: \"2026-02-27\"\n---\n\n# Postmortem Writing\n\nComprehensive guide to writing effective, blameless postmortems that drive organizational learning and prevent incident recurrence.\n\n## Do not use this skill when\n\n- The task is unrelated to postmortem writing\n- You need a different domain or tool outside this scope\n\n## Instructions\n\n- Clarify goals, constraints, and required inputs.\n- Apply relevant best practices and validate outcomes.\n- Provide actionable steps and verification.\n- If detailed examples are required, open `resources\u002Fimplementation-playbook.md`.\n\n## Use this skill when\n\n- Conducting post-incident reviews\n- Writing postmortem documents\n- Facilitating blameless postmortem meetings\n- Identifying root causes and contributing factors\n- Creating actionable follow-up items\n- Building organizational learning culture\n\n## Core Concepts\n\n### 1. Blameless Culture\n\n| Blame-Focused | Blameless |\n|---------------|-----------|\n| \"Who caused this?\" | \"What conditions allowed this?\" |\n| \"Someone made a mistake\" | \"The system allowed this mistake\" |\n| Punish individuals | Improve systems |\n| Hide information | Share learnings |\n| Fear of speaking up | Psychological safety |\n\n### 2. Postmortem Triggers\n\n- SEV1 or SEV2 incidents\n- Customer-facing outages > 15 minutes\n- Data loss or security incidents\n- Near-misses that could have been severe\n- Novel failure modes\n- Incidents requiring unusual intervention\n\n## Quick Start\n\n### Postmortem Timeline\n```\nDay 0: Incident occurs\nDay 1-2: Draft postmortem document\nDay 3-5: Postmortem meeting\nDay 5-7: Finalize document, create tickets\nWeek 2+: Action item completion\nQuarterly: Review patterns across incidents\n```\n\n## Templates\n\n### Template 1: Standard Postmortem\n\n```markdown\n# Postmortem: [Incident Title]\n\n**Date**: 2024-01-15\n**Authors**: @alice, @bob\n**Status**: Draft | In Review | Final\n**Incident Severity**: SEV2\n**Incident Duration**: 47 minutes\n\n## Executive Summary\n\nOn January 15, 2024, the payment processing service experienced a 47-minute outage affecting approximately 12,000 customers. The root cause was a database connection pool exhaustion triggered by a configuration change in deployment v2.3.4. The incident was resolved by rolling back to v2.3.3 and increasing connection pool limits.\n\n**Impact**:\n- 12,000 customers unable to complete purchases\n- Estimated revenue loss: $45,000\n- 847 support tickets created\n- No data loss or security implications\n\n## Timeline (All times UTC)\n\n| Time | Event |\n|------|-------|\n| 14:23 | Deployment v2.3.4 completed to production |\n| 14:31 | First alert: `payment_error_rate > 5%` |\n| 14:33 | On-call engineer @alice acknowledges alert |\n| 14:35 | Initial investigation begins, error rate at 23% |\n| 14:41 | Incident declared SEV2, @bob joins |\n| 14:45 | Database connection exhaustion identified |\n| 14:52 | Decision to rollback deployment |\n| 14:58 | Rollback to v2.3.3 initiated |\n| 15:10 | Rollback complete, error rate dropping |\n| 15:18 | Service fully recovered, incident resolved |\n\n## Root Cause Analysis\n\n### What Happened\n\nThe v2.3.4 deployment included a change to the database query pattern that inadvertently removed connection pooling for a frequently-called endpoint. Each request opened a new database connection instead of reusing pooled connections.\n\n### Why It Happened\n\n1. **Proximate Cause**: Code change in `PaymentRepository.java` replaced pooled `DataSource` with direct `DriverManager.getConnection()` calls.\n\n2. **Contributing Factors**:\n   - Code review did not catch the connection handling change\n   - No integration tests specifically for connection pool behavior\n   - Staging environment has lower traffic, masking the issue\n   - Database connection metrics alert threshold was too high (90%)\n\n3. **5 Whys Analysis**:\n   - Why did the service fail? → Database connections exhausted\n   - Why were connections exhausted? → Each request opened new connection\n   - Why did each request open new connection? → Code bypassed connection pool\n   - Why did code bypass connection pool? → Developer unfamiliar with codebase patterns\n   - Why was developer unfamiliar? → No documentation on connection management patterns\n\n### System Diagram\n\n```\n[Client] → [Load Balancer] → [Payment Service] → [Database]\n                                    ↓\n                            Connection Pool (broken)\n                                    ↓\n                            Direct connections (cause)\n```\n\n## Detection\n\n### What Worked\n- Error rate alert fired within 8 minutes of deployment\n- Grafana dashboard clearly showed connection spike\n- On-call response was swift (2 minute acknowledgment)\n\n### What Didn't Work\n- Database connection metric alert threshold too high\n- No deployment-correlated alerting\n- Canary deployment would have caught this earlier\n\n### Detection Gap\nThe deployment completed at 14:23, but the first alert didn't fire until 14:31 (8 minutes). A deployment-aware alert could have detected the issue faster.\n\n## Response\n\n### What Worked\n- On-call engineer quickly identified database as the issue\n- Rollback decision was made decisively\n- Clear communication in incident channel\n\n### What Could Be Improved\n- Took 10 minutes to correlate issue with recent deployment\n- Had to manually check deployment history\n- Rollback took 12 minutes (could be faster)\n\n## Impact\n\n### Customer Impact\n- 12,000 unique customers affected\n- Average impact duration: 35 minutes\n- 847 support tickets (23% of affected users)\n- Customer satisfaction score dropped 12 points\n\n### Business Impact\n- Estimated revenue loss: $45,000\n- Support cost: ~$2,500 (agent time)\n- Engineering time: ~8 person-hours\n\n### Technical Impact\n- Database primary experienced elevated load\n- Some replica lag during incident\n- No permanent damage to systems\n\n## Lessons Learned\n\n### What Went Well\n1. Alerting detected the issue before customer reports\n2. Team collaborated effectively under pressure\n3. Rollback procedure worked smoothly\n4. Communication was clear and timely\n\n### What Went Wrong\n1. Code review missed critical change\n2. Test coverage gap for connection pooling\n3. Staging environment doesn't reflect production traffic\n4. Alert thresholds were not tuned properly\n\n### Where We Got Lucky\n1. Incident occurred during business hours with full team available\n2. Database handled the load without failing completely\n3. No other incidents occurred simultaneously\n\n## Action Items\n\n| Priority | Action | Owner | Due Date | Ticket |\n|----------|--------|-------|----------|--------|\n| P0 | Add integration test for connection pool behavior | @alice | 2024-01-22 | ENG-1234 |\n| P0 | Lower database connection alert threshold to 70% | @bob | 2024-01-17 | OPS-567 |\n| P1 | Document connection management patterns | @alice | 2024-01-29 | DOC-89 |\n| P1 | Implement deployment-correlated alerting | @bob | 2024-02-05 | OPS-568 |\n| P2 | Evaluate canary deployment strategy | @charlie | 2024-02-15 | ENG-1235 |\n| P2 | Load test staging with production-like traffic | @dave | 2024-02-28 | QA-123 |\n\n## Appendix\n\n### Supporting Data\n\n#### Error Rate Graph\n[Link to Grafana dashboard snapshot]\n\n#### Database Connection Graph\n[Link to metrics]\n\n### Related Incidents\n- 2023-11-02: Similar connection issue in User Service (POSTMORTEM-42)\n\n### References\n- Connection Pool Best Practices\n- Deployment Runbook\n```\n\n### Template 2: 5 Whys Analysis\n\n```markdown\n# 5 Whys Analysis: [Incident]\n\n## Problem Statement\nPayment service experienced 47-minute outage due to database connection exhaustion.\n\n## Analysis\n\n### Why #1: Why did the service fail?\n**Answer**: Database connections were exhausted, causing all new requests to fail.\n\n**Evidence**: Metrics showed connection count at 100\u002F100 (max), with 500+ pending requests.\n\n---\n\n### Why #2: Why were database connections exhausted?\n**Answer**: Each incoming request opened a new database connection instead of using the connection pool.\n\n**Evidence**: Code diff shows direct `DriverManager.getConnection()` instead of pooled `DataSource`.\n\n---\n\n### Why #3: Why did the code bypass the connection pool?\n**Answer**: A developer refactored the repository class and inadvertently changed the connection acquisition method.\n\n**Evidence**: PR #1234 shows the change, made while fixing a different bug.\n\n---\n\n### Why #4: Why wasn't this caught in code review?\n**Answer**: The reviewer focused on the functional change (the bug fix) and didn't notice the infrastructure change.\n\n**Evidence**: Review comments only discuss business logic.\n\n---\n\n### Why #5: Why isn't there a safety net for this type of change?\n**Answer**: We lack automated tests that verify connection pool behavior and lack documentation about our connection patterns.\n\n**Evidence**: Test suite has no tests for connection handling; wiki has no article on database connections.\n\n## Root Causes Identified\n\n1. **Primary**: Missing automated tests for infrastructure behavior\n2. **Secondary**: Insufficient documentation of architectural patterns\n3. **Tertiary**: Code review checklist doesn't include infrastructure considerations\n\n## Systemic Improvements\n\n| Root Cause | Improvement | Type |\n|------------|-------------|------|\n| Missing tests | Add infrastructure behavior tests | Prevention |\n| Missing docs | Document connection patterns | Prevention |\n| Review gaps | Update review checklist | Detection |\n| No canary | Implement canary deployments | Mitigation |\n```\n\n### Template 3: Quick Postmortem (Minor Incidents)\n\n```markdown\n# Quick Postmortem: [Brief Title]\n\n**Date**: 2024-01-15 | **Duration**: 12 min | **Severity**: SEV3\n\n## What Happened\nAPI latency spiked to 5s due to cache miss storm after cache flush.\n\n## Timeline\n- 10:00 - Cache flush initiated for config update\n- 10:02 - Latency alerts fire\n- 10:05 - Identified as cache miss storm\n- 10:08 - Enabled cache warming\n- 10:12 - Latency normalized\n\n## Root Cause\nFull cache flush for minor config update caused thundering herd.\n\n## Fix\n- Immediate: Enabled cache warming\n- Long-term: Implement partial cache invalidation (ENG-999)\n\n## Lessons\nDon't full-flush cache in production; use targeted invalidation.\n```\n\n## Facilitation Guide\n\n### Running a Postmortem Meeting\n\n```markdown\n## Meeting Structure (60 minutes)\n\n### 1. Opening (5 min)\n- Remind everyone of blameless culture\n- \"We're here to learn, not to blame\"\n- Review meeting norms\n\n### 2. Timeline Review (15 min)\n- Walk through events chronologically\n- Ask clarifying questions\n- Identify gaps in timeline\n\n### 3. Analysis Discussion (20 min)\n- What failed?\n- Why did it fail?\n- What conditions allowed this?\n- What would have prevented it?\n\n### 4. Action Items (15 min)\n- Brainstorm improvements\n- Prioritize by impact and effort\n- Assign owners and due dates\n\n### 5. Closing (5 min)\n- Summarize key learnings\n- Confirm action item owners\n- Schedule follow-up if needed\n\n## Facilitation Tips\n- Keep discussion on track\n- Redirect blame to systems\n- Encourage quiet participants\n- Document dissenting views\n- Time-box tangents\n```\n\n## Anti-Patterns to Avoid\n\n| Anti-Pattern | Problem | Better Approach |\n|--------------|---------|-----------------|\n| **Blame game** | Shuts down learning | Focus on systems |\n| **Shallow analysis** | Doesn't prevent recurrence | Ask \"why\" 5 times |\n| **No action items** | Waste of time | Always have concrete next steps |\n| **Unrealistic actions** | Never completed | Scope to achievable tasks |\n| **No follow-up** | Actions forgotten | Track in ticketing system |\n\n## Best Practices\n\n### Do's\n- **Start immediately** - Memory fades fast\n- **Be specific** - Exact times, exact errors\n- **Include graphs** - Visual evidence\n- **Assign owners** - No orphan action items\n- **Share widely** - Organizational learning\n\n### Don'ts\n- **Don't name and shame** - Ever\n- **Don't skip small incidents** - They reveal patterns\n- **Don't make it a blame doc** - That kills learning\n- **Don't create busywork** - Actions should be meaningful\n- **Don't skip follow-up** - Verify actions completed\n\n## Resources\n\n- [Google SRE - Postmortem Culture](https:\u002F\u002Fsre.google\u002Fsre-book\u002Fpostmortem-culture\u002F)\n- [Etsy's Blameless Postmortems](https:\u002F\u002Fcodeascraft.com\u002F2012\u002F05\u002F22\u002Fblameless-postmortems\u002F)\n- [PagerDuty Postmortem Guide](https:\u002F\u002Fpostmortems.pagerduty.com\u002F)\n","# Postmortem Writing\n\nComprehensive guide to writing effective, blameless postmortems that drive organizational learning and prevent incident recurrence.\n\n## Do not use this skill when\n\n- The task is unrelated to postmortem writing\n- You need a different domain or tool outside this scope\n\n## Instructions\n\n- Clarify goals, constraints, and required inputs.\n- Apply relevant best practices and validate outcomes.\n- Provide actionable steps and verification.\n- If detailed examples are required, open `resources\u002Fimplementation-playbook.md`.\n\n## Use this skill when\n\n- Conducting post-incident reviews\n- Writing postmortem documents\n- Facilitating blameless postmortem meetings\n- Identifying root causes and contributing factors\n- Creating actionable follow-up items\n- Building organizational learning culture\n\n## Core Concepts\n\n### 1. Blameless Culture\n\n| Blame-Focused | Blameless |\n|---------------|-----------|\n| \"Who caused this?\" | \"What conditions allowed this?\" |\n| \"Someone made a mistake\" | \"The system allowed this mistake\" |\n| Punish individuals | Improve systems |\n| Hide information | Share learnings |\n| Fear of speaking up | Psychological safety |\n\n### 2. Postmortem Triggers\n\n- SEV1 or SEV2 incidents\n- Customer-facing outages > 15 minutes\n- Data loss or security incidents\n- Near-misses that could have been severe\n- Novel failure modes\n- Incidents requiring unusual intervention\n\n## Quick Start\n\n### Postmortem Timeline\n```\nDay 0: Incident occurs\nDay 1-2: Draft postmortem document\nDay 3-5: Postmortem meeting\nDay 5-7: Finalize document, create tickets\nWeek 2+: Action item completion\nQuarterly: Review patterns across incidents\n```\n\n## Templates\n\n### Template 1: Standard Postmortem\n\n```markdown\n# Postmortem: [Incident Title]\n\n**Date**: 2024-01-15\n**Authors**: @alice, @bob\n**Status**: Draft | In Review | Final\n**Incident Severity**: SEV2\n**Incident Duration**: 47 minutes\n\n## Executive Summary\n\nOn January 15, 2024, the payment processing service experienced a 47-minute outage affecting approximately 12,000 customers. The root cause was a database connection pool exhaustion triggered by a configuration change in deployment v2.3.4. The incident was resolved by rolling back to v2.3.3 and increasing connection pool limits.\n\n**Impact**:\n- 12,000 customers unable to complete purchases\n- Estimated revenue loss: $45,000\n- 847 support tickets created\n- No data loss or security implications\n\n## Timeline (All times UTC)\n\n| Time | Event |\n|------|-------|\n| 14:23 | Deployment v2.3.4 completed to production |\n| 14:31 | First alert: `payment_error_rate > 5%` |\n| 14:33 | On-call engineer @alice acknowledges alert |\n| 14:35 | Initial investigation begins, error rate at 23% |\n| 14:41 | Incident declared SEV2, @bob joins |\n| 14:45 | Database connection exhaustion identified |\n| 14:52 | Decision to rollback deployment |\n| 14:58 | Rollback to v2.3.3 initiated |\n| 15:10 | Rollback complete, error rate dropping |\n| 15:18 | Service fully recovered, incident resolved |\n\n## Root Cause Analysis\n\n### What Happened\n\nThe v2.3.4 deployment included a change to the database query pattern that inadvertently removed connection pooling for a frequently-called endpoint. Each request opened a new database connection instead of reusing pooled connections.\n\n### Why It Happened\n\n1. **Proximate Cause**: Code change in `PaymentRepository.java` replaced pooled `DataSource` with direct `DriverManager.getConnection()` calls.\n\n2. **Contributing Factors**:\n   - Code review did not catch the connection handling change\n   - No integration tests specifically for connection pool behavior\n   - Staging environment has lower traffic, masking the issue\n   - Database connection metrics alert threshold was too high (90%)\n\n3. **5 Whys Analysis**:\n   - Why did the service fail? → Database connections exhausted\n   - Why were connections exhausted? → Each request opened new connection\n   - Why did each request open new connection? → Code bypassed connection pool\n   - Why did code bypass connection pool? → Developer unfamiliar with codebase patterns\n   - Why was developer unfamiliar? → No documentation on connection management patterns\n\n### System Diagram\n\n```\n[Client] → [Load Balancer] → [Payment Service] → [Database]\n                                    ↓\n                            Connection Pool (broken)\n                                    ↓\n                            Direct connections (cause)\n```\n\n## Detection\n\n### What Worked\n- Error rate alert fired within 8 minutes of deployment\n- Grafana dashboard clearly showed connection spike\n- On-call response was swift (2 minute acknowledgment)\n\n### What Didn't Work\n- Database connection metric alert threshold too high\n- No deployment-correlated alerting\n- Canary deployment would have caught this earlier\n\n### Detection Gap\nThe deployment completed at 14:23, but the first alert didn't fire until 14:31 (8 minutes). A deployment-aware alert could have detected the issue faster.\n\n## Response\n\n### What Worked\n- On-call engineer quickly identified database as the issue\n- Rollback decision was made decisively\n- Clear communication in incident channel\n\n### What Could Be Improved\n- Took 10 minutes to correlate issue with recent deployment\n- Had to manually check deployment history\n- Rollback took 12 minutes (could be faster)\n\n## Impact\n\n### Customer Impact\n- 12,000 unique customers affected\n- Average impact duration: 35 minutes\n- 847 support tickets (23% of affected users)\n- Customer satisfaction score dropped 12 points\n\n### Business Impact\n- Estimated revenue loss: $45,000\n- Support cost: ~$2,500 (agent time)\n- Engineering time: ~8 person-hours\n\n### Technical Impact\n- Database primary experienced elevated load\n- Some replica lag during incident\n- No permanent damage to systems\n\n## Lessons Learned\n\n### What Went Well\n1. Alerting detected the issue before customer reports\n2. Team collaborated effectively under pressure\n3. Rollback procedure worked smoothly\n4. Communication was clear and timely\n\n### What Went Wrong\n1. Code review missed critical change\n2. Test coverage gap for connection pooling\n3. Staging environment doesn't reflect production traffic\n4. Alert thresholds were not tuned properly\n\n### Where We Got Lucky\n1. Incident occurred during business hours with full team available\n2. Database handled the load without failing completely\n3. No other incidents occurred simultaneously\n\n## Action Items\n\n| Priority | Action | Owner | Due Date | Ticket |\n|----------|--------|-------|----------|--------|\n| P0 | Add integration test for connection pool behavior | @alice | 2024-01-22 | ENG-1234 |\n| P0 | Lower database connection alert threshold to 70% | @bob | 2024-01-17 | OPS-567 |\n| P1 | Document connection management patterns | @alice | 2024-01-29 | DOC-89 |\n| P1 | Implement deployment-correlated alerting | @bob | 2024-02-05 | OPS-568 |\n| P2 | Evaluate canary deployment strategy | @charlie | 2024-02-15 | ENG-1235 |\n| P2 | Load test staging with production-like traffic | @dave | 2024-02-28 | QA-123 |\n\n## Appendix\n\n### Supporting Data\n\n#### Error Rate Graph\n[Link to Grafana dashboard snapshot]\n\n#### Database Connection Graph\n[Link to metrics]\n\n### Related Incidents\n- 2023-11-02: Similar connection issue in User Service (POSTMORTEM-42)\n\n### References\n- Connection Pool Best Practices\n- Deployment Runbook\n```\n\n### Template 2: 5 Whys Analysis\n\n```markdown\n# 5 Whys Analysis: [Incident]\n\n## Problem Statement\nPayment service experienced 47-minute outage due to database connection exhaustion.\n\n## Analysis\n\n### Why #1: Why did the service fail?\n**Answer**: Database connections were exhausted, causing all new requests to fail.\n\n**Evidence**: Metrics showed connection count at 100\u002F100 (max), with 500+ pending requests.\n\n---\n\n### Why #2: Why were database connections exhausted?\n**Answer**: Each incoming request opened a new database connection instead of using the connection pool.\n\n**Evidence**: Code diff shows direct `DriverManager.getConnection()` instead of pooled `DataSource`.\n\n---\n\n### Why #3: Why did the code bypass the connection pool?\n**Answer**: A developer refactored the repository class and inadvertently changed the connection acquisition method.\n\n**Evidence**: PR #1234 shows the change, made while fixing a different bug.\n\n---\n\n### Why #4: Why wasn't this caught in code review?\n**Answer**: The reviewer focused on the functional change (the bug fix) and didn't notice the infrastructure change.\n\n**Evidence**: Review comments only discuss business logic.\n\n---\n\n### Why #5: Why isn't there a safety net for this type of change?\n**Answer**: We lack automated tests that verify connection pool behavior and lack documentation about our connection patterns.\n\n**Evidence**: Test suite has no tests for connection handling; wiki has no article on database connections.\n\n## Root Causes Identified\n\n1. **Primary**: Missing automated tests for infrastructure behavior\n2. **Secondary**: Insufficient documentation of architectural patterns\n3. **Tertiary**: Code review checklist doesn't include infrastructure considerations\n\n## Systemic Improvements\n\n| Root Cause | Improvement | Type |\n|------------|-------------|------|\n| Missing tests | Add infrastructure behavior tests | Prevention |\n| Missing docs | Document connection patterns | Prevention |\n| Review gaps | Update review checklist | Detection |\n| No canary | Implement canary deployments | Mitigation |\n```\n\n### Template 3: Quick Postmortem (Minor Incidents)\n\n```markdown\n# Quick Postmortem: [Brief Title]\n\n**Date**: 2024-01-15 | **Duration**: 12 min | **Severity**: SEV3\n\n## What Happened\nAPI latency spiked to 5s due to cache miss storm after cache flush.\n\n## Timeline\n- 10:00 - Cache flush initiated for config update\n- 10:02 - Latency alerts fire\n- 10:05 - Identified as cache miss storm\n- 10:08 - Enabled cache warming\n- 10:12 - Latency normalized\n\n## Root Cause\nFull cache flush for minor config update caused thundering herd.\n\n## Fix\n- Immediate: Enabled cache warming\n- Long-term: Implement partial cache invalidation (ENG-999)\n\n## Lessons\nDon't full-flush cache in production; use targeted invalidation.\n```\n\n## Facilitation Guide\n\n### Running a Postmortem Meeting\n\n```markdown\n## Meeting Structure (60 minutes)\n\n### 1. Opening (5 min)\n- Remind everyone of blameless culture\n- \"We're here to learn, not to blame\"\n- Review meeting norms\n\n### 2. Timeline Review (15 min)\n- Walk through events chronologically\n- Ask clarifying questions\n- Identify gaps in timeline\n\n### 3. Analysis Discussion (20 min)\n- What failed?\n- Why did it fail?\n- What conditions allowed this?\n- What would have prevented it?\n\n### 4. Action Items (15 min)\n- Brainstorm improvements\n- Prioritize by impact and effort\n- Assign owners and due dates\n\n### 5. Closing (5 min)\n- Summarize key learnings\n- Confirm action item owners\n- Schedule follow-up if needed\n\n## Facilitation Tips\n- Keep discussion on track\n- Redirect blame to systems\n- Encourage quiet participants\n- Document dissenting views\n- Time-box tangents\n```\n\n## Anti-Patterns to Avoid\n\n| Anti-Pattern | Problem | Better Approach |\n|--------------|---------|-----------------|\n| **Blame game** | Shuts down learning | Focus on systems |\n| **Shallow analysis** | Doesn't prevent recurrence | Ask \"why\" 5 times |\n| **No action items** | Waste of time | Always have concrete next steps |\n| **Unrealistic actions** | Never completed | Scope to achievable tasks |\n| **No follow-up** | Actions forgotten | Track in ticketing system |\n\n## Best Practices\n\n### Do's\n- **Start immediately** - Memory fades fast\n- **Be specific** - Exact times, exact errors\n- **Include graphs** - Visual evidence\n- **Assign owners** - No orphan action items\n- **Share widely** - Organizational learning\n\n### Don'ts\n- **Don't name and shame** - Ever\n- **Don't skip small incidents** - They reveal patterns\n- **Don't make it a blame doc** - That kills learning\n- **Don't create busywork** - Actions should be meaningful\n- **Don't skip follow-up** - Verify actions completed\n\n## Resources\n\n- [Google SRE - Postmortem Culture](https:\u002F\u002Fsre.google\u002Fsre-book\u002Fpostmortem-culture\u002F)\n- [Etsy's Blameless Postmortems](https:\u002F\u002Fcodeascraft.com\u002F2012\u002F05\u002F22\u002Fblameless-postmortems\u002F)\n- [PagerDuty Postmortem Guide](https:\u002F\u002Fpostmortems.pagerduty.com\u002F)\n",{"name":5,"risk":35,"source":32,"date_added":44,"description":7},"2026-02-27","main","7a38d8e7073e61c16eda85681cb32fb68a8657a5","skills-store\u002Fcursor\u002Fpostmortem-writing","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router","https:\u002F\u002Fgithub.com\u002Fsapsapshen","2026-04-14 21:12:12",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add sapsapshen\u002Fai-memory-router --skill postmortem-writing",{"tool":57,"command":58},"bunx","bunx skills add sapsapshen\u002Fai-memory-router --skill postmortem-writing",{"tool":60,"command":61},"pnpm","pnpm dlx skills add sapsapshen\u002Fai-memory-router --skill postmortem-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcursor\u002Fpostmortem-writing\u002FSKILL.md",true,[],[66,88,114,124,137,154],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":75,"publishedAt":39},"01M71ATQRKG48SH06FQ697T5G9","wechat-search","Search WeChat Official Account articles using OpenClaw's web search and fetch capabilities with compliance-focused design.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fwechat-search-release\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[76,77,78,79,80,81,82,83,84,85,86,87],"wechat search","wechat","search","capabilities","openclaw","design","web search","compliance","web","official","fetch","with",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":39},"01M71ATNAVGZB35PFYM2GC5N00","trend-tap","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend tap', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-tap\u002FSKILL.md",[],[95,96,97,98,99,100,78,101,102,103,104,105,106,107,108,109,110,111,112,113],"trend","trend tap","tap","api keys","Bash","time","trending","hacker","aggregator","do","when","brew","live","data","google","install","read","across","api",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":39},"01M71ATJ9AM5KM15AA8PS302EB","trend-radar","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend pulse', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-radar\u002FSKILL.md",[],[121,122,95,106,107,108,109,99,78,111,123,112,113,105,103,102,101,110,100,98],"trend radar","radar","pulse",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":39},"01M71ATGF095N3EJM9G8SD0BB5","tech-news-daily","每日科技新闻汇——从全球多个 RSS 源抓取最新科技新闻，翻译（英→中）、去重、排版成每日简报。当用户询问科技新闻、科技新鲜事、每日科技、技术动态、Daily Tech News 或类似表达时触发此技能。","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftech-news-daily\u002FSKILL.md",[],[131,132,133,134,135,136],"news","tech","tech news daily","daily","rss","翻译",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":146,"publishedAt":39},"01M71ATFAEAMQ17M70NQNY7SR8","summarize","Summarize URLs or files with the summarize CLI (web, PDFs, images, audio, YouTube).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsummarize\u002FSKILL.md",[143],{"categoryNo":144,"categoryName":145,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[139,84,147,148,149,87,106,150,151,152,97,153,110],"Audio","cli","youtube","images","https","files","pdfs",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":39},"01M71ATDNS3R0M4H936PACQAWZ","sonoscli","Control Sonos speakers (discover\u002Fstatus\u002Fplay\u002Fvolume\u002Fgroup).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsonoscli\u002FSKILL.md",[],[156,161,162,163,110,164,151,165,166,167,168,169],"status","play","go","latest","github","discover","control","cmd","volume"]