[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70NTCY2V7PQQHE5MN8AMQJ4":3,"skill-same:01M70NTCY2V7PQQHE5MN8AMQJ4":76},{"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":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M70NTCY2V7PQQHE5MN8AMQJ4","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 processes.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fwshobson-agents\u002Fplugins\u002Fincident-response\u002Fskills\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,39,40,41,42,43,44,45,46],"postmortem","postmortem writing","writing","root","processes","root cause analysis","with","use","root cause","action","action items","write","analysis","incident response","when","documents","incident","reviews","2026-11-10 10:12:30",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 processes.\n---\n\n# Postmortem Writing\n\nComprehensive guide to writing effective, blameless postmortems that drive organizational learning and prevent incident recurrence.\n\n## When to Use This Skill\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](internal-wiki\u002Fconnection-pools)\n- [Deployment Runbook](internal-wiki\u002Fdeployment-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## When to Use This Skill\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](internal-wiki\u002Fconnection-pools)\n- [Deployment Runbook](internal-wiki\u002Fdeployment-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,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002Fwshobson-agents\u002Fplugins\u002Fincident-response\u002Fskills\u002Fpostmortem-writing",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill postmortem-writing",{"tool":68,"command":69},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill postmortem-writing",{"tool":71,"command":72},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill postmortem-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fwshobson-agents\u002Fplugins\u002Fincident-response\u002Fskills\u002Fpostmortem-writing\u002FSKILL.md",true,[],[77,91,123,146,168,187],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":84,"publishedAt":47},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[83],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[85,86,87,88,89,31,90],"methodology","xiaolai","xiaolai methodology","朋友","投资","收入",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":103,"publishedAt":47},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[97,100],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":101,"categoryName":102,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[93,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","architecture","code","unknown","generated",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":131,"publishedAt":47},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[129,130],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[125,132,133,134,135,136,137,138,112,139,140,141,43,36,142,143,144,145],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","auto","types","Video","创作",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":47},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[152],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},[154,155,125,156,157,144,158,159,160,161,162,163,164,165,110,166,43,36,104,167],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":178,"publishedAt":47},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[174,175,176,177],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":101,"categoryName":102,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[179,31,180,181,182,40,120,43,36,183,184,185,186],"writing skills","how","teach","write skill","claude code skills","files","how to","trigger",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":195,"publishedAt":47},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[193,194],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[196,31,197,108,198,184,43,180,40,36,185],"Rules","writing rules","project rules"]