minutes-debrief

# /minutes-debrief

Post-meeting analysis that reads your latest recording, compares what happened to what you planned, and surfaces decision evolution — so nothing falls through the cracks.

## How it works

This is a multi-phase interactive flow. It connects to `/minutes-prep` when a prep file exists, creating a before→after loop.

### Phase 1: Find the most recent recording

```bash
minutes list --limit 5
```

Pick the most recent recording. If there are multiple from today, ask via AskUserQuestion: "You have [N] recordings today. Which one are you debriefing?" with options listing the titles.

**If no recent recording exists:**
Say: "I don't see any recent recordings. Did you run `minutes record` and `minutes stop`? If the recording is from a specific meeting, tell me the title or date and I'll find it."

Don't proceed without a recording to debrief.

### Phase 2: Read the transcript

Use `Read` on the meeting file path. Extract from the transcript and frontmatter:

- **Decisions made** (from `decisions:` frontmatter or `## Decisions` section)
- **Action items created** (from `action_items:` frontmatter or `## Action Items` section)
- **Key discussion points** (from `## Summary` or the transcript itself)
- **Attendees** (from `attendees:` frontmatter)

### Phase 2a: No-capture sensitive meetings (capture: none)

If the frontmatter says `capture: none`, there is no transcript by design: the
meeting was designated sensitive and the recorder never ran. The debrief IS the
record. Switch to debrief-from-memory mode:

1. Read what exists: the `## Markers` section (timestamped notes typed during
   the meeting) and the frontmatter (`title`, `date`, `duration`,
   `debrief:` state).
2. Ask the user to recount the meeting: who was there, what was discussed,
   decisions, action items. Use the markers as memory joggers.
3. Write their account into the meeting file itself: fill `## Summary`,
   `## Decisions`, and `## Action Items` sections (and the matching
   frontmatter lists), then set the frontmatter `debrief:` key to `complete`.
4. If the user says it was a test or accidental trigger, set `debrief:` to
   `not-applicable` and leave the body untouched.
5. **Sensitivity is binding, not advisory.** When `sensitivity: restricted`,
   the account lives ONLY in this meeting file. Do not propagate any of it
   into other notes, summaries, knowledge bases, or week-level rollups unless
   the user explicitly asks.

Skip Phases 2 and 2b (there is no transcript and no speaker attribution);
continue with prep matching and the closing ritual as normal.

### Phase 2b: Check speaker attributions

If the meeting has a `speaker_map:` field in frontmatter, check the confidence levels:

- **All High confidence**: Speakers are confirmed — use real names throughout the debrief.
- **Any Medium confidence**: Note this — "Speakers were auto-identified (medium confidence). If the names look wrong, run: `minutes confirm --meeting <path>`"
- **No speaker_map but has SPEAKER_X labels**: The meeting has diarization but no attribution — suggest: "I see anonymous speaker labels. If you know who was in this meeting, run `minutes confirm --meeting <path>` to tag them."

This nudge is brief (one line) — don't make it a blocker.

### Phase 3: Check for matching prep

Look for a prep file that matches this meeting:

```bash
ls ~/.minutes/preps/ 2>/dev/null
```

Match logic:
1. Find `.prep.md` files from today or yesterday (within 48 hours)
2. Read each file's `person:` frontmatter field
3. Compare against the recording's `attendees:` list — match on first name, but check learned aliases before deciding there is no match:
   ```bash
   node "${CLAUDE_PLUGIN_ROOT}/hooks/lib/minutes-learn-cli.mjs" aliases "<attendee-or-person>" 2>/dev/null
   ```
   Treat all returned variants as equivalent during prep-file matching.
4. If multiple preps match → AskUserQuestion to pick which one
5. If no prep matches → standalone debrief (skip to Phase 4b)

**Phase 4a: Prep-connected debrief** (when a matching prep exists)

Read the prep file. Pull out the `goal:` field. Ask via AskUserQuestion:

"You went into this meeting wanting to: **[goal from prep]**

Did you accomplish it?"

Options:
- **A) Yes — fully resolved** → Mark as complete. Summarize what was decided.
- **B) Partially — some progress** → Ask: "What's still open?" Capture the remaining items.
- **C) No — it didn't come up or it changed** → Ask: "What happened instead?" Capture the pivot.
- **D) The goal changed during the meeting** → Ask: "What's the new direction?"

Then produce the debrief summary with the prep comparison:

Before writing the output, check for a learned debrief presentation preference:

```bash
node "${CLAUDE_PLUGIN_ROOT}/hooks/lib/minutes-learn-cli.mjs" get-presentation-focus debrief
```

If the result is:
- `decisions-first` → put Decisions before Action Items and Relationship Update
- `actions-first` → put Action Items first, then Decisions, then Relationship Update
- `relationship-first` → put Relationship Update first, then Decisions, then Action Items

If there is no preference, keep the default order below.

```
## Debrief: [Meeting Title]

### Prep vs Reality
- **Goal:** [from prep]
- **Outcome:** [resolved / partially / pivoted]
- **What changed:** [if anything]

### Decisions
- [list each decision]

### Action Items
- [list with assignee and due date]

### Relationship Update
- [any notable changes in tone, new topics, shifted priorities]
```

**Phase 4b: Standalone debrief** (no matching prep)

Produce a straightforward debrief:

Before deciding the section order, check:

```bash
node "${CLAUDE_PLUGIN_ROOT}/hooks/lib/minutes-learn-cli.mjs" get-presentation-focus debrief
```

Apply the same ordering rules if a preference exists; otherwise keep the default order below.

```
## Debrief: [Meeting Title]

### Key Decisions
- [list each decision]

### Action Items
- [list with assignee and due date]

### Notable Discussion Points
- [2-3 most significant