rsc-universal 0.1.1

package/skills/medium-writing/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: medium-writing
+description: "Use when crafting or rewriting ONE Medium story so it earns reads, claps, and Boost curation — writing the title/subtitle/kicker as a hook system, fixing a story that gets views but a low read ratio (title over-promises, intro buries the payoff, wall-of-text body), making a draft scannable and curation-eligible, or reshaping a blog post/newsletter into Medium-native form. Triggers: 'write a Medium article that gets read', 'my Medium post gets views but nobody finishes it', 'fix my read ratio', 'give me a title subtitle and kicker', 'make this Boost-eligible', 'curation-worthy Medium draft', 'escribe un artículo de Medium que enganche desde el primer párrafo', 'fes que aquest esborrany de Medium sigui llegible'. NOT scheduling/publishing/tags/submitting to a publication (that is medium-publishing), and NOT deciding what topics or cadence to write (that is medium-strategy)."
+tags: [medium, writing, headlines, hooks, read-ratio, curation, boost, formatting]
+recommends: [medium-publishing, medium-strategy, brand-voice, article-writing, content-engine]
+origin: risco
+---
+
+# Medium Writing — One Story That Gets Read
+
+*You produce a single paste-ready Medium story: the hook system, the first screen, the scannable body, the images, the alt text — tuned for the two metrics Medium's 2026 model rewards. You do not publish it and you do not decide what to write.*
+
+You own the **craft of one Medium story**. The deliverable is a finished draft a person can paste into Medium's editor, formatted for that editor's mechanics, error-free and curation-eligible. Three things are explicitly out of scope:
+
+- **Publishing mechanics** — connecting the account, scheduling, tags, choosing/submitting to a publication, canonical/import, distribution status. That is `medium-publishing`.
+- **Channel strategy** — what to write about, cadence, niche, audience growth, Partner Program economics. That is `medium-strategy`.
+- **The brand's reusable voice definition** — that is [`../brand-voice/SKILL.md`](../brand-voice/SKILL.md). This skill *applies* a voice; it does not author one. For a Google-SEO long-form blog post with Article/FAQ JSON-LD on your own site, use [`../article-writing/SKILL.md`](../article-writing/SKILL.md) — Medium owns its own on-page surface, so schema is irrelevant here.
+
+## The two numbers that govern every choice
+
+Medium's recommendation model is per-article and turns on two funnel ratios, not your follower count or tenure. Optimize for these or nothing else matters.
+
+| Number | Rule-of-thumb aim | What it means | What earns it |
+|---|---|---|---|
+| Impressions → views | >10% | People who saw the card clicked it | Title + subtitle + cover |
+| Views → reads | >50% | People who clicked stayed 30s+ | The first screen delivering the title's promise |
+
+The two ratios are real and authoritative; the specific >10% and >50% targets are **community rule-of-thumb benchmarks**, not numbers Medium publishes. Treat them as "good enough to clear the bar," not as Medium's stated model. What Medium *does* document: a member read counts at **30s+**, and the read ratio "adjusts" earnings up or down (Help Center, "Medium Partner Program earnings calculation").
+
+Rule: **the title earns the click, the first screen earns the read, and there can be no gap between them.** Why: the read ratio (members who read 30s+ ÷ members who loaded the story) adjusts your earnings and explicitly penalizes stories that "attract clicks but do not deliver on the promise of their title or preview" — verbatim from Medium's Distribution Guidelines. A title that over-promises does not just under-perform; it is taxed. (This penalty is about the title/preview promise, not story length — long reads are not penalized for being long.)
+
+Rule: **claps feed the recommendation engine.** Why: passing roughly 200 claps materially raises the chance Medium surfaces the story to new readers, so write something a reader wants to applaud at the end, not just open.
+
+## Title + subtitle + kicker = one hook system
+
+These three are one mechanism, not three decorations. Write them together, last, after the body exists — you cannot promise what you have not yet delivered.
+
+Pick a title archetype to match the payoff:
+
+| Archetype | Use when | Example |
+|---|---|---|
+| Specific result | You have a concrete number/outcome | "How I Cut Our Build Time From 14 Minutes to 90 Seconds" |
+| Contrarian | You disagree with received wisdom | "Stop Writing Unit Tests First" |
+| How-to | The value is a repeatable method | "A 4-Step Way to Debug Any Flaky Test" |
+| Narrative-I | The lesson rides on your story | "I Shipped to Production on Day One. Here's What Broke." |
+| Question | The reader shares the open question | "Why Does Every Postgres Index Slow Down My Writes?" |
+
+The **subtitle extends and qualifies the title** — it is indexed for on-Medium and external search and is the preview text under the title, so it is load-bearing, never filler. Use it to add the specificity the title leaves out.
+
+- Bad → title "How I Cut Our Build Time" / subtitle "A story about CI."
+- Good → title "How I Cut Our Build Time From 14 Minutes to 90 Seconds" / subtitle "The fix was three lines of cache config — but finding them took a week of profiling."
+
+The **kicker** is a short phrase that frames the category, e.g. "Engineering" or "Lessons From a Failed Launch." It sets context before the title lands.
+
+**Strong, not sensational.** Boost curation rejects shocking or sensational titles, subtitles, and covers. A strong title makes a specific, deliverable promise; a sensational one manufactures alarm or withholds to bait the click. "How I Cut Our Build Time From 14 Minutes to 90 Seconds" is strong. "This One Trick Will SHOCK Your DevOps Team" is sensational and disqualifying. The full archetype library, with annotated Bad→Good pairs and the sensational-vs-strong line, is in [`references/title-patterns.md`](references/title-patterns.md).
+
+## The first screen earns the read
+
+The read ratio is won or lost above the first scroll. The reader arrived because the title made a promise; pay it immediately.
+
+- Rule: **open on the promise within ~3 sentences.** Why: every sentence of warm-up is a sentence in which a member can bounce before the 30-second read counts.
+- Rule: **kill the meta-throat-clearing.** Delete "In this article, I'll…", "Before we dive in…", "We've all been there…". Why: it announces the article instead of being the article, and it reads as AI filler to curators.
+- Rule: **land one concrete payoff before the first scroll.** Why: a number, a result, a sharp claim, or the single most useful line — proof the promise is real.
+
+Bad → "Performance is something every engineer cares about. In this post, I want to share some thoughts on build times and why they matter to teams like ours."
+
+Good → "Our CI took 14 minutes. After a week of profiling, three lines of cache config took it to 90 seconds. Here is exactly what those three lines were and how I found them."
+
+## Scannable body
+
+Most readers scan before they commit. Build the page so a scan still delivers value.
+
+- **Section headers are scan anchors.** Let a reader lock onto the part they want; one header per distinct idea.
+- **One idea per short block.** Paragraphs of 1–3 sentences. A wall of text is the second-most-common read-ratio killer after a weak first screen.
+- **Pull-quote the one screenshot-worthy line.** Exactly one per story — the line you would want someone to share.
+- **Drop cap is optional** and at most once, at the open.
+- Rule: **less is more on styling.** Why: over-mixing drop caps, pull-quotes, bold runs, and embeds reads amateur and distracts from the argument; pick the few that earn their place.
+
+## Images and alt text
+
+- The **cover image sets the preview card** alongside the title and subtitle — it participates in impressions→views, and like the title it must not be sensational.
+- **In-body images break long text stretches** and give the eye a rest; place one before any section that runs long.
+- Rule: **every image gets alt text.** Why: it is an accessibility requirement and a free relevance signal; describe the image's content, not "image1.png".
+
+## Boost-eligibility pass
+
+Boost is human curation against Medium's Distribution Guidelines, and publications/editors remain a main discovery path into it — so the bar is "reads like a curated publication piece." (Medium closed the Boost Nomination Program on 2026-05-31 and is replacing it with an Editor Partner Program, expanded in July 2026; the *Distribution Guidelines applied to Boost are unchanged*, so this gate still holds.) Before delivering, run this gate — every item must pass:
+
+- [ ] **Error-free** — spelling, grammar, broken links, and formatting all clean. Copyediting is gating, not cosmetic.
+- [ ] **Appropriately sourced** — claims, stats, and quotes attributed with links; nothing asserted bare.
+- [ ] **Narratively strong** — a clear arc with a beginning, a middle, and a payoff; not a loose list of tips.
+- [ ] **Not sensational** — title, subtitle, and cover are strong but not shocking, explicit, or alarmist.
+- [ ] **Human-written** — AI-generated content is not Boost-eligible; the prose must read as the author's, with specific lived detail, not generic.
+- [ ] **Not aggressively promotional** — a sales pitch dressed as an article is deprioritized.
+
+(The 180-day freshness window is a publishing-time concern — `medium-publishing` owns it. Your job is that the craft passes the moment it is published.)
+
+## Editor mechanics — label the structural lines
+
+Medium's editor derives structure from formatting, not metadata: the **first line** of the story is the title (large "T"), the line directly below it formatted small "t" is the **subtitle**, and a **kicker** is a short phrase on a line *above* the title, also small "t". Mis-formatting these can render the story **ineligible for curation**. So the delivered draft must label them explicitly so the author applies the right formatting:
+
+```text
+KICKER:   Engineering
+TITLE:    How I Cut Our Build Time From 14 Minutes to 90 Seconds
+SUBTITLE: The fix was three lines of cache config — but finding them took a week of profiling.
+
+[body starts here…]
+```
+
+Tell the author plainly: in Medium's editor, type the kicker line first and format it small "t", then the title as the large "T" line, then the subtitle small "t" directly under it.
+
+## Learn from the author's stats (02-DOCS)
+
+If `02-DOCS/` exists, learn before you write:
+
+- Read raw exports under `02-DOCS/raw/medium/` and any compiled patterns under `02-DOCS/wiki/medium/`.
+- Bias toward the title/subtitle patterns and topics that historically beat a 50% read ratio for *this* author; avoid angles that drew clicks but bounced.
+- After a notable result, append the learned pattern to `02-DOCS/wiki/medium/read-ratio-patterns.md` so the next draft inherits it.
+
+If `02-DOCS/` is absent, proceed from the craft defaults above and say so in one line, rather than inventing stats.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+|---|---|---|
+| Sensational title ("SHOCKING", "You won't believe…") | Disqualifies the story from Boost curation | Strong, specific, deliverable promise |
+| Title over-promises the body | Member read ratio penalizes the click-gap and taxes earnings | Write title + subtitle last, only promise what the body delivers |
+| Warm-up intro ("In this article, I'll…") | Members bounce before the 30s read counts | Open on the promise in ~3 sentences with a concrete payoff |
+| Wall of text | Scanners leave; read ratio drops | Section headers, 1–3 sentence blocks, one idea per block |
+| Over-styled (drop cap + 5 pull-quotes + bold everywhere) | Reads amateur; distracts from the argument | Less is more; one pull-quote, headers, sparing bold |
+| Generic AI-tell prose, no lived detail | Not Boost-eligible; readers don't clap | Specific numbers, names, and first-hand detail in the author's voice |
+| Claims with no sources | Fails the "appropriately sourced" curation gate | Attribute every stat/quote with a link |
+
+## Cross-references
+
+- Publish, schedule, tag, or submit the finished draft → `medium-publishing`.
+- Decide topics, cadence, niche, monetization → `medium-strategy`.
+- Define the reusable voice this draft writes in → [`../brand-voice/SKILL.md`](../brand-voice/SKILL.md).
+- A Google-SEO blog post with JSON-LD on your own site → [`../article-writing/SKILL.md`](../article-writing/SKILL.md).
+- A multi-channel editorial calendar/pipeline → [`../content-engine/SKILL.md`](../content-engine/SKILL.md).

