after-action

name	after-action
description	After-action report skill for producing structured, succinct summaries of completed missions. Use after any multi-step task, implementation, review, or operational mission to give the user a clear picture of what happened, what changed, and what remains. Covers mission debrief, change inventory, officer contributions, decision log, and follow-up items.

After-Action Report

Structured debrief format for summarizing completed missions. The goal is maximum clarity in minimum words — the user should be able to read this in under 60 seconds and know exactly what happened.

When to Produce

Generate an after-action report:

• At the end of any mission that involved 2+ officers or 2+ phases
• After any implementation that changed files in the repository
• After any operational task that modified live systems
• When the user asks "what happened?" or "give me a summary"
• When handing off between Picard and the user at mission end

Do NOT generate for trivial single-step tasks (one file edit, one command run).

Report Structure

Use this template. Omit sections that don't apply — an empty section is worse than a missing one.

## After-Action Report

**Mission:** [One-sentence description of what was requested]
**Classification:** [Mission type and profile used, e.g., "Quick Fix" or "Full Mission"]
**Status:** [Complete | Partial | Blocked]

### What Changed

[Bulleted list of concrete changes. Be specific — file paths, config values, commit SHAs.]

- `path/to/file.ts` — Added rate limiting middleware (feat: add rate limiter, abc1234)
- `path/to/config.yaml` — Updated timeout from 30s to 60s
- `src/server/ck3/validation/` — New scope validator module created

### Who Did What

[One line per officer who contributed. Name, what they did, outcome.]

- **Data** — Researched existing middleware patterns, identified 3 candidates
- **Riker** — Coordinated implementation: dispatched Scotty (code) + Wesley (tests)
- **Scotty** — Implemented rate limiter in `src/middleware/rateLimit.ts` (45 lines)
- **Wesley** — Wrote 12 test cases, all passing
- **Crusher** — Code review: APPROVED, no issues
- **Worf** — Security scan: CLEAR, no vulnerabilities

### Reviews

[Verdicts from review officers. Only include if reviews were conducted.]

| Reviewer | Verdict | Notes |
|----------|---------|-------|
| Crusher | APPROVED | Clean implementation, good error handling |
| Worf | CLEAR | No injection vectors, input properly validated |
| Troi | ALIGNED | Delivers requested functionality |

### Decisions Made

[Any choices that were made during the mission — by the captain, by officers, or by the user.]

- Selected Express middleware pattern over custom HTTP interceptor (La Forge recommendation)
- Chose 100 req/min default limit (user confirmed)

### Outstanding Items

[Anything not finished, deferred, or needing follow-up. Empty = nothing outstanding.]

- [ ] Performance testing under load (Barclay — deferred, not blocking)
- [ ] Update API documentation to reflect rate limit headers (Guinan — next sprint)

### Commits

[List of commits created during this mission, if any.]

| SHA | Message |
|-----|---------|
| `abc1234` | feat: add rate limiter middleware |
| `def5678` | test: add rate limiter test suite |

Writing Guidelines

Be Concrete, Not Abstract

Bad: "Made improvements to the authentication system." Good: "Added JWT token refresh logic in src/auth/refresh.ts. Tokens now auto-refresh 5 minutes before expiry."

Bad: "Several files were updated." Good: "Modified 3 files: src/auth/refresh.ts (new), src/auth/middleware.ts (updated), src/auth/types.ts (updated)."

Be Succinct, Not Verbose

Each bullet should be one line. If you need two sentences, the second sentence probably belongs in a sub-bullet or a different section. The user is busy — respect their time.

Include the "Why" for Decisions

Don't just state what was decided — state why, in a short clause:

• "Selected Redis over in-memory cache — data must survive restarts"
• "Deferred performance testing — user confirmed not blocking for this PR"

Status Definitions

Status	Meaning
Complete	All requested work done, all reviews passed, no blockers
Partial	Some work done, remaining items listed in Outstanding
Blocked	Cannot proceed without user input or external dependency

Review Verdicts

Verdict	Meaning
APPROVED	Code review passed, no blocking issues
CLEAR	Security scan passed, no vulnerabilities found
ALIGNED	Value assessment confirms implementation matches request
CHANGES REQUESTED	Issues found, listed in notes — not ready to merge
CRITICAL	Blocking security or correctness issue — must fix before proceeding

Partial Reports

When a mission is still in progress but a checkpoint summary is needed (user asks "where are we?"), use this abbreviated format:

## Mission Status

**Mission:** [One sentence]
**Phase:** [Current phase, e.g., "Phase 2: Implementation"]

### Completed
- [What's done so far]

### In Progress
- [Who is working on what right now]

### Remaining
- [What hasn't started yet]

### Blockers
- [Anything preventing progress, if any]