minutes-tag

## Skill Path

Before running helper scripts or opening bundled references, set:

```bash
export MINUTES_SKILLS_ROOT="$(git rev-parse --show-toplevel)/.opencode/skills"
export MINUTES_SKILL_ROOT="$MINUTES_SKILLS_ROOT/minutes-tag"
```

# /minutes-tag

Lightweight outcome tagging — adds an `outcome:` field to a meeting's frontmatter so `/minutes-mirror` can correlate the user's behavior with their results over time.

The whole point of this skill is **speed**. Tagging should take 5 seconds, not 5 questions. Don't be precious about it — most users will never adopt tagging if it feels like data entry.

## How it works

### Phase 1: Identify the meeting

Three patterns the user might use. **Always filter to meetings, not voice memos** — voice memos can't be "won" or "lost".

**1. Most recent** ("tag this meeting", "mark that as a win", "tag the call I just finished"):
```bash
minutes list --content-type meeting --limit 1
```
Use the most recent. **Don't ask which one** — that defeats the speed promise. The default behavior should always be "the call you just had".

**2. By date** ("tag yesterday's call", "tag the Tuesday call"):
```bash
minutes list --content-type meeting --limit 10
```
Pick the meeting matching the date. If multiple meetings match the same day, ask once: "You had <N> meetings <date>. Which one?" with options listing titles.

**3. By name** ("tag my call with Sarah as a win"):
```bash
minutes search "<name>" --content-type meeting --limit 5
```
Pick the most recent. If ambiguous, ask once.

### Phase 2: Identify the tag

If the user already named the outcome in their message ("tag that as a win"), use it directly. Don't ask again — they already told you.

If they haven't, ask via AskUserQuestion with these standard options:

- **won** — got the outcome you wanted (deal closed, decision made, agreement reached)
- **lost** — didn't get what you wanted (deal lost, idea rejected, no decision)
- **stalled** — neither — went sideways, no clear outcome, needs another meeting
- **great** — high-quality conversation regardless of outcome (insight, real connection, energy, learned something)
- **noise** — should have been an email; no value; time wasted
- **(custom)** — let the user provide their own tag

Standard tags are the only ones `/minutes-mirror` will correlate. Custom tags are stored faithfully but won't appear in correlation analysis — warn the user gently if they pick a custom one: "Custom tags are saved, but mirror only correlates the standard five."

### Phase 3: Capture a note **only if the user gave one in their message**

**Do not ask an interactive note question.** That's a second prompt and it breaks the speed promise.

Parse the user's original message for a "why" or note. Common patterns:
- "tag as won, **note: Sarah committed to monthly billing**" → note = "Sarah committed to monthly billing"
- "tag won — **got the verbal commit on pricing**" → note = "got the verbal commit on pricing"
- "tag stalled **because Alex postponed the decision**" → note = "Alex postponed the decision"

If you find a note in the message, use it. If you don't, **leave `outcome_note` out of the frontmatter entirely**. Don't insert an empty field. Don't ask. Users who want a fuller record have `/minutes-debrief` for that.

### Phase 4: Edit the frontmatter via the bundled helper script

**Use the script — do not Edit the frontmatter manually.** YAML frontmatter is fragile, and the script handles all the edge cases (no existing frontmatter, existing outcome that needs replacement, atomic write to prevent half-edits, preservation of all other fields).

```bash
python3 "$MINUTES_SKILL_ROOT/scripts/tag_apply.py" \
  "<absolute-path-to-meeting-file>" \
  --outcome <won|lost|stalled|great|noise|custom> \
  [--note "the optional one-line note from Phase 3"]
```

Pass `--note` only if Phase 3 found a note in the user's message. Skip the flag entirely otherwise — the script will omit `outcome_note` from the frontmatter rather than inserting an empty field.

**What the script guarantees:**

- The new fields (`outcome`, `outcome_note` if a note was passed, `tagged_at`) are inserted just before the closing `---` of the frontmatter, after every other existing field.
- All other frontmatter fields are preserved **byte-for-byte** — no reordering, no reformatting, no whitespace changes.
- Re-tagging is fully idempotent: if `outcome:` already exists, the script removes the old outcome lines and re-inserts fresh ones at the end. Old `outcome_note:` is dropped if no new note is passed.
- The body of the meeting file is never touched — only the frontmatter block.
- Writes are atomic (temp file + rename) so an interrupted run can never leave a half-written meeting.

The script prints `{"status": "ok", ...}` to stdout on success, or `{"error": "..."}` to stderr with non-zero exit on failure. Surface any error to the user.

**Fallback if Python isn't available** (extremely rare on macOS): use the `Edit` tool with surgical precision. Find the closing `---` of the frontmatter, anchor on a small unique block ending in it, and insert your new fields right before. This is brittle on unusual frontmatter — only do it if the script fails.

### Phase 5: Confirm and nudge

Confirm in **one line**: "Tagged **<meeting title>** as **<outcome>**."

Then verify the file is still parseable by Minutes after the edit. The slug is the filename minus `.md` (e.g., `2026-03-18-product-roadmap-with-case`):

```bash
minutes get "<filename-without-.md>" 2>&1 | head -3
```

If the output contains an error or warning about malformed frontmatter, surface it gently: "Note: this meeting's frontmatter has a pre-existing schema issue. The tag was saved, but `/minutes-mirror` may skip this meeting until it's fixed." Don't try to fix the unrelated schema issue — that's not tag's job.

**One-time lifetime nudge** (idempotent — never repeats):
```bash
ls ~/.minutes/tag-nudge-shown 2>/dev/null
```

If that marker file doesn't exist, this is the firs