package/skills/medium-writing/evals/README.md

@@ -0,0 +1,5 @@
+# Evals — medium-writing
+
+`cases.yaml` holds the trigger and capability cases for this skill. There is no automated runner here and no `verify.sh`: the output is prose (a Medium draft), not a checkable artifact, so rigor lives in the capability eval rather than a script.
+
+To run by hand, feed each `should_trigger` prompt to the agent and confirm it engages `medium-writing`; feed each `should_not_trigger` prompt and confirm it routes to the named sibling (`medium-publishing`, `medium-strategy`, `article-writing`, `brand-voice`) instead. For the `capability` case, give the agent the scenario draft and grade the result against every line in `must_include` — most load-bearing are the no-clickbait-gap between title and first screen, the explicit KICKER/TITLE/SUBTITLE labels, and an honest sensational-vs-strong Boost verdict.

package/skills/medium-writing/evals/cases.yaml

@@ -0,0 +1,39 @@
+skill: medium-writing
+
+should_trigger:
+  - prompt: "Write a Medium article about how we cut our build times, one that'll actually get read."
+    why: Core case — drafting one paste-ready Medium story tuned for the read ratio.
+  - prompt: "My Medium post gets thousands of views but the read ratio is terrible and nobody finishes it. Fix it."
+    why: Non-obvious symptom — high views, low completion points at a title/body gap and a weak first screen, both this skill's craft.
+  - prompt: "Give me a title, subtitle and kicker for this Medium story."
+    why: The hook system written as one coupled mechanism.
+  - prompt: "Make this Medium draft Boost-eligible and curation-worthy."
+    why: The curation-craft gate (error-free, sourced, narratively strong, not sensational, human-written).
+  - prompt: "Turn my newsletter issue into a Medium story that hooks from the first paragraph."
+    why: Adapting existing long-form into Medium-native shape with a first-screen hook.
+  - prompt: "Convierte este artículo en un post de Medium que enganche desde el primer párrafo."
+    why: Spanish phrasing for the same first-screen / hook craft.
+
+should_not_trigger:
+  - prompt: "Schedule this draft and submit it to the Better Programming publication with tags."
+    route_to: medium-publishing
+    why: Scheduling, publication submission, and tags are publishing mechanics, not story craft.
+  - prompt: "What should I write about on Medium and how often should I post?"
+    route_to: medium-strategy
+    why: Topic/niche selection and cadence are channel strategy, not the craft of one story.
+  - prompt: "Write an SEO blog post with FAQPage and Article JSON-LD schema for my own website."
+    route_to: article-writing
+    why: On-site SEO long-form with on-page schema; Medium owns its own surface so schema is irrelevant here.
+  - prompt: "Define the tone of voice for my Medium account so everything sounds consistent."
+    route_to: brand-voice
+    why: Authoring the reusable voice definition, not applying it to one story.
+
+capability:
+  - scenario: "Given a topic ('we deleted 40% of our tests and shipped faster') plus a rough, rambling draft, produce a Medium-ready package."
+    must_include:
+      - "Three title+subtitle+kicker options drawn from distinct archetypes (e.g. specific-result, contrarian, narrative-I)."
+      - "A rewritten first screen that opens on the promise within ~3 sentences and lands a concrete payoff before the first scroll, with no 'in this article' warm-up."
+      - "A scannable section-header structure (headers as scan anchors, short blocks)."
+      - "Explicit KICKER / TITLE / SUBTITLE labels so the author formats the editor's structural lines correctly."
+      - "A Boost-eligibility verdict checking sensational vs strong, sourcing, error-free, and human-written."
+      - "Prose in rsc voice with specific lived detail and no AI-tell filler."

