[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71T16M0V64KY7H6DF5Y6M96":3,"skill-same:01M71T16M0V64KY7H6DF5Y6M96":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":13,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71T16M0V64KY7H6DF5Y6M96","postmortem-writing",null,"Write effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response proce...","javiertarazon\u002Fide-agente-free-jt7-","javiertarazon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F153141207?v=4","01M71R52TB3S9HXKH6WSNT8A7V","01M71R52VG5KS2DKDDH4GDQ30A",0,"MIT","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fpostmortem-writing\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"postmortem writing","writing","postmortem","root","root cause analysis","action","action items","write","with","analysis","unknown","incident response","when","documents","use","root cause","incident","reviews","community","2026-11-10 13:02:02",false,"---\nname: postmortem-writing\ndescription: \"Write effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response proce...\"\nrisk: unknown\nsource: community\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":38,"source":46,"description":7},"release\u002Fv4.2.11-panel-pro","a92ea02bcf7e2b3dbaf46d49696c29a3cb490d4f",".github\u002Fskills\u002Fpostmortem-writing","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-","https:\u002F\u002Fgithub.com\u002Fjaviertarazon","2026-07-12 07:10:45",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add javiertarazon\u002Fide-agente-free-jt7- --skill postmortem-writing",{"tool":64,"command":65},"bunx","bunx skills add javiertarazon\u002Fide-agente-free-jt7- --skill postmortem-writing",{"tool":67,"command":68},"pnpm","pnpm dlx skills add javiertarazon\u002Fide-agente-free-jt7- --skill postmortem-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fpostmortem-writing\u002FSKILL.md",true,[],[73,97,124,144,159,180],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"publishedAt":47},"01M71TQ7Q6Z10VWF3C2H5X1KW9","zustand-store-ts","Create Zustand stores with TypeScript, subscribeWithSelector middleware, and proper state\u002Faction separation. Use when building React state management, creating global stores, or implementing reacti...","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fzustand-store-ts\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[83,84,85,46,86,87,42,88,40,38,89,36,90,91,92,93,33,94,95,96],"zustand","store","zustand store ts","middleware","implementing","react state management","react","state","create","state management","typescript","management","separation","global",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":106,"publishedAt":47},"01M71TQ5EAR40G6W0MV5ZDVEZT","zoom-automation","Automate Zoom meeting creation, management, recordings, webinars, and participant tracking via Rube MCP (Composio). Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fzoom-automation\u002FSKILL.md",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[107,108,109,46,110,111,112,113,114,38,115,116,117,118,119,120,121,122,94,123],"zoom automation","zoom","automation","creation","for","search","schemas","MCP","first","via","meeting","search tools","tracking","webinars","composio","recordings","Tools",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":47},"01M71TQ29B1EYBCEAP1ZBGXQ1A","zoho-crm-automation","Automate Zoho CRM tasks via Rube MCP (Composio): create\u002Fupdate records, search contacts, manage leads, and convert leads. Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fzoho-crm-automation\u002FSKILL.md",[130],{"categoryNo":104,"categoryName":105,"taxonomyType":20,"taxonomyTypeDesc":21},[132,133,109,134,135,136,46,137,138,111,139,112,113,140,114,38,141,142,143,91],"crm automation","zoho crm automation","crm","zoho crm","zoho","leads","manage leads","manage","records","convert","tasks","contacts",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":47},"01M71TPZPMN60DH0XV58KVHY23","zendesk-automation","Automate Zendesk tasks via Rube MCP (Composio): tickets, users, organizations, replies. Always search tools first for current schemas.","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fzendesk-automation\u002FSKILL.md",[150],{"categoryNo":104,"categoryName":105,"taxonomyType":20,"taxonomyTypeDesc":21},[152,109,153,46,111,112,113,114,154,38,142,155,156,115,116,157,118,121,123,158],"zendesk automation","zendesk","organizations","replies","users","tickets","automate",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":47},"01M71TPXDWKHKG4N6TVEPXWD0N","zapier-make-patterns","No-code automation democratizes workflow building. Zapier and Make (formerly Integromat) let non-developers automate business processes without writing code. But no-code doesn't mean no-complexity ...","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fzapier-make-patterns\u002FSKILL.md",[],[166,167,168,169,170,171,29,172,173,109,174,38,175,176,177,178,179,158],"zapier make patterns","zapier","patterns","make","No-Code","complexity","spawner","business","workflow","code","integromat","apache","processes","but",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":189,"publishedAt":47},"01M71TPT5T10WXNKW9G7ZXZ27W","youtube-summarizer","Extract transcripts from YouTube videos and generate comprehensive, detailed summaries using intelligent analysis frameworks","https:\u002F\u002Fgithub.com\u002Fjaviertarazon\u002Fide-agente-free-jt7-\u002Fblob\u002Frelease\u002Fv4.2.11-panel-pro\u002F.github\u002Fskills\u002Fyoutube-summarizer\u002FSKILL.md",[186],{"categoryNo":187,"categoryName":188,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",[190,191,192,193,46,194,195,196,197,198,199,37,175,200,201,202,203,204,205,206],"summarizer","youtube","youtube summarizer","Video","content-analysis","frameworks","copilot","2025","github-copilot","extract transcripts","codex","cli","summaries","github","generate","summarization","2026"]