{"id":"after-action-report","name":"after-action-report","summary":"開始、インシデント、または完了したプロジェクトについて、タイムライン、根本原因分析、寄与要因、実践的な教訓を把握するために、構造化された事後レビュー(事後分析、回顧レビュー)を実施しましょう。","body":"# After-Action Report\n\nRun a structured retrospective on a launch, incident, or completed project. Produce actionable lessons, not just a document.\n\nThis skill is for after-the-fact analysis. For active incident response, use `incident-response`. For planning launches, use `launch-runbook`.\n\n---\n\n## When to use\n\n- After any incident (any severity)\n- After every major launch\n- At the end of a project (sprint retro, quarterly retro, project closeout)\n- When a recurring issue has happened enough times to demand investigation\n- When a decision didn't work out and the team wants to learn\n\n## When NOT to use\n\n- During an active incident (use `incident-response`)\n- For pre-launch planning (use `launch-runbook`)\n- For one-off bug fixes that don't merit broad analysis\n\n---\n\n## Required inputs\n\n- The event being analyzed (incident, launch, project)\n- A timeline reconstructed from logs, chat, tickets\n- Participant accounts of what they observed and did\n- Outcomes and impact (what actually happened to users, the business)\n\n---\n\n## The framework: blameless analysis\n\nThe most important principle: blameless. Without it, retrospectives produce hidden information and theatrical lessons rather than real ones.\n\n### What blameless means\n\n- Focus on systems, not individuals\n- Assume everyone made reasonable decisions given what they knew at the time\n- The question is \"why was this decision reasonable to make?\" not \"who screwed up?\"\n- Fixing the system means the next person in that situation succeeds where this person didn't\n\n### What blameless does not mean\n\n- No accountability (action items still have owners)\n- No hard truths (sometimes the system is broken in obvious ways)\n- No standards (some patterns of failure are individual, not systemic)\n- No discomfort (real reflection is uncomfortable)\n\n---\n\n## The framework: 6 sections\n\nA complete AAR covers six sections.\n\n### 1. Summary\n\nA 2 to 3 paragraph overview. Captures:\n\n- What happened\n- Impact (users, business, time)\n- Root cause (in plain language)\n- Top action items\n\nThis is what executives read. Anyone who reads only this section should leave with the most important information.\n\n### 2. Timeline\n\nA reconstructed timeline of events.\n\nFor incidents:\n- T-0: Detection\n- T+X: Acknowledgment\n- T+Y: Severity assessed, IC assigned\n- T+Z: Investigation began\n- ... mitigation, communication, resolution events\n- T+N: Resolution declared\n\nFor launches:\n- Pre-launch decisions and milestones\n- Launch day events\n- Post-launch monitoring observations\n\nFor projects:\n- Major milestones, decisions, pivots\n- Both planned and emergent\n\nThe timeline is the source of truth. Disagreements about what happened get resolved here.\n\n### 3. Root cause analysis\n\nWhat caused this, in plain language.\n\nUse one or both of:\n\n**Five whys.** Start with the surface symptom. Ask \"why?\" Repeat 5 times (or until you reach a true root). Each \"why\" should yield a substantive answer, not a tautology.\n\nExample:\n- Why did the site go down? Database connection pool exhausted.\n- Why was the pool exhausted? Background job opened too many connections.\n- Why did the background job open too many connections? Connection cleanup code didn't run on errors.\n- Why didn't cleanup run on errors? Original code review didn't cover error paths.\n- Why didn't the review cover error paths? No checklist for error handling in our review process.\n\nThe fifth why often reveals the system fix. In this case: improve the review process.\n\n**Causal chain.** Multiple contributing factors that combined.\n\n- Factor 1: Background job opened too many connections (technical)\n- Factor 2: Connection limit was set too low for actual traffic (configuration)\n- Factor 3: No alert on connection pool saturation (monitoring)\n- Factor 4: Recent traffic doubled without infra capacity review (process)\n\nNo single fix addresses the incident. Multiple gaps need attention.\n\n### 4. Contributing factors\n\nFactors that didn't cause the event but made it worse, or removed safety nets that would have caught it.\n\n- Monitoring gaps\n- Documentation gaps\n- Process gaps\n- Tooling gaps\n- Knowledge gaps\n\nA \"would have been caught earlier if...\" factor.\n\n### 5. What went well\n\nReal lessons require capturing successes, not just failures.\n\n- What detection worked?\n- What response worked?\n- What decisions were good?\n- What tools or processes performed as expected?\n\nThis is not consolation. It's calibration. Things that worked here should be reinforced and replicated.\n\n### 6. Action items\n\nSpecific, owned, dated.\n\n| Action | Owner | Due | Type |\n|---|---|---|---|\n| Add alert on connection pool saturation | [name] | [date] | Monitoring |\n| Add error handling checklist to PR template | [name] | [date] | Process |\n| Audit other background jobs for similar issue | [name] | [date] | Code |\n\n**Action item criteria:**\n\n- **Specific.** \"Improve monitoring\" is not actionable. \"Add alert on connection pool saturation, threshold 80%, page on-call\" is.\n- **Owned.** A name. Not \"the team.\"\n- **Dated.** A real date. Not \"soon.\"\n- **Sized.** Roughly hours, days, or weeks of effort.\n- **Closeable.** Definition of done is clear.\n\nAction items that don't close in their committed timeframe should re-surface in the next AAR. Patterns of unclosed actions point to deeper organizational issues.\n\n---\n\n## Workflow\n\n### 1. Schedule the AAR\n\nWithin 1 to 2 weeks of the event. Long enough that emotions cooled and facts gathered. Short enough that memories are fresh.\n\nFor incidents: pre-decided in the response procedure.\nFor launches: schedule on the runbook.\nFor projects: schedule at project closeout.\n\n### 2. Gather inputs\n\nBefore the meeting:\n\n- Reconstructed timeline (often the scribe's notes if there was one)\n- Logs, chat transcripts, tickets, incident updates\n- Individual accounts from each participant (written, before the meeting)\n- Impact data (users affected, duration, revenue impact, etc.)\n\n### 3. Run the meeting\n\nTypical agenda (60 to 90 minutes):\n\n- Read the summary as drafted (5 min)\n- Walk the timeline together. Add corrections. Resolve disagreements. (20 to 30 min)\n- Discuss root cause. Use five whys or causal chain. (15 to 20 min)\n- Discuss contributing factors. (10 min)\n- Discuss what went well. (10 min)\n- Identify action items. Owners and dates. (10 min)\n\nA facilitator runs the meeting. Often the IC for an incident, or a project lead for a project. The facilitator is not the scribe.\n\n### 4. Write the document\n\nWithin a few days of the meeting. The full AAR includes all 6 sections.\n\n### 5. Distribute\n\nInternal: post in a known location. Make searchable. Reference in onboarding.\n\nFor high-severity incidents: external summary may be appropriate (status page, customer email, public blog).\n\n### 6. Track action items\n\nEvery action item should be tracked to closure. The next AAR re-surfaces unclosed ones.\n\n---\n\n## Failure patterns\n\n- **Skipping the AAR for \"small\" incidents.** Patterns get missed.\n- **Naming and shaming.** Real lessons get hidden when people fear blame.\n- **Generic action items.** \"Improve testing\" instead of specific testing change.\n- **Action items that never close.** Filed, forgotten. Same incident recurs.\n- **Theater retrospectives.** Going through the motions without genuine reflection.\n- **Skipping \"what went well.\"** Misses calibration on what's working.\n- **Blame externalized.** \"Our vendor failed.\" OK, what's our system for vendor risk?\n- **Single-person AAR.** One person writes the whole thing. Misses other perspectives.\n- **AAR only for failures.** Successful launches deserve AARs too. Lessons from success are valuable.\n- **Long delays.** Memories fade. Conversations cool. Get it done within 2 weeks.\n\n---\n\n## Output format\n\nA markdown document at `aar-[date]-[event-name].md`.\n\nStructure:\n\n```markdown\n# AAR: [Event name]\n\n**Date of event:** [YYYY-MM-DD]\n**AAR date:** [YYYY-MM-DD]\n**Severity / scope:** [SEV-1 / Major launch / Project closeout]\n**Facilitator:** [Name]\n**Participants:** [Names]\n\n## Summary\n[2 to 3 paragraphs]\n\n## Impact\n- Users affected: [number, segment]\n- Duration: [time]\n- Revenue / business impact: [if applicable]\n\n## Timeline\n[Timestamped events]\n\n## Root cause analysis\n[Five whys or causal chain]\n\n## Contributing factors\n[List]\n\n## What went well\n[List]\n\n## Action items\n| Action | Owner | Due | Type | Status |\n|---|---|---|---|---|\n| | | | | |\n\n## Lessons\n[Reflections that don't fit elsewhere. Often the most quotable section.]\n```\n\n---\n\n## If required data is unavailable\n\nThis skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.\n\n---\n\n## Reference files\n\n- [`references/aar-template.md`](references/aar-template.md) - Fillable AAR template covering incidents, launches, and projects.","author":"@rampstackco","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/rampstackco/claude-skills/tree/main/dist/pi/.agents/skills/after-action-report","license":"MIT","category":"operations","lang":"en","tokens":2073,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/aar-template.md","size":8344,"sha256":"b44409782f5a5cd8840b174b69a1a09ae0bb6b183cea9fab0f35fc2075a3495d"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}