/tabletop-aar — draft the After-Action Report

You ingest a completed tabletop exercise's filled forms and produce a polished After-Action Report.

Argument flags

Workflow

Step 1 — Locate the exercise

If --exercise given, use that path. Otherwise:

1. Look for tabletop-exercises/ in the cwd
2. Find the most recently modified subdirectory (use ls -t semantics via Bash)
3. Confirm with the user which exercise they want before writing the AAR — show the path and summary, ask "AAR this one?"

If no exercises exist, tell the user there's nothing to AAR and suggest running /tabletop first.

Step 2 — Ingest filled forms

Read in parallel:

• RUNBOOK.md (for scenario context — what was the exercise meant to test?)
• forms/attendance.md
• forms/decision-log.md
• forms/timeline-reconstruction.md
• forms/gaps-and-findings.md
• forms/aar-template.md (any pre-filled notes)
• If --from-json given, load that JSON instead of the markdown forms

If forms are mostly empty (more than half blank), warn the user that the AAR will be thin and ask if they want to proceed or add notes first.

Step 3 — Synthesize

Build the AAR with these sections, in order:

1. Executive summary — 3-5 sentences. What was tested, who attended, top 3 takeaways, top 3 action items. Tuned to the --audience flag.

1. Exercise overview — scenario name, date, duration, attendees (anonymized to roles if regulator/board audience), facilitator(s).

1. Timeline reconstruction — what happened in the exercise, phase by phase, with timestamps from the decision log. Stay factual; commentary goes in later sections.

1. What went well — specific behaviors and decisions to repeat. Cite the decision log. Tie each to a capability the exercise was meant to test.

1. What didn't go well — gaps, hesitations, missed escalations, decision paralysis, communication breakdowns. Cite the decision log. Be specific and blameless — describe behavior, not character.

1. Gaps identified — categorized:

• Technical: missing tooling, alerting blind spots, runbook gaps
• Process: unclear ownership, escalation ambiguity, decision rights
• Communication: internal coordination, customer/regulator/exec messaging
• People / training: knowledge gaps, single-points-of-knowledge

1. Action items — table format. Columns: Action · Owner · Severity (P0/P1/P2) · Target date · Tracking link (placeholder). Order by severity. Be ruthless about ownership — every item has exactly one owner.

1. Recommendations for next exercise — what to test next, what to adjust about the format, who else should be in the room.

1. Appendices — A: raw decision log · B: gaps as captured · C: attendance · D: raw timeline. (Anonymize attendees and timeline names if --audience is regulator or board.)

Step 4 — Write artifacts

Write in the exercise directory:

• AAR.md — the full report
• AAR.html — styled HTML version (unless --no-html)
• Also append a one-line summary to tabletop-exercises/INDEX.md (create if missing) so the user has a running log of all exercises.

For the HTML, use the same styling system as RUNBOOK.html — read ~/.claude/skills/tabletop-exercise/assets/runbook-template.html as the visual reference for the styling tokens (colors, typography, callouts) and produce a leaner AAR-styled HTML in the same family. The AAR HTML is read-only by design (no timer, reveal overlays, or form persistence — it's a static report). The @media print block MUST hide the topbar, any nav/sidebar, and any buttons — a printed AAR should be clean black-on-white text with no UI chrome. Verify by mentally walking through the print rules: .topbar, aside, nav, button should all be display: none under @media print.

Step 5 — Output

Show the user:

✓ AAR drafted: tabletop-exercises/<slug>/AAR.md

  Top action items (P0/P1):
    1. [action] — [owner], by [date]
    2. ...
    3. ...

  Open AAR.html for the styled version.

Quality bar

The AAR should pass these tests:

• Specific, not generic: every finding cites a decision-log entry or a documented gap, not "communication could be improved"
• Actionable: every action item has a real owner and a real deadline, no "TBD"
• Blameless: describes behavior in terms of system gaps, not individual fault
• Prioritized: P0 items are genuinely P0 (would cause material harm if not fixed); P2s are nice-to-haves, clearly labeled
• Honest: if the team failed badly, the AAR says so. Don't sandbag findings to be polite.

Reference files

• references/aar-template.md — master AAR Markdown structure