Minutes Tag

Skill Path

Before running helper scripts or opening bundled references, set:

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"):

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"):

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"):

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).

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.