package/skills/medium-writing/references/title-patterns.md

@@ -0,0 +1,79 @@
+# Title / subtitle / kicker pattern library
+
+The hook system is three coupled lines: the **title** earns the click, the **subtitle** extends and qualifies it (and is search-indexed and shown as preview text), the **kicker** frames the category. Write all three after the body exists, so you only promise what you deliver. Strong always; sensational never (sensational disqualifies the story from Boost).
+
+## Title archetypes
+
+Each archetype below carries when-to-use and two annotated examples. Match the archetype to the kind of payoff your body actually contains.
+
+### Specific result
+
+Use when the body lands a concrete, quantified outcome. The number is the hook.
+
+- "How I Cut Our Build Time From 14 Minutes to 90 Seconds" — the gap (14m → 90s) is the promise; the body must show exactly how.
+- "We Deleted 40% of Our Tests and Shipped Faster" — counter-intuitive number; works because it names a measurable result, not a vibe.
+
+### Contrarian
+
+Use when you genuinely disagree with received wisdom and can defend it. The tension is the hook.
+
+- "Stop Writing Unit Tests First" — sets up a real argument; only works if the body earns the claim with reasoning.
+- "Your Microservices Are Probably a Mistake" — "probably" keeps it honest rather than absolutist; the body must qualify *when*.
+
+### How-to
+
+Use when the value is a repeatable method the reader can apply tomorrow.
+
+- "A 4-Step Way to Debug Any Flaky Test" — the step count signals scope and finishability.
+- "How to Read a Postgres Query Plan Without Guessing" — names the pain ("without guessing") the method removes.
+
+### Listicle with teeth
+
+Use when you have a genuine set of distinct, non-obvious items — not filler padded to a round number.
+
+- "5 Postgres Indexes That Quietly Slow Down Writes" — specific domain + a non-obvious angle; each item must be real.
+- Bad version: "10 Amazing Tips for Better Code" — round number, no specificity, no teeth. Avoid.
+
+### Narrative first-person
+
+Use when the lesson rides on something that happened to you. The story is the hook; the lesson is the payoff.
+
+- "I Shipped to Production on Day One. Here's What Broke." — concrete stakes, promises a reckoning.
+- "I Spent Three Months on a Feature Nobody Used" — vulnerability + a clear lesson the reader can avoid.
+
+### Question
+
+Use when the reader carries the same open question and your body answers it.
+
+- "Why Does Every Postgres Index Slow Down My Writes?" — the answer must be in the body, not teased.
+- Bad version: "Is This the End of REST APIs?" — rhetorical bait with no committed answer. Avoid.
+
+## Subtitle: do and don't
+
+The subtitle is the preview text under the title and is indexed for search. Treat it as the second half of the promise.
+
+- Do: add the specificity the title omits. Title "How I Cut Our Build Time" → subtitle "The fix was three lines of cache config — but finding them took a week of profiling."
+- Do: name the payoff or the catch. It should make the click more, not less, likely once the reader knows what's inside.
+- Don't: restate the title in other words ("A story about CI build performance").
+- Don't: leave it decorative or empty ("Read on to find out"). That wastes an indexed line and a preview slot.
+
+## Kicker: examples
+
+A short framing phrase above the title. It orients the reader's expectation.
+
+- Category: "Engineering", "Product", "Career".
+- Series/angle: "Lessons From a Failed Launch", "Notes From Production".
+- Keep it short — a phrase, not a sentence. It is not a second subtitle.
+
+## Sensational vs. strong
+
+Boost curation rejects shocking or sensational hooks. The difference is a deliverable promise versus manufactured alarm or withheld payoff.
+
+| Sensational (disqualifying) | Strong (curation-friendly) |
+|---|---|
+| "This One Trick Will SHOCK Your DevOps Team" | "The Cache Config That Cut Our Build Time 90%" |
+| "You're Doing Testing ALL WRONG" | "Why Writing Tests First Slowed My Team Down" |
+| "The TRUTH About Microservices Nobody Tells You" | "When Microservices Cost Us More Than They Saved" |
+| "I Almost QUIT Engineering Forever…" | "The Burnout Quarter That Changed How I Plan Work" |
+
+The tell: a sensational hook relies on caps, superlatives, vague menace, or a withheld reveal to bait the click; a strong hook states a specific, real, deliverable claim and trusts the reader to want it.

