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

Run `minutes get "<exact path>" --json`, require exit status 0, and use only the
returned transcript and frontmatter. Never reopen the list path with the host
`Read` tool. Extract:

- **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 authorized 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. Use the already-authorized response: 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. Present the account in the conversation, but do not edit the meeting path
   through a host filesystem tool. Until Minutes exposes a native authorized
   debrief-update command, ask the user to persist it in the desktop app or a
   human-operated CLI flow.
4. If the user says it was a test or accidental trigger, report that conclusion
   without mutating the source path from this skill.
5. **Sensitivity is binding, not advisory.** A restricted meeting is not
   available to this agent skill by default. Do not bypass a failed native
   read; direct the user to a human-operated Minutes app/CLI flow with the
   explicit audited restricted-access controls.

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