Before running helper scripts or opening bundled references, set:
\nexport MINUTES_SKILLS_ROOT=\"$(git rev-parse --show-toplevel)/.opencode/skills\"\nexport MINUTES_SKILL_ROOT=\"$MINUTES_SKILLS_ROOT/minutes-tag\"\nLightweight 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.
\nThree patterns the user might use. Always filter to meetings, not voice memos — voice memos can't be \"won\" or \"lost\".
\n1. Most recent (\"tag this meeting\", \"mark that as a win\", \"tag the call I just finished\"):
\nminutes list --content-type meeting --limit 1\nUse the most recent. Don't ask which one — that defeats the speed promise. The default behavior should always be \"the call you just had\".
\n2. By date (\"tag yesterday's call\", \"tag the Tuesday call\"):
\nminutes list --content-type meeting --limit 10\nPick the meeting matching the date. If multiple meetings match the same day, ask once: \"You had
\n3. By name (\"tag my call with Sarah as a win\"):
\nminutes search \"<name>\" --content-type meeting --limit 5\nPick the most recent. If ambiguous, ask once.
\nIf 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.
\nIf they haven't, ask via AskUserQuestion with these standard options:
\nStandard 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.\"
Do not ask an interactive note question. That's a second prompt and it breaks the speed promise.
\nParse the user's original message for a \"why\" or note. Common patterns:
\nIf 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.
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).
\npython3 \"$MINUTES_SKILL_ROOT/scripts/tag_apply.py\" \\\n \"<absolute-path-to-meeting-file>\" \\\n --outcome <won|lost|stalled|great|noise|custom> \\\n [--note \"the optional one-line note from Phase 3\"]\nPass --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:
\noutcome, outcome_note if a note was passed, tagged_at) are inserted just before the closing --- of the frontmatter, after every other existing field.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 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.
Confirm in one line: \"Tagged as .\"
\nThen 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):
minutes get \"<filename-without-.md>\" 2>&1 | head -3\nIf 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):
\nls ~/.minutes/tag-nudge-shown 2>/dev/null\nIf 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:
\n\n\n\"First tag — nice. When you've tagged ~10 meetings, run
\n/minutes-mirror trendsand I'll show you what your winning meetings have in common.\"
mkdir -p ~/.minutes && touch ~/.minutes/tag-nudge-shown\nThe marker file is the state. No counting, no edge cases, no risk of repeated nudges from re-tagging the same meeting.
\nwon, 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.--- markers. Use Edit with surgical precision.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.