package/skills/meeting-notes/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: meeting-notes
+description: "Use when a meeting, standup, or call just ended and you have a transcript or rough notes to turn into a durable record — extract the decisions with their why, assign action items with an owner and a real due date, flag open questions, and ship a one-screen recap within 24–48h. Also when an AI-notetaker transcript hallucinated tasks or mixed up speakers and you must clean it before sending. Triggers: 'pull the action items out of this transcript and tell me who owns what by when', 'the Otter transcript mixed up who said what, clean it up so I can send it', 'resume la reunión de hoy y saca los próximos pasos con responsable y fecha límite', 'fes una acta de la reunió'. NOT the durable decision record with full alternatives and review cadence (that is decision-records)."
+tags: [meeting-notes, action-items, decisions, recap, transcript-cleanup, minutes, standup, business-ops]
+recommends: [decision-records, sop-builder, project-ops, calendar-scheduling, notion-connector, automation-flows, document-processing]
+origin: risco
+---
+
+# Meeting Notes — Make the Meeting Count
+
+*The meeting just ended. Pull the decisions and the why, assign the actions with owners and real dates, flag what's still open, and ship a record someone who missed it can act on.*
+
+You own the **point-in-time meeting record**: take a transcript or raw notes, separate signal from noise, and emit a curated artifact — decisions (with rationale), action items (owner + due date), open questions, and a one-screen TL;DR. The output is human-readable judgment, not a code file.
+
+## What this owns vs. what it does not
+
+- The **durable decision record** — full rationale, alternatives weighed, reversibility framing, review cadence → [`decision-records`](../decision-records/SKILL.md). This skill *captures* a decision in its meeting context and hands the heavy ADR off; it does not maintain the long-lived artifact.
+- A **reusable step-by-step procedure / runbook** → [`sop-builder`](../sop-builder/SKILL.md). A SOP is a repeatable how-to; meeting notes are a point-in-time record.
+- **Tracking the emitted tasks across a board / sprint** → [`project-ops`](../project-ops/SKILL.md). This skill *emits* action items; managing their lifecycle is project-ops.
+- **Scheduling the meeting, finding a slot, sending the invite** → [`calendar-scheduling`](../calendar-scheduling/SKILL.md).
+- **Building the integration that pushes notes into Notion/Slack/a tracker** → [`notion-connector`](../notion-connector/SKILL.md) / [`automation-flows`](../automation-flows/SKILL.md).
+- **Summarizing an arbitrary document that is not a meeting** → [`document-processing`](../document-processing/SKILL.md).
+
+Boundary in one line: the durable decision record with alternatives and review lives in `decision-records`; `meeting-notes` captures the decision in context and ships the actionable recap.
+
+## The capture loop
+
+This is the spine. Six steps, in order:
+
+1. **Consent & setup** — if it's being recorded, announce it and get consent *before* capture (see Consent below). Note attendees, date, purpose.
+2. **Capture in real time** — record context → decision → action *as the discussion happens*. Don't reconstruct from memory hours later; you'll lose the why and invent the rest. (Umbrex, accessed 2026-06-02.)
+3. **Sort signal from noise** — a useful record filters to decisions, commitments, and open questions. It is *not* a transcript. (Fellow.app / VoiceType, accessed 2026-06-02.)
+4. **Extract decisions + actions + open questions** — into the skeleton below.
+5. **Verify** — confirm each owner accepts their task while everyone is still present. For AI drafts this step is mandatory and heavier (see Working with AI transcripts).
+6. **Ship the recap within 24–48h** — as a draft, invite corrections, then finalize. (VoiceType / Wrike, accessed 2026-06-02.)
+
+Your first move depends on the source. Branch here:
+
+| You have… | First move | Why |
+|---|---|---|
+| A live meeting / you're the note-taker | Capture in real time, then verbal-confirm each owner before close | Memory decays fast; the room is the cheapest place to fix attribution |
+| An AI-notetaker transcript (Otter, Fireflies, Granola…) | Verify *first* — speakers, hallucinated tasks, quotes vs. source — before you trust any line | AI drafts misattribute speakers and invent tasks; a clean-looking draft is the trap |
+| Raw bullet notes someone typed | Sort signal from noise, then chase the gaps (missing owners/dates) | The notes already filtered; your job is structure + completeness |
+
+## The record skeleton
+
+Curated record, not a transcript (don't dump the conversation flow). Canonical sections, in this order:
+
+```markdown
+# <Meeting> — <Date>
+**Attendees:** Ana, Marc, Júlia (note-taker: Ana) · **Purpose:** decide Q3 launch scope
+
+## TL;DR
+One screen the absent can act on: we cut feature X from the launch, Marc owns the
+go/no-go by Jun 12, payments integration is still open.
+
+## Decisions
+- Cut feature X from the Q3 launch. *Why:* QA can't cover it in time; ships in Q4.
+  *Reversibility:* partially-reversible (re-add in Q4). Dissent: Júlia wanted a flag.
+
+## Action items
+- [ ] Spike the Stripe webhook retry — Marc — by Tue Jun 9
+- [ ] Send revised launch scope to stakeholders — Ana — by Thu Jun 11
+
+## Open questions
+- Who signs off on the payments contract? (raised by Marc, unresolved)
+
+## Parking lot
+- Revisit pricing tiers next sync (not in scope today)
+```
+
+Rule: every major decision gets **one sentence of context**. A decision with no why rots — six weeks later nobody remembers what trade-off it solved. (Umbrex / Fellow.app, accessed 2026-06-02.)
+
+## Action items done right
+
+A complete action item is **`verb, owner, by <real date>`** — never a vague "soon". Explicit dates and named owners raise completion and ownership. (Umbrex, accessed 2026-06-02.)
+
+- **Verb-first** — the task starts with what to do: "Draft…", "Spike…", "Send…", "Confirm…".
+- **One named owner** — a person, not "the team" or "we". Shared ownership means nobody owns it.
+- **A real date** — "by Tue Jun 9", not "next week", not "soon", not "ASAP".
+
+Bad → Good:
+
+| Bad | Good |
+|---|---|
+| "Look into the API stuff — team — soon" | "Spike the Stripe webhook retry path — María — by Tue Jun 9" |
+| "Follow up on the contract" | "Send the signed vendor contract to legal — Marc — by Thu Jun 11" |
+| "Everyone review the doc" | "Leave inline comments on the launch doc — Ana, Júlia — by Mon Jun 8" |
+
+**Verbal-confirm before the meeting ends.** Ask each owner to confirm they accept the task while everyone is still present. (Umbrex, accessed 2026-06-02.) An unaccepted task is a wish.
+
+Add a **status field** (`[ ]` open / `[~]` in progress / `[x]` done) so the same record can be re-read as a tracker until the tasks migrate to [`project-ops`](../project-ops/SKILL.md).
+
+Add **RACI only when ownership is genuinely contested** — a cross-team decision with unclear accountability. Don't bolt a Responsible/Accountable/Consulted/Informed grid onto a five-person standup; it's overhead nobody reads.
+
+## Decisions + the one-line why
+
+For each real decision capture three things:
+
+1. **The decision** — what was decided, stated as a fact.
+2. **One sentence of why** — the trade-off or context. (Umbrex / Fellow.app, accessed 2026-06-02.)
+3. **Dissent or unresolved issue** — if someone disagreed or it's conditional, note it. A record that hides dissent will be re-litigated.
+
+Tag each decision by **reversibility** — `reversible` / `partially-reversible` / `irreversible` — as a single field. Reversible calls can be made fast on imperfect info; irreversible ones warrant slowing down and recording more context, and the tag helps later review. (fs.blog / Reflect OS, accessed 2026-06-02.)
+
+Bad → Good:
+
+| Bad | Good |
+|---|---|
+| "Decided to use Postgres." | "Adopt Postgres over DynamoDB for the events store. *Why:* relational queries we need; team already knows it. *Reversibility:* partially-reversible. Dissent: none." |
+
+When a decision needs the full ADR — alternatives weighed, reversibility argued, a review date — that is `decision-records`' job. Capture it here in context, then hand it off. Don't grow an ADR inside the meeting notes.
+
+## Working with AI transcripts
+
+AI transcripts hallucinate and misattribute speakers, and even strong ASR is not error-free — Whisper reports ~2.5–3% word error on clean read speech (LibriSpeech test-clean) and ~4.7% on TED talks (TED-LIUM), and real meeting audio with crosstalk and accents is worse. A human verification pass is **mandatory** before any task or quote ships. (OpenAI Whisper, *Robust Speech Recognition via Large-Scale Weak Supervision*, arXiv 2212.04356, https://cdn.openai.com/papers/whisper.pdf, accessed 2026-06-02.) Never let an AI-extracted action item or quote go out unverified against the source.
+
+Run three checks before you trust a draft:
+
+1. **Speaker attribution** — does each commitment trace to the right person? AI notetakers swap speakers, especially on overlapping talk or after a silence.
+2. **Hallucinated task** — does each action item correspond to something actually said? If you can't find it in the audio/transcript, drop it or flag it — don't ship it.
+3. **Quote vs. source** — any verbatim quote you keep must match the source. Paraphrase if unsure; never present an unverified quote as exact.
+
+When a line is suspect, **flag it for verification rather than asserting it** — and never invent a missing owner or date. The full checklist is in [`references/templates.md`](references/templates.md).
+
+## Consent & confidentiality
+
+Recording a conversation carries real legal and confidentiality exposure. (Justia, *Recording Phone Calls and Conversations — 50-State Survey*, https://www.justia.com/50-state-surveys/recording-phone-calls-and-conversations/, accessed 2026-06-02; ABA GPSolo eReport "AI and You", Sept 2025.)
+
+- **Announce + get consent before recording.** Roughly a dozen US states require all-party (two-party) consent — per Justia's 50-state survey, CA, CT, DE, FL, IL, MD, MA, MT, NV, NH, PA, WA — but the canonical list is contested (some sources classify MI, OR, or NV differently). Verify the current rule for your jurisdiction; don't assert a fixed count. Under GDPR, recording is data processing — you need a basis and to inform attendees.
+- **A cloud AI notetaker grants a third party access** to the conversation, which can waive privilege. Don't auto-record sensitive or privileged meetings (legal, HR, M&A, incident reviews).
+- **Redact** names, secrets, and confidential details before distribution if the audience is wider than the room.
+
+Decision checklist before you record or distribute:
+
+- [ ] Is this being recorded? → announce it and get consent first.
+- [ ] Any all-party-consent jurisdiction or EU attendee? → explicit consent, on record.
+- [ ] Sensitive / privileged (legal, HR, M&A)? → don't auto-record; notes by hand, tighter distribution.
+- [ ] Distributing beyond the room? → redact names/secrets first.
+
+## Distribution
+
+Ship within **24–48h while memory is fresh**. (VoiceType / Wrike, accessed 2026-06-02.)
+
+1. **Draft** — send the record as a draft, not a finalized minute.
+2. **Invite corrections** — let attendees fix attribution and dates; this is your accuracy pass.
+3. **Finalize** — lock it once corrections land, still inside 48h.
+
+Then route, don't fork. Action items → a tracker via [`project-ops`](../project-ops/SKILL.md) (or pushed by [`automation-flows`](../automation-flows/SKILL.md) / [`notion-connector`](../notion-connector/SKILL.md)). Durable decisions → [`decision-records`](../decision-records/SKILL.md). Keep **one canonical home** for the record and link to it — don't paste three diverging copies into Slack, Notion, and email.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+|---|---|---|
+| Paste the whole transcript as "the notes" | Nobody re-reads a wall of dialogue; the decisions drown | Curate to decisions, actions, open questions + a TL;DR |
+| Action item with no owner ("the team will…") | Shared ownership = nobody owns it; it dies | One named person per task |
+| Owner but no real date ("soon", "next week") | Not a deadline; can't be tracked or chased | `verb, owner, by <real date>` |
+| Ship the AI draft unverified | Hallucinated tasks and swapped speakers go out as fact | Run the 3 verification checks first |
+| Auto-record a sensitive/privileged meeting | Consent and privilege exposure; can waive privilege | Announce + consent; hand-note sensitive meetings |
+| Decision with no why | Rots — re-litigated when nobody recalls the trade-off | One sentence of rationale per decision |
+| Send the recap a week later | Memory's gone; corrections are guesses; team already drifted | Draft within 24–48h, invite corrections, finalize |
+| Fork the notes into three places | Versions diverge; people act on the stale one | One canonical home, link don't copy |
+| Invent a missing owner or date | A fabricated commitment is worse than a flagged gap | Flag it as "needs confirmation" — never guess |
+| Bolt RACI onto a standup | Overhead nobody reads; slows a simple sync | RACI only when ownership is genuinely contested |
+
+## References
+
+- [`references/templates.md`](references/templates.md) — four ready meeting-record templates (decision meeting, standup/sync, retro, 1:1), the full AI-transcript verification checklist, and copy-paste action-item and decision-row formats.

package/skills/meeting-notes/evals/README.md

@@ -0,0 +1,14 @@
+# Evals — meeting-notes
+
+These cases are graded by an LLM against the rubric in `cases.yaml`; run them
+through the repo's eval harness. The `should_trigger` and `should_not_trigger`
+sets check routing — that meeting recaps and AI-transcript cleanups land here,
+while the near-misses route correctly (durable ADRs to `decision-records`,
+reusable procedures to `sop-builder`, slot-finding to `calendar-scheduling`,
+board tracking to `project-ops`). The `capability` case checks the produced
+record against `must_include` — especially that AI-suspect content (a
+misattributed line, a quote) is flagged for verification rather than fabricated,
+that the dateless commitment is marked "needs confirmation" instead of guessed,
+and that every action item carries a named owner plus a real due date. There is
+no `verify.sh`: the output is a human-judged meeting record, not a machine-
+lintable artifact, so the rigor lives entirely in this capability eval.

package/skills/meeting-notes/evals/cases.yaml

@@ -0,0 +1,46 @@
+skill: meeting-notes
+
+should_trigger:
+  - prompt: "We just wrapped the planning call — turn my rough notes into a clean recap with next steps."
+    why: Core path — raw notes to a structured record with action items.
+  - prompt: "Pull the action items out of this meeting transcript and tell me who owns what by when."
+    why: Core path — action-item extraction with owner + concrete due date.
+  - prompt: "The Otter transcript is a mess and it mixed up who said what — clean it into something I can send the team."
+    why: Non-obvious — AI-transcript cleanup + speaker verification, never uses the word "notes".
+  - prompt: "Resume la reunión de hoy y saca los próximos pasos con responsable y fecha límite."
+    why: Spanish — summarize the meeting and produce next steps with owner and due date.
+  - prompt: "Take last week's open items and today's discussion and give me a follow-up recap to send tomorrow."
+    why: Carry-over of open items plus the 24–48h distribution window.
+  - prompt: "Fes una acta de la reunió de producte i marca qui es compromet a què."
+    why: Catalan — meeting minutes with commitments attributed to owners.
+
+should_not_trigger:
+  - prompt: "Write up the architecture decision to adopt Postgres over DynamoDB, with the alternatives we weighed and how we'd revisit it."
+    route_to: decision-records
+    why: Durable ADR with full alternatives and review cadence, not a meeting recap.
+  - prompt: "Document the step-by-step process for onboarding a new vendor so anyone can repeat it."
+    route_to: sop-builder
+    why: A reusable repeatable procedure, not a point-in-time meeting record.
+  - prompt: "Set up next week's recurring sync and find a slot that works for everyone."
+    route_to: calendar-scheduling
+    why: Scheduling and finding a slot, not recording what happened.
+  - prompt: "Track all the open tasks from our meetings on a board and chase them across the sprint."
+    route_to: project-ops
+    why: Task lifecycle on a board, not the meeting record that emits the tasks.
+
+capability:
+  - scenario: >
+      Given a messy ~30-line raw transcript of a product sync that contains two
+      real decisions, three commitments (one with no date stated), a tangent
+      about lunch, and one line likely misattributed to the wrong speaker,
+      produce a meeting record.
+    must_include:
+      - A one-screen TL;DR an absent person could act on.
+      - A Decisions section: each decision + a one-line why + a reversibility tag (reversible / partially-reversible / irreversible).
+      - Action items each as verb-first task + a named owner + a concrete due date.
+      - Flags the commitment with no stated date as "needs confirmation" rather than inventing a date.
+      - Filters out the lunch tangent (curated record, not a transcript dump).
+      - Flags the likely-misattributed line for verification rather than asserting it as fact.
+      - An Open questions section for the unresolved items.
+      - Notes a 24–48h draft + invite-corrections + finalize step.
+      - Does NOT invent owners or dates, and does NOT ship the suspect quote as verified.

package/skills/meeting-notes/references/templates.md

@@ -0,0 +1,140 @@
+# Meeting-record templates & verification checklist
+
+Lookup material for [`../SKILL.md`](../SKILL.md). Copy a template, fill it,
+verify, ship within 24–48h. Every record stays a curated artifact — not a
+transcript.
+
+## Canonical action-item row
+
+```text
+- [ ] <verb-first task> — <named owner> — by <real date>
+```
+
+Status markers: `[ ]` open · `[~]` in progress · `[x]` done · `[!]` blocked.
+Never use "team", "we", "soon", "ASAP", or "next week".
+
+## Canonical decision row
+
+```text
+- <decision as a fact>. *Why:* <one sentence>. *Reversibility:* reversible |
+  partially-reversible | irreversible. Dissent: <name + position, or "none">.
+```
+
+---
+
+## Template 1 — Decision meeting
+
+Heaviest template. Use when the meeting's job was to *decide*.
+
+```markdown
+# <Topic> Decision — <Date>
+**Attendees:** <names> (note-taker: <name>) · **Purpose:** <one line>
+
+## TL;DR
+<One screen: what we decided, who owns the next move, what's still open.>
+
+## Decisions
+- <Decision>. *Why:* <one sentence>. *Reversibility:* <tag>. Dissent: <…>.
+
+## Action items
+- [ ] <verb> — <owner> — by <date>
+
+## Open questions
+- <question> (raised by <name>, unresolved)
+
+## Parking lot
+- <out-of-scope item to revisit>
+
+## Hand-offs
+- Durable ADR for <decision> → decision-records
+- Tasks above → project-ops
+```
+
+---
+
+## Template 2 — Standup / sync
+
+Lightest template. No RACI, no reversibility unless a real decision happened.
+
+```markdown
+# <Team> Standup — <Date>
+**Present:** <names>
+
+## Decisions (if any)
+- <decision>. *Why:* <one line>.
+
+## Action items
+- [ ] <verb> — <owner> — by <date>
+
+## Blockers / open
+- <blocker> — needs <name/decision>
+```
+
+---
+
+## Template 3 — Retro
+
+```markdown
+# <Sprint/Project> Retro — <Date>
+**Attendees:** <names> (facilitator: <name>)
+
+## TL;DR
+<Top theme + the one change we're committing to.>
+
+## What went well
+- <point>
+
+## What to improve
+- <point>
+
+## Action items (commitments, not wishes)
+- [ ] <verb> — <owner> — by <date>
+
+## Parking lot
+- <recurring theme to watch>
+```
+
+---
+
+## Template 4 — 1:1
+
+Tighter distribution; redact before any wider share.
+
+```markdown
+# 1:1 — <Name A> / <Name B> — <Date>
+
+## Agreed
+- <agreement>. *Why:* <one line>.
+
+## Action items
+- [ ] <verb> — <owner> — by <date>
+
+## Follow-ups for next time
+- <topic>
+```
+
+---
+
+## AI-transcript verification checklist
+
+Mandatory before any AI-drafted task or quote ships. AI transcripts hallucinate
+and misattribute speakers, and even strong ASR is not error-free (Whisper:
+~2.5–3% word error on clean read speech, ~4.7% on TED talks, worse on real
+meeting audio) — a clean-looking draft is the trap. Run every box:
+
+- [ ] **Speaker attribution** — each commitment traces to the correct person.
+      Re-check overlapping talk, post-silence lines, and similar-sounding voices.
+- [ ] **Hallucinated task** — every action item maps to something actually said.
+      If you can't find it in the source, drop it or flag it — don't ship it.
+- [ ] **Quote vs. source** — every verbatim quote matches the source word for
+      word. Unsure? Paraphrase. Never present an unverified quote as exact.
+- [ ] **Attribution of commitments** — the person credited with an action is the
+      one who accepted it, not whoever happened to be talking nearby.
+- [ ] **No invented owners/dates** — a missing owner or date is flagged "needs
+      confirmation", never guessed.
+- [ ] **Tangents filtered** — banter and off-topic threads are cut, not recorded.
+- [ ] **Sensitive content** — names/secrets redacted before distribution beyond
+      the room.
+
+When a line is suspect, write it as: `> [VERIFY] <line> — attribution/quote
+unconfirmed against source`. Resolve every `[VERIFY]` before finalizing.