opencode Claude Skill

minutes-tag

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

LLM Mart · 0 points · 19 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download silverstein-minutes-.opencode_skills_minutes-tag-e56450a.zip · 6 KB

silverstein/minutes 1501 165 forks MIT Updated 9h ago

Part of silverstein/minutes — 155 skills

Install

skills CLI npx skills add https://github.com/silverstein/minutes/tree/main/.opencode/skills/minutes-tag

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install silverstein-minutes@llmmart

Git git clone https://github.com/silverstein/minutes.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole silverstein/minutes collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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

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.

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

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

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

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.

Files (minutes)

scripts

tag_apply.py 5.7 KB

#!/usr/bin/env python3
"""
tag_apply.py — Atomic outcome tagging for a meeting's YAML frontmatter.

Used by the /minutes-tag skill to avoid Edit-tool fragility on unusual
frontmatter. Inserts or updates the `outcome:`, `outcome_note:` (optional),
and `tagged_at:` fields just before the closing `---` of the frontmatter,
preserving everything else exactly.

Usage:
    tag_apply.py <meeting_file.md> --outcome won [--note "Sarah committed to monthly"]

Output: writes the file back atomically (temp file + rename). Prints
        {"status": "ok", ...} JSON to stdout on success, or
        {"error": "..."} to stderr with non-zero exit on failure.

Requires: Python 3.8+, stdlib only. No YAML parser — does line-based edits
to keep formatting and ordering of existing fields stable.
"""

from __future__ import annotations

import argparse
import datetime
import json
import os
import sys
from pathlib import Path

OUTCOME_FIELDS = ("outcome", "outcome_note", "tagged_at")


def find_frontmatter_bounds(lines: list[str]) -> tuple[int, int] | None:
    """Return (start_index_inclusive, end_index_exclusive) of frontmatter content
    lines (excluding the surrounding `---` markers). Returns None if no
    well-formed frontmatter block exists.
    """
    if not lines or lines[0].rstrip("\r\n") != "---":
        return None
    for i in range(1, len(lines)):
        if lines[i].rstrip("\r\n") == "---":
            return (1, i)
    return None


def is_outcome_field_line(line: str) -> bool:
    stripped = line.lstrip()
    if line[: len(line) - len(stripped)]:  # has leading whitespace → not top-level
        return False
    for field in OUTCOME_FIELDS:
        if stripped.startswith(f"{field}:"):
            return True
    return False


def yaml_quote(value: str) -> str:
    """Quote a value safely for YAML inline use. Uses JSON-style double quotes,
    which YAML accepts and which round-trip cleanly through any YAML parser.
    """
    return json.dumps(value, ensure_ascii=False)


def update_frontmatter(content: str, outcome: str, note: str | None) -> str:
    today = datetime.date.today().isoformat()

    # Build the canonical outcome lines we want to end up with.
    new_outcome_lines = [f"outcome: {outcome}\n"]
    if note:
        new_outcome_lines.append(f"outcome_note: {yaml_quote(note)}\n")
    new_outcome_lines.append(f"tagged_at: {today}\n")

    lines = content.splitlines(keepends=True)
    bounds = find_frontmatter_bounds(lines)

    if bounds is None:
        # No frontmatter at all — synthesize one.
        new_fm = ["---\n"] + new_outcome_lines + ["---\n"]
        if content and not content.startswith("\n"):
            new_fm.append("\n")
        return "".join(new_fm) + content

    start, end = bounds
    # Strip any pre-existing outcome field lines from the frontmatter body.
    cleaned_fm = [line for line in lines[start:end] if not is_outcome_field_line(line)]

    # Make sure the last cleaned line ends with a newline so our insertions sit cleanly.
    if cleaned_fm and not cleaned_fm[-1].endswith("\n"):
        cleaned_fm[-1] = cleaned_fm[-1] + "\n"

    new_lines = lines[:start] + cleaned_fm + new_outcome_lines + lines[end:]
    return "".join(new_lines)


def main() -> int:
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("meeting_file", type=Path)
    parser.add_argument(
        "--outcome",
        required=True,
        help="Outcome tag (e.g. won, lost, stalled, great, noise, or a custom value)",
    )
    parser.add_argument(
        "--note",
        default=None,
        help="Optional one-line note about why",
    )
    args = parser.parse_args()

    if not args.meeting_file.exists():
        print(json.dumps({"error": f"file not found: {args.meeting_file}"}), file=sys.stderr)
        return 1
    if not args.meeting_file.is_file():
        print(json.dumps({"error": f"not a file: {args.meeting_file}"}), file=sys.stderr)
        return 1

    # Capture the original file mode BEFORE any writes so we can restore it
    # after the atomic replace. Without this, a meeting at 0600 (private) would
    # come back as 0644 (world-readable) because the temp file is created with
    # default perms — a real privacy regression for users who manually lock
    # down sensitive meetings. Caught by external code review.
    try:
        original_mode = args.meeting_file.stat().st_mode
    except OSError as exc:
        print(json.dumps({"error": f"stat failed: {exc}"}), file=sys.stderr)
        return 1

    try:
        content = args.meeting_file.read_text(encoding="utf-8")
    except Exception as exc:
        print(json.dumps({"error": f"read failed: {exc}"}), file=sys.stderr)
        return 1

    new_content = update_frontmatter(content, args.outcome, args.note)

    # Atomic write: write to a sibling temp file, copy the original's mode onto
    # it, then rename over the original. Setting the mode BEFORE the rename
    # means there's no window where the file exists with the wrong perms.
    temp = args.meeting_file.with_suffix(args.meeting_file.suffix + ".tmp")
    try:
        temp.write_text(new_content, encoding="utf-8")
        os.chmod(temp, original_mode)
        temp.replace(args.meeting_file)
    except Exception as exc:
        if temp.exists():
            try:
                temp.unlink()
            except OSError:
                pass
        print(json.dumps({"error": f"write failed: {exc}"}), file=sys.stderr)
        return 1

    print(
        json.dumps(
            {
                "status": "ok",
                "file": str(args.meeting_file),
                "outcome": args.outcome,
                "note": args.note,
            }
        )
    )
    return 0


if __name__ == "__main__":
    sys.exit(main())

SKILL.md 8.8 KB

---
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.
compatibility: opencode
---

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