--- name: minutes-tag description: Lightweight outcome tagging for meetings — won, lost, stalled, great, or noise. Use whenever the user says "tag this meeting", "mark that as a win", "that one was a loss", "tag yesterday's call as stalled", "mark this great", "that meeting was noise", "label that meeting", or any time they describe a meeting outcome in passing. Tagging takes 5 seconds and unlocks /minutes-mirror correlation analysis — the more meetings get tagged, the smarter mirror gets at telling the user what behavior patterns lead to wins. Surface this skill any time the user mentions a meeting result, win, loss, or wasted time. --- ## Skill Path Before running helper scripts or opening bundled references, set: ```bash export MINUTES_SKILLS_ROOT="$(git rev-parse --show-toplevel)/.agents/skills/minutes" 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 meetings . Which one?" with options listing titles. **3. By name** ("tag my call with Sarah as a win"): ```bash minutes search "" --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" \ "" \ --outcome \ [--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 **** as ****." 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 "" 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 first time tag has run on this machine. Show the nudge once, then create the marker: > "First tag — nice. When you've tagged ~10 meetings, run `/minutes-mirror trends` and I'll show you what your winning meetings have in common." ```bash mkdir -p ~/.minutes && touch ~/.minutes/tag-nudge-shown ``` The marker file is the state. No counting, no edge cases, no risk of repeated nudges from re-tagging the same meeting. ## Gotchas - **Speed is the entire feature.** If tagging takes more than two questions (the tag, optionally the note), you've broken it. Default to "most recent". Skip the optional note unless the user clearly wants to add one. - **Standard tags only correlate.** Mirror's correlation analysis only works on the five standard tags: `won`, `lost`, `stalled`, `great`, `noise`. Custom tags are saved but won't be analyzed. Warn the user once if they pick a custom tag — don't lecture them, just let them know. - **Don't touch the meeting body.** Only edit the YAML frontmatter block between the first two `---` markers. Use `Edit` with surgical precision. - **Re-tagging is intentional.** If the user tags a meeting that's already tagged, overwrite it cleanly. They're either correcting themselves or seeing it differently after the fact. Both are valid. - **Preserve existing frontmatter exactly.** Some meetings have `action_items`, `decisions`, `intents`, `entities`, `people`, `calendar_event`, `captured_at`, `device`, `recorded_by`, etc. Don't reformat or reorder anything — only insert/update the three outcome fields. - **Tag freshness matters.** Tags are most valuable within ~24 hours, while the outcome is fresh in the user's head. Tagging two weeks later is fine but worth less. Don't enforce this — just don't make tagging feel like a chore that the user puts off. - **Don't try to infer the tag from the transcript.** If the user says "tag this meeting" without saying which outcome, ask. Don't guess from the transcript — your guess will be wrong in the cases that matter most (a meeting that looks like a win on paper but actually wasn't, or vice versa). - **The note is optional for a reason.** Most users will skip it. That's fine — the tag itself is the load-bearing data. Don't make the user feel like they're underperforming if they skip the note.