@ericrisco/rsc 0.1.55 → 0.1.57

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.55",
+  "version": "0.1.57",
   "counts": {
     "skills": 258
   },
@@ -2065,7 +2065,7 @@
     },
     {
       "id": "github-actions",
-      "description": "Use when authoring or fixing GitHub Actions CI/CD — workflows under .github/workflows, jobs, the runner matrix, dependency caching, secrets and OIDC cloud deploys, environments and approval gates, reusable and composite workflows. Triggers: 'write a CI workflow', 'my GitHub Actions builds are slow / add caching', 'run the tests on a matrix of node versions', 'deploy to AWS without storing access keys' (OIDC), 'every push spawns a run and the old ones keep finishing' (concurrency), 'pin my actions / supply-chain hardening after the tj-actions thing', 'munta el desplegament continu amb GitHub Actions cap a producció', 'per què el GITHUB_TOKEN té permisos d'escriptura per defecte'. NOT writing the Dockerfile or image build strategy (that is docker), NOT the branching/merge model (that is git-workflow), NOT release readiness or the changelog (that is ship).",
+      "description": "Use when authoring or fixing GitHub Actions CI/CD — workflows under .github/workflows, triggers, job matrix, caching, token permissions, OIDC cloud deploys, environment gates, reusable workflows. NOT the Dockerfile or image build strategy (that is `docker`), NOT the branching model (that is `git-workflow`), NOT release readiness (that is `ship`).",
       "tags": [
         "github-actions",
         "ci-cd",
@@ -2654,7 +2654,7 @@
     },
     {
       "id": "linkedin-outreach",
-      "description": "Use when running LinkedIn-native social selling as a repeatable motion: building Sales Navigator saved searches and trigger alerts, fixing a low connection-acceptance rate, designing a daily social-selling routine, turning profile views / post engagers / accepted connections into warm conversations, and logging every touch so the loop is measurable. Triggers: 'set up a Sales Nav saved search and alert me on job changes', 'how many connection requests per week without getting flagged', 'my acceptance rate is in the toilet', 'someone viewed my profile, what is the play', 'turn the people who liked my post into conversations', 'munta'm una rutina de social selling a LinkedIn', '¿cuántas invitaciones puedo enviar por semana'. This owns the loop and its ledger, NOT writing the cold connection note or DM copy (that is cold-outreach).",
+      "description": "Use when running LinkedIn social selling as a repeatable motion — Sales Navigator saved searches and trigger alerts, weekly request budgets, fixing a low acceptance rate, turning profile views and post engagers into warm threads, logging every touch. NOT the note or DM copy (that is `cold-outreach`), NOT the deal after a reply (that is `sales-pipeline`).",
       "tags": [
         "linkedin",
         "social-selling",
@@ -2789,7 +2789,7 @@
     },
     {
       "id": "market-research",
-      "description": "Use when you need a defensible picture of a MARKET as a whole — sizing it with TAM/SAM/SOM, cutting it into reachable segments, and proving demand is real and moving — with a dated source behind every number. Triggers: 'how big is the market for X', 'size this market', 'what's our TAM', 'is there real demand for this', 'who are the segments', 'where's the beachhead', 'sanity-check this TAM before the raise', 'top-down or bottom-up', '¿qué tamaño tiene el mercado de X', 'calcula el TAM', 'hay demanda real para esto', 'quina mida té aquest mercat'. NOT profiling specific named rivals and their moves (that is competitor-watch), NOT building a named list of accounts to sell to (that is lead-gen).",
+      "description": "Use when a MARKET as a whole needs a defensible picture — TAM/SAM/SOM sized top-down AND bottom-up until the two converge, cut into reachable segments with one named beachhead, demand proven real, and a dated source behind every figure. NOT profiling named rivals and their moves (that is `competitor-watch`), NOT building a list of accounts to sell to (that is `lead-gen`).",
       "tags": [
         "market-research",
         "tam-sam-som",
@@ -2888,7 +2888,7 @@
     },
     {
       "id": "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).",
+      "description": "Use when a meeting just ended and a transcript or rough notes must become a record the absent can act on — decisions with their why, actions with an owner and a real date, open questions, a recap inside 24–48h — or to clean an AI-notetaker draft that invented tasks or swapped speakers. NOT the durable ADR with alternatives weighed (that is decision-records).",
       "tags": [
         "meeting-notes",
         "action-items",
@@ -3033,7 +3033,7 @@
     },
     {
       "id": "nestjs",
-      "description": "Use when building or structuring a NestJS backend — feature modules, providers, controllers, DI wiring, and the cross-cutting layer (guards, interceptors, pipes, exception filters) — including binding-scope and request-lifecycle decisions and Nest-specific testing. Triggers: 'create a NestJS module', 'wire a custom provider with useFactory', 'APP_GUARD vs @UseGuards on the controller', 'my request-scoped provider is undefined in a guard', 'A circular dependency has been detected at bootstrap', 'mock a repository provider with overrideProvider', 'monta un módulo de Nest', 'guard de autenticación JWT en NestJS'. NOT a bare Express/Node service with no DI (that is nodejs).",
+      "description": "Use when building or structuring a NestJS backend — feature modules, providers and DI wiring, provider scopes and request-lifecycle order, where to bind guards/pipes/interceptors/filters, and testing with Test.createTestingModule. NOT a bare Express/Fastify service with no DI (that is `nodejs`), NOT framework-agnostic REST design (that is `api-design`).",
       "tags": [
         "nestjs",
         "nodejs",
@@ -3158,7 +3158,7 @@
     },
     {
       "id": "nodejs",
-      "description": "Use when building or structuring a plain Node.js / Express backend service — project layout, async correctness, central error handling, config validation, and graceful shutdown — the runtime and HTTP service, not a DI framework. Triggers: 'set up an Express 5 service', 'my async route error returns 200 with an empty body', 'where do controllers vs services go', 'centralize error handling middleware', 'shut down cleanly on SIGTERM without dropping requests', 'why does one unhandled promise rejection crash my server', 'monta un backend con Express y manejo de errores', 'apaga el servidor sin perder peticiones en vuelo'. NOT NestJS DI/modules/guards (that is nestjs); NOT the TS type system/tsconfig (that is typescript); NOT REST contract/versioning (that is api-design).",
+      "description": "Use when building or operating a plain Node.js / Express 5 backend service: project layout, async correctness, central error middleware, fail-fast config, graceful shutdown on SIGTERM. NOT DI modules/providers/guards (that is `nestjs`), NOT the type system or tsconfig (that is `typescript`), NOT REST contract design (that is `api-design`).",
       "tags": [
         "nodejs",
         "express",
@@ -3459,7 +3459,7 @@
     },
     {
       "id": "power-automate",
-      "description": "Use when operating Microsoft Power Automate cloud flows programmatically — creating, enabling, updating, listing or deleting flows through the Dataverse Web API (the workflow table, category 5) with Entra ID / OAuth2 auth, or reading action-level run history via the third-party FlowStudio MCP. Triggers: 'create a Power Automate cloud flow with the Dataverse API', 'enable my flow by code / set statecode to 1', 'why can't I create or edit a My Flow programmatically', 'PATCH the workflow clientdata', 'automatizar el despliegue de un flujo de Power Automate desde código'. NOT designing the flow or authoring its definition (automation-flows), NOT choosing a platform by billing model (automation-strategy), NOT a generic typed REST client with auth/pagination/backoff (api-connector-builder), NOT the endpoint receiving an HTTP-trigger POST in your app (webhooks), NOT scripting Microsoft 365 / Graph mail & calendar directly (no first-party skill — api-connector-builder, or google-workspace).",
+      "description": "Use when operating Microsoft Power Automate cloud flows from code — create, enable, update, list or delete via the Dataverse Web API (`workflow` table, category 5) with Entra ID OAuth2, plus run-history debugging. NOT designing the flow definition (that is `automation-flows`), NOT picking a platform by billing model (that is `automation-strategy`).",
       "tags": [
         "power-automate",
         "dataverse",
@@ -3546,7 +3546,7 @@
     },
     {
       "id": "prisma-orm",
-      "description": "Use when modeling data or writing type-safe queries with Prisma ORM in TypeScript and hitting its classic problems: N+1 on relations, over-fetching with fat include, an unbounded findMany scanning the whole table, the v7 'requires either adapter or accelerateUrl' error, or a Prisma 6 to 7 upgrade. Owns schema.prisma, the prisma-client generator, prisma.config.ts, the Prisma Client query API, and Prisma Migrate. Triggers: 'PrismaClient requires either adapter or accelerateUrl', 'client is not in node_modules anymore', 'relationLoadStrategy join vs query', 'migrate dev vs migrate deploy in CI', 'findMany returns the whole table', 'modela el esquema de usuarios y pedidos con Prisma', 'migració de Prisma a la versió 7'. NOT the schema-as-TS SQL-builder ORM (that is drizzle-orm), NOT cross-cutting zero-downtime migration strategy (that is db-migrations), NOT Postgres server tuning and EXPLAIN (that is postgresdb).",
+      "description": "Use when modeling data or writing type-safe queries with Prisma ORM in TypeScript — `schema.prisma`, `prisma.config.ts`, the generated Prisma Client, and Prisma Migrate, including the v6 to v7 upgrade. NOT schema-as-TS with a SQL builder (that is `drizzle-orm`), NOT ORM-agnostic zero-downtime migration (that is `db-migrations`), NOT Postgres engine tuning (that is `postgresdb`).",
       "tags": [
         "prisma",
         "prisma-orm",
@@ -3571,7 +3571,7 @@
     },
     {
       "id": "procurement",
-      "description": "Use when a small operator must decide what to buy and from whom — pick a supplier/vendor, write an RFI/RFQ/RFP that gets comparable bids back, compare quotes on total cost not sticker price, negotiate price and payment terms, judge single-source risk, or build a vendor scorecard for quarterly review. Triggers: 'help me pick a supplier for X', 'write an RFQ for 5,000 units', 'which of these quotes is actually cheapest over three years', 'should I take the 2/10 net 30 early-payment discount', 'we buy a critical part from one supplier — how risky is that', 'build a supplier scorecard', 'compara estos proveedores / negociar condiciones de pago', 'compara aquests proveïdors / negociar condicions amb el proveïdor'. NOT signing the binding purchase agreement or redlining liability/IP clauses (that is contracts), NOT the price you charge your own customers (that is pricing), NOT counting or reordering the stock once it arrives (that is inventory).",
+      "description": "Use when a small operator must choose what to buy and from whom: pick a supplier, write an RFI/RFQ/RFP that returns comparable bids, score quotes on total cost of ownership, negotiate price and payment terms, or judge single-source risk. NOT redlining the purchase agreement (that is `contracts`), NOT the price you charge customers (that is `pricing`), NOT stock once it lands (that is `inventory`).",
       "tags": [
         "procurement",
         "sourcing",
@@ -3750,7 +3750,7 @@
     },
     {
       "id": "react-native",
-      "description": "Use when writing the JS/TS code inside a React Native or Expo app — screens, navigation, lists, animation, platform-conditional UI, data/offline state, and native-module authoring — and when killing runtime jank or render bugs. Triggers: 'scaffold an Expo Router app', 'FlashList vs FlatList', 'auth-gated route groups', 'gesture reattaches every render', 're-render storm on every keystroke', 'deep link lands on the wrong screen', 'write an Expo Module wrapping a native SDK', 'la llista pateix lag quan faig scroll', 'mi app va fluida en iOS pero a tirones en Android'. NOT eas build/submit/OTA update/prebuild/config-plugin (that is expo), NOT a Dart app (that is flutter), NOT web React/DOM (that is react or nextjs).",
+      "description": "Use when writing the JS/TS inside a React Native or Expo app — screens, Expo Router navigation, lists, Reanimated gestures, platform forks, offline state, native modules — or killing jank and render storms. NOT eas build/submit/OTA/config-plugin (that is `expo`), NOT a Dart app (that is `flutter`), NOT web React/DOM (that is `react` or `nextjs`).",
       "tags": [
         "react-native",
         "expo",
@@ -3884,7 +3884,7 @@
     },
     {
       "id": "reporting",
-      "description": "Use when you need a recurring report that ships to stakeholders on a cadence — a weekly team digest, monthly exec pack, quarterly board summary, or recurring client performance report — and it must go out reliably without a human in the loop. Symptoms: a standing metrics email keeps breaking or shows stale numbers, the Monday digest is hand-assembled every week, leadership asks for 'the same report but every month', or a client expects a PDF on a schedule. Triggers: 'set up a weekly automated report emailed to the exec team', 'build a monthly PDF report for our biggest client on a schedule', 'send the board a quarterly summary every quarter', 'our Monday metrics email keeps going out with last week's numbers — make it reliable', 'automatiza un informe mensual para dirección', 'munta un informe setmanal automàtic per al comitè'. NOT a live screen people open to slice metrics (that is dashboard), NOT deciding which KPIs to track (that is kpi-framework), NOT a one-off investigation (that is analytics).",
+      "description": "Use when a recurring report must ship itself on a cadence — weekly digest, monthly exec pack, board pack — via a fetch→narrate→render→deliver pipeline with a schedule and a freshness gate. NOT a live view people slice (that is `dashboard`), NOT picking which KPIs to track (that is `kpi-framework`), NOT a one-off investigation (that is `analytics`).",
       "tags": [
         "reporting",
         "automated-reports",
@@ -3994,7 +3994,7 @@
     },
     {
       "id": "roast-me",
-      "description": "Use when you want honest, comedic feedback on how you prompt — analyzing your own past sessions to score prompt quality and compute efficiency, surface your worst habits, and generate a model-selection cheat sheet. Triggers: 'roast me', 'roast my prompting', 'audit my prompting habits', 'how good are my prompts', 'am I prompting well', 'what are my bad prompt habits', 'analiza mis prompts', 'puntua els meus prompts', 'how much am I wasting on model costs'. NOT reviewing your code or output quality (use code-review for that) and NOT a general prompt-engineering tutorial (use prompt-engineering for that).",
+      "description": "Use when someone wants an honest, comedic audit of their own prompting — reads their past agent transcripts, scores prompt quality and compute efficiency, names their worst habits, builds a model-selection cheat sheet. NOT reviewing code an agent produced (that is `code-review`), NOT prompting technique in general (that is `prompt-engineering`).",
       "tags": [
         "prompting",
         "self-audit",
@@ -4013,7 +4013,7 @@
     },
     {
       "id": "ruby",
-      "description": "Use when writing idiomatic Ruby outside Rails — plain scripts, CLIs, gems, libraries — or refactoring imperative loops into Enumerable chains, designing module mixins, packaging with Bundler, deciding whether metaprogramming is worth it, or setting up Minitest/RSpec. Triggers: 'write this in Ruby', 'refactor this loop with map/reduce', 'build a gem', 'gemspec / Gemfile.lock', 'method_missing or define_method?', 'Minitest vs RSpec', 'FrozenError after Ruby 3.4 upgrade', 'mixin vs inheritance', 'escribir una gema en Ruby', 'refactoritzar amb blocs'. NOT Rails/ActiveRecord/controllers (that is rails).",
+      "description": "Use when writing or refactoring plain Ruby outside Rails — scripts, CLIs, gems, libraries: Enumerable chains and blocks, module mixins and value objects, Bundler/gemspec packaging, whether metaprogramming earns its keep, Minitest or RSpec, Ruby 3.4/4.0 frozen-string hygiene. NOT Rails, ActiveRecord, or ActiveSupport idioms (that is `rails`).",
       "tags": [
         "ruby",
         "gems",
@@ -4273,7 +4273,7 @@
     },
     {
       "id": "shortform-ideation",
-      "description": "Use when an account that already posts (or is about to start posting) Reels/TikTok/Shorts needs a ranked batch of next video ideas grounded in its own performance log plus live trending sounds/formats/hashtags, and a ledger that ties each idea-bet to its measured outcome. Use to fold this week's trending audio into ideas, to decide which 3 of 12 ideas to shoot first, or to review why the bets you made flopped. Triggers: 'give me 10 Reels ideas for next week', 'which of these ideas do we make first', 'fold this week's trending TikTok sounds into our idea list', 'why did the ones we bet on last month flop', 'idea backlog for our TikTok', 'idéame Reels para esta semana basándote en lo que ya nos funcionó', 'prioritza idees de vídeo curt per aquesta setmana'. NOT writing the shot-by-shot script or edit decision sheet for a chosen idea (that is video-shorts), NOT setting cadence/pillars/positioning (that is shortform-strategy), NOT captions/covers/hashtag-sets for a finished cut (that is shortform-packaging).",
+      "description": "Use when a Reels/TikTok/Shorts account needs its next video ideas scored into a ranked backlog, grounded in its own performance log plus dated trending sounds, each bet logged so its outcome feeds the next batch. NOT scripting a chosen idea (that is `video-shorts`), NOT pillars or cadence (that is `shortform-strategy`), NOT packaging a finished cut (that is `shortform-packaging`).",
       "tags": [
         "shortform",
         "reels",
@@ -4322,7 +4322,7 @@
     },
     {
       "id": "shortform-strategy",
-      "description": "Use when running the durable strategy layer of a TikTok and/or Instagram Reels account — positioning, posting cadence, format mix, which trends and sounds to ride, recurring series, and the what-worked learning loop — not making one video. Use for standing up a new account before posting; diagnosing a flat or declining account (positioning, cadence, or format?); deciding whether to ride a trend or sound now; designing a recurring series; the monthly strategy review; or choosing the Reels-vs-carousel mix. Triggers: 'starting a new TikTok account, what and how often should we post', 'we post every single day and our reach is going down' (cadence-dilution symptom, no strategy word), 'should we jump on this sound or is it dead', 'we want a weekly recurring series on Reels', 'muntar l''estratègia del compte de Reels: posicionament i cadència', '¿nos subimos a esta tendencia o ya pasó?'. NOT writing the single short script or hook variants (that is video-shorts).",
+      "description": "Use when the unit of work is a TikTok/Reels account, not one clip: positioning, sustainable cadence and format mix, ride-or-skip on a trend or sound, recurring series, diagnosing a flat account, and the dated learning loop. NOT the single script or hook variants (that is `video-shorts`), NOT the idea backlog (that is `shortform-ideation`).",
       "tags": [
         "short-form-video",
         "tiktok",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ericrisco/rsc",
-  "version": "0.1.55",
+  "version": "0.1.57",
   "description": "Eric Risco's agent-skills catalog as a granular, self-recommending CLI installer.",
   "type": "module",
   "bin": {

package/skills/github-actions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: github-actions
-description: "Use when authoring or fixing GitHub Actions CI/CD — workflows under .github/workflows, jobs, the runner matrix, dependency caching, secrets and OIDC cloud deploys, environments and approval gates, reusable and composite workflows. Triggers: 'write a CI workflow', 'my GitHub Actions builds are slow / add caching', 'run the tests on a matrix of node versions', 'deploy to AWS without storing access keys' (OIDC), 'every push spawns a run and the old ones keep finishing' (concurrency), 'pin my actions / supply-chain hardening after the tj-actions thing', 'munta el desplegament continu amb GitHub Actions cap a producció', 'per què el GITHUB_TOKEN té permisos d'escriptura per defecte'. NOT writing the Dockerfile or image build strategy (that is docker), NOT the branching/merge model (that is git-workflow), NOT release readiness or the changelog (that is ship)."
+description: "Use when authoring or fixing GitHub Actions CI/CD — workflows under .github/workflows, triggers, job matrix, caching, token permissions, OIDC cloud deploys, environment gates, reusable workflows. NOT the Dockerfile or image build strategy (that is `docker`), NOT the branching model (that is `git-workflow`), NOT release readiness (that is `ship`)."
 tags: [github-actions, ci-cd, workflows, oidc, caching]
 recommends: [docker, git-workflow, ship, deployment, secure-coding, aws-essentials, vercel]
 origin: risco
@@ -10,26 +10,16 @@ origin: risco
 
 A workflow is config that runs on an event. Before you write a single step, decide three things: **which events** fire the workflow, **what permissions** the token needs, and **where credentials come from**. Get those wrong and you have a fast pipeline that leaks secrets or a secure one nobody can trigger. Everything after that — checkout, install, test, build — is just steps.
 
-This skill owns the workflow layer: the `.github/workflows/*.yml` files, their triggers, jobs, matrix, caching, secret/OIDC handling, environments, and deploy gates. It does not own the image you build, the branching model, or the release decision (see the boundaries below).
+This skill owns the workflow layer — the `.github/workflows/*.yml` files, their triggers, jobs, matrix, caching, secret/OIDC handling, environments and deploy gates. Route the rest out:
 
-## Use this when
-
-- Writing or fixing a `ci.yml` / `deploy.yml` / `release.yml`.
-- Adding lint/test/build jobs on push or pull_request.
-- Speeding up CI with dependency caching.
-- Running a build across an OS x language-version matrix.
-- Wiring deploys: environments, approval gates, OIDC to a cloud, secrets.
-- Reusable workflows (`workflow_call`) and composite actions to kill copy-paste.
-- Killing redundant runs with `concurrency`; SHA-pinning actions for supply-chain safety.
-
-## Not this when
-
-- Authoring the `Dockerfile` or deciding the image build strategy → docker. The workflow may *call* `docker build`; designing the image is not this skill.
-- Branching model, PR hygiene, merge vs rebase, commit conventions → git-workflow.
-- Release readiness checklist, changelog, the shipping decision → `../ship/SKILL.md`.
-- Blue/green, canary, rollback *theory* → `../deployment/SKILL.md`. Actions triggers the deploy; the strategy is deployment's.
-- Choosing the host and its deploy primitives → `../vercel/SKILL.md` / `../aws-essentials/SKILL.md` / the host skill. Actions *triggers* the deploy; the host owns the target.
-- Triaging SAST/CVE findings or threat-modeling → `../secure-coding/SKILL.md`. This skill runs a scanner *as a job*; it does not interpret the report.
+| Not this skill | Goes to | Because |
+| --- | --- | --- |
+| The `Dockerfile`, image build strategy | `../docker/SKILL.md` | The workflow may *call* `docker build`; designing the image is not this skill. |
+| Branching model, PR hygiene, merge vs rebase, commit conventions | `../git-workflow/SKILL.md` | That is the source-control model, not the CI config layer. |
+| Release readiness checklist, changelog, the shipping decision | `../ship/SKILL.md` | Whether to release is a decision; this skill only automates the mechanics. |
+| Blue/green, canary, rollback *theory* | `../deployment/SKILL.md` | Actions triggers the deploy; the strategy is deployment's. |
+| Choosing the host and its deploy primitives | `../vercel/SKILL.md`, `../aws-essentials/SKILL.md` | Actions *triggers* the deploy; the host owns the target. |
+| Triaging SAST/CVE findings, threat modeling | `../secure-coding/SKILL.md` | This skill runs a scanner *as a job*; it does not interpret the report. |
 
 ## Decide the trigger first
 
@@ -74,16 +64,15 @@ jobs:
         with:
           node-version: 22
           cache: npm                     # built-in lockfile-keyed cache
-      - run: npm ci                       # ci, not install — respects the lockfile
+      - run: npm ci                       # not install — fails on a stale lockfile, reproducible
       - run: npm run lint
       - run: npm test
 ```
 
-Rules baked into that file, each with its why:
-- `permissions: contents: read` at the top — **default token permissions may be write**; declare read-only and widen per job. A leaked write token can push tags or publish packages.
-- `concurrency` + `cancel-in-progress: true` — without it, every push to an open PR leaves the old run finishing and billing. One group per ref keeps at most one running + one pending.
-- `npm ci` not `npm install` — `ci` fails on a stale lockfile and is reproducible.
-- `actions/checkout@v6`, `setup-node@v6` — current majors (checkout v6.0.2, setup-node v6.4.0). Old majors run on Node 20, removed from runners in **September 2026**; JS actions are forced onto **Node 24** by default since June 2026. Upgrade to silence deprecation warnings and stay supported.
+Why those three lines are not optional:
+- `permissions: contents: read` at the top — **default token permissions may be write**, and a leaked write token can push tags or publish packages. Widen per job and only to what that job needs (`packages: write` to publish, `id-token: write` for OIDC), never at the top.
+- `concurrency` + `cancel-in-progress: true` — without it every push to an open PR leaves the old run finishing and billing. One group per ref keeps at most one running + one pending.
+- `actions/checkout@v6`, `setup-node@v6` are the current majors (checkout v6.0.2, setup-node v6.4.0). Old majors run on Node 20, removed from runners in **September 2026**; JS actions are forced onto **Node 24** by default since June 2026.
 
 ## Caching
 
@@ -183,7 +172,6 @@ Per-cloud trust setup (AWS role, GCP Workload Identity Federation, Azure federat
   ```
 
   First-party `actions/*` and `github/*` may stay on a major tag (GitHub controls them), but pinning everything is the stronger posture.
-- **Keep `GITHUB_TOKEN` read-only by default**, widen per job. Set `permissions: contents: read` at the top, then grant exactly what a job needs (`packages: write` to publish, `id-token: write` for OIDC).
 - **`pull_request_target` + checking out the PR head = remote code execution with your secrets.** That trigger runs in the *base* repo's trusted context. If you then `checkout` `github.event.pull_request.head.sha`, you execute a fork's code with full secret access. Never combine them.
 
 ## Reuse: workflow vs composite action

package/skills/linkedin-outreach/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: linkedin-outreach
-description: "Use when running LinkedIn-native social selling as a repeatable motion: building Sales Navigator saved searches and trigger alerts, fixing a low connection-acceptance rate, designing a daily social-selling routine, turning profile views / post engagers / accepted connections into warm conversations, and logging every touch so the loop is measurable. Triggers: 'set up a Sales Nav saved search and alert me on job changes', 'how many connection requests per week without getting flagged', 'my acceptance rate is in the toilet', 'someone viewed my profile, what is the play', 'turn the people who liked my post into conversations', 'munta'm una rutina de social selling a LinkedIn', '¿cuántas invitaciones puedo enviar por semana'. This owns the loop and its ledger, NOT writing the cold connection note or DM copy (that is cold-outreach)."
+description: "Use when running LinkedIn social selling as a repeatable motion — Sales Navigator saved searches and trigger alerts, weekly request budgets, fixing a low acceptance rate, turning profile views and post engagers into warm threads, logging every touch. NOT the note or DM copy (that is `cold-outreach`), NOT the deal after a reply (that is `sales-pipeline`)."
 tags: [linkedin, social-selling, sales-navigator, outreach, pipeline]
 recommends: [cold-outreach, lead-gen, sales-pipeline, linkedin-strategy, linkedin-content]
 origin: risco
@@ -8,46 +8,28 @@ origin: risco
 
 # Linkedin Outreach — The Loop and Its Ledger
 
-*You run the LinkedIn social-selling motion and keep its score. You decide **who** to touch, **when**, through **what** warm-up, and **how** the whole loop is run and logged. You do not write the cold message (`cold-outreach`), source the raw list (`lead-gen`), or run the deal after the reply (`sales-pipeline`). The thesis is warm-first: engagement before connection, signal before send, ledger before "I'll remember it."*
+*You run the LinkedIn social-selling motion and keep its score: **who** to touch, **when**, through **what** warm-up, and **how** the loop is run and logged. The thesis is warm-first — engagement before connection, signal before send, ledger before "I'll remember it." The output is a running system plus a touch ledger under `02-DOCS/`, never a finished line of copy: when prose is needed you write the brief and hand it off, then stay in the loop.*
 
-This skill is a *motion*, not a message. Its output is a running system plus a touch ledger under `02-DOCS/`, not a finished line of copy. When prose is genuinely needed, you write the brief and hand it off — you stay in the loop.
+## Boundary
 
-## When to use
+The sharpest line is against `../cold-outreach/SKILL.md`, and it splits on message-vs-system:
 
-- "Set up a Sales Navigator saved search / lead list for [ICP] and the trigger alerts."
-- "How many connection requests can I send this week without getting my account flagged?"
-- "Build me a 30-min-a-day social-selling routine that turns LinkedIn into pipeline."
-- "My acceptance rate is ~15% — how do I run requests so people actually accept?"
-- "Turn everyone who engaged with my last post into a conversation."
-- "Someone viewed my profile / liked my post — what's the play?"
-- "Log my LinkedIn touches and show me what's converting."
-- "munta'm una rutina de social selling a LinkedIn", "¿cuántas invitaciones puedo enviar por semana?"
+- **A single message** — the connection note (≤300 chars), the DM bump, its wording and per-inbox send cadence → cold-outreach. If the ask is "write this" or "fix this template," it is not yours.
+- **The system** — who to touch, when, the warm-up, the budget, the ledger → here. When both are in play, this skill drives and delegates the copy.
 
-## When NOT — the boundary that gets fought over
-
-The sharpest line is against **cold-outreach**. Hold it:
-
-- **A single message** — the connection note (≤300 chars), the DM bump, its wording and per-inbox send cadence → `../cold-outreach/SKILL.md`. If the ask is "write this" or "fix this template," it is not yours.
-- **The system** — who to touch, when, the warm-up, the budget, the ledger → here. When both are in play, **this skill drives and delegates the copy.**
-
-Other routes:
-
-- Sourcing / scoring the raw prospect list, ICP definition, dedupe → `../lead-gen/SKILL.md`.
-- Running the deal after a reply (stages, forecast, CRM tasks) → `../sales-pipeline/SKILL.md`.
-- Writing/scheduling LinkedIn *posts* → `../linkedin-content/SKILL.md`.
-- Brand growth/positioning strategy → `../linkedin-strategy/SKILL.md`.
+Also not yours: sourcing / scoring the raw prospect list and ICP definition → `../lead-gen/SKILL.md`; the deal after a reply, i.e. stages, forecast, CRM tasks → `../sales-pipeline/SKILL.md`; writing or scheduling LinkedIn *posts* → `../linkedin-content/SKILL.md`; brand growth and positioning → `../linkedin-strategy/SKILL.md`.
 
 ## The loop
 
 Five phases, in order. Each has a *why* and yields one artifact; the artifact gates the next phase. Skipping a phase is how acceptance collapses.
 
 1. **Target** — *why:* outreach timed to a reason beats outreach timed to a calendar. → Yields a Sales Nav saved search + trigger alerts (job change, funding, recent post).
-2. **Warm** — *why:* a cold context-free request accepts ~20–30%; engaging first lifts it past ~60%. → Yields a logged pre-touch (profile view + one genuine comment/like 1–2 days prior).
+2. **Warm** — *why:* a cold, context-free request is the worst-accepting move you can make; engaging first is what fixes it. → Yields a logged pre-touch (profile view + one genuine comment/like 1–2 days prior).
 3. **Connect** — *why:* the request is the smallest, most rate-limited move; spend it deliberately. → Yields a sent request inside the weekly budget, note-or-no-note chosen by goal.
 4. **Convert** — *why:* an accept is not a conversation; the choreography turns a signal into a warm 1:1. → Yields a thread with a real reply, copy delegated to cold-outreach when needed.
 5. **Log** — *why:* a motion you can't measure you can't repeat or fix. → Yields a row in the `02-DOCS/` ledger with the outcome.
 
-Each phase has its own section below. Run them as a daily checklist (last section).
+Each phase gets a section below; the last one compresses all five into a day.
 
 ## Target with Sales Navigator
 
@@ -88,7 +70,7 @@ When you do send a note, you do **not** write it here — hand the brief (the ho
 | Free | ~100/wk | ~20/weekday, stay under ~80/wk | Pause and warm more if acceptance drops below ~30%. |
 | Premium / Sales Nav | up to ~200/wk | up to ~40/day | Only with strong SSI and acceptance >40%; otherwise treat as free. |
 
-Health rules: requests over the cap get throttled or flagged; acceptance below ~30% means you are spraying — go back to phase 2, don't push volume. Withdraw stale pending requests before they pile up.
+Over the cap, requests get throttled or the account flagged. Below ~30% acceptance you are spraying — go back to phase 2 instead of pushing volume, and withdraw stale pending requests before they pile up.
 
 ## Engagement → conversation
 
@@ -123,9 +105,7 @@ Buying-signal tells in a thread: they ask about price/timeline, mention an activ
 
 1. Book the call or send the warm intro.
 2. Log the outcome (`call_booked`) in the ledger.
-3. Hand the thread + context to `../sales-pipeline/SKILL.md`.
-
-**Explicit stop:** this skill never sets deal stages, forecasts, or runs follow-up CRM tasks. The moment a deal exists, it is sales-pipeline's.
+3. Hand the thread + context to `../sales-pipeline/SKILL.md` — the moment a deal exists it is theirs, and you set no stages or forecasts.
 
 ## The ledger (02-DOCS)
 

package/skills/market-research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: market-research
-description: "Use when you need a defensible picture of a MARKET as a whole — sizing it with TAM/SAM/SOM, cutting it into reachable segments, and proving demand is real and moving — with a dated source behind every number. Triggers: 'how big is the market for X', 'size this market', 'what's our TAM', 'is there real demand for this', 'who are the segments', 'where's the beachhead', 'sanity-check this TAM before the raise', 'top-down or bottom-up', '¿qué tamaño tiene el mercado de X', 'calcula el TAM', 'hay demanda real para esto', 'quina mida té aquest mercat'. NOT profiling specific named rivals and their moves (that is competitor-watch), NOT building a named list of accounts to sell to (that is lead-gen)."
+description: "Use when a MARKET as a whole needs a defensible picture — TAM/SAM/SOM sized top-down AND bottom-up until the two converge, cut into reachable segments with one named beachhead, demand proven real, and a dated source behind every figure. NOT profiling named rivals and their moves (that is `competitor-watch`), NOT building a list of accounts to sell to (that is `lead-gen`)."
 tags: [market-research, tam-sam-som, market-sizing, segmentation, demand-signals, jtbd, opportunity]
 recommends: [competitor-watch, lead-gen, pitch-deck, financial-model, pricing, forecasting, content-engine]
 origin: risco
@@ -14,22 +14,19 @@ The test of this work is not the number. It is **whether someone else can audit
 
 ## The hard stop: no named entities
 
-This skill produces understanding of a market **as a whole** — never a named buyer you can call today, never a named competitor dossier. The moment the ask turns into "who specifically," stop and route:
-
-- "Give me 200 fintech accounts with the VP Eng contact" → that is a sales list → `../lead-gen/SKILL.md`.
-- "Profile Competitor X — their tiers, gaps, recent launches" → that is a rival dossier → `../competitor-watch/SKILL.md`.
+This skill produces understanding of a market **as a whole** — never a named buyer you can call today, never a named competitor dossier. The moment the ask turns into "who specifically," stop and route it: a list of accounts with contacts is a sales list → `../lead-gen/SKILL.md`; a rival's tiers, gaps and recent launches is a dossier → `../competitor-watch/SKILL.md`.
 
 Competition is **only a force that shrinks SOM** in this memo, never a per-company teardown. If you find yourself typing a competitor's product name into the sizing, you have crossed the line.
 
 ## The three jobs
 
-| Job | One governing rule | Failure if skipped |
-| --- | --- | --- |
-| **Size it** | Never ship a number without a second, independent method | A lone figure is unfalsifiable; readers discount it |
-| **Segment it** | Cut by the *job buyers hire you for*, then prove the slice is reachable AND distinct | A market with no beachhead is a market you can't enter |
-| **Read demand** | Secondary to form the hypothesis, primary to decide it | You confirm your own bias with stale reports |
+| Job | One governing rule |
+| --- | --- |
+| **Size it** | Never ship a number without a second, independent method |
+| **Segment it** | Cut by the *job buyers hire you for*, then prove the slice is reachable AND distinct |
+| **Read demand** | Secondary to form the hypothesis, primary to decide it |
 
-Do them in order — sizing tells you what to segment, segments tell you where to read demand. The artifact at the end ties all three together with a sources table. That memo is what `scripts/verify.sh` lints.
+Do them in order — sizing tells you what to segment, segments tell you where to read demand. The artifact at the end ties all three together with a sources table.
 
 ## Job 1 — Size it (triangulate or it's a guess)
 
@@ -39,7 +36,6 @@ Two instruments, two different errors. Run **both** and force them to agree.
 | --- | --- | --- | --- | --- |
 | **Top-down** | A published industry figure (Gartner/IDC/Statista, e.g. "$70B CRM market") | `industry size × your segment share %` | Fast, anchors to a named source | Inherits and amplifies the report's error; easy to hand-wave the share % |
 | **Bottom-up** | Your customers + price | `ACV × number of ICP-fitting accounts` | Grounded in your own pricing; survives investor scrutiny | Slow; needs a real ICP and a real account count |
-| **Triangulation** | BOTH of the above | Run both, force them to agree | The actual credibility signal | Skipping it — a lone number is a guess |
 
 ### The triangulation gate
 
@@ -58,7 +54,7 @@ Good  Bottom-up:  960 ICP accounts × $50K ACV       = $48M
 - **SAM** — the slice your business model + geography can actually serve.
 - **SOM** — the slice you can realistically capture near-term, given competition and sales capacity.
 
-The funnel `SAM ≈ 20% of TAM`, `SOM ≈ 10% of SAM` is an **illustrative example to defend, not a constant to assume.** Derive SAM from your real reach (model, geography, language) and SOM from the competitive pressure and your sales capacity — then state why. Worked top-down and bottom-up calculations, the convergence math, and the full memo template live in `references/sizing-playbook.md`.
+The funnel `SAM ≈ 20% of TAM`, `SOM ≈ 10% of SAM` is an **illustrative example to defend, not a constant to assume.** Derive SAM from your real reach (model, geography, language) and SOM from the competitive pressure and your sales capacity — then state why. Worked top-down and bottom-up calculations, the convergence math, the SAM-then-SOM derivation logic, and the full memo template with its sources/provenance schema live in `references/sizing-playbook.md`.
 
 ## Job 2 — Segment it (reachable AND distinct, with a named beachhead)
 
@@ -108,15 +104,15 @@ This is exactly what `scripts/verify.sh` checks. Keep it Markdown so the linter
 | "$50B market" with no source or year | Cite the report + access date for every figure | Undated/unsourced = a guess; markets move fast |
 | Top-down and bottom-up are 4× apart, pick the bigger | Re-check inputs until they converge ≤~20% | 3–5× divergence means broken assumptions, not a choice |
 | Convert a Google Trends curve into a market size | Pair with absolute-volume tools before sizing | Trends is RELATIVE interest, never absolute volume |
-| Segment by demographics alone | Add JTBD/behavioral; name a reachable beachhead | Demographics miss *why* people actually buy |
+| Segment by demographics alone | Add JTBD/behavioral; name a reachable beachhead | Demographics miss *why* people buy, and a market with no beachhead is one you can't enter |
 | Treat SAM/SOM as fixed 20%/10% of TAM | Derive SAM from reach, SOM from competition + capacity | Those ratios are illustrative, not constants |
 | Name specific competitor products in the memo | Treat competition as a SOM-shrinking force | A dossier is scope creep — hand to competitor-watch |
 | List named target accounts as "the market" | Hand the segment to lead-gen to build the list | That is a sales list, not market understanding |
-| All secondary data, no primary check on the decisive question | Use interviews/survey to fill the gap that decides | Stale or misaligned reports mislead the call |
+| All secondary data, no primary check on the decisive question | Use interviews/survey to fill the gap that decides | Stale or misaligned reports mislead the call — you just confirm your own bias |
 
 ## Verify
 
-The memo is a checkable artifact, so `scripts/verify.sh` lints a produced memo file (read-only — it never edits) for the three things that keep "market sizing" honest:
+The memo is a checkable artifact, so `scripts/verify.sh` lints a produced memo file (read-only — it never edits) for the three things above that keep "market sizing" honest: the numeric `SOM ≤ SAM ≤ TAM` nesting, **both** methods plus a stated convergence/divergence note (one method alone fails), and a citation **and** date on every load-bearing figure.
 
 ```bash
 ./scripts/verify.sh                     # scan ./ for *memo*/*market*.md
@@ -125,7 +121,7 @@ The memo is a checkable artifact, so `scripts/verify.sh` lints a produced memo f
 ./scripts/verify.sh --strict            # treat warnings as failures (CI gate)
 ```
 
-It asserts: (a) **TAM, SAM, SOM** all present with parseable numeric values and the nesting `SOM ≤ SAM ≤ TAM` holds; (b) evidence of **both** a top-down and a bottom-up figure plus a stated **convergence/divergence** note — fails if only one method is present; (c) a **sources** section where each load-bearing figure carries a citation/URL AND a date. It exits `0` on a clean or empty target — a missing memo is a skip, never a false failure. The memo schema it enforces is documented in `references/sizing-playbook.md`.
+It exits `0` on a clean or empty target — a missing memo is a skip, never a false failure.
 
 ## Hand-offs
 
@@ -138,8 +134,3 @@ The memo is the start of a chain. When it is done, route:
 - Set the ACV the bottom-up math depends on → `../pricing/SKILL.md`.
 - Project the demand series forward from history → `../forecasting/SKILL.md`.
 - Act on the keyword/topic demand signals → `../content-engine/SKILL.md`.
-
-## references/
-
-- `references/sizing-playbook.md` — worked top-down and bottom-up calculations side by side, the triangulation convergence math (≤~15–20% credible, 3–5× broken), the SAM-then-SOM derivation logic, and the full market-memo template including the mandatory sources/provenance table schema.
-- `references/demand-signals.md` — the signal-source catalog (Google Trends + its relative-volume caveat, Exploding Topics, Statista, government/industry data, primary survey/interview design) and a source-grading rubric for vetting secondary data by recency and credibility.

package/skills/market-research/evals/cases.yaml

@@ -2,7 +2,7 @@ skill: market-research
 
 should_trigger:
   - prompt: "How big is the market for AI legal-research tools in Spain?"
-    why: Core sizing request — "how big is the market for X" is the central trigger.
+    why: Core sizing request for a whole market — Job 1, the central case for this skill.
   - prompt: "Sanity-check this TAM before our seed raise — does $2B hold up?"
     why: Non-obvious; cross-checking an existing number IS the triangulation core, not deck design or modeling.
   - prompt: "Cut our addressable market into segments and tell me which one to attack first."
@@ -12,9 +12,9 @@ should_trigger:
   - prompt: "Should we size this top-down from the industry report or bottom-up from our customers?"
     why: Non-obvious; the top-down-vs-bottom-up choice and triangulation gate are this skill's method, not a generic data pull.
   - prompt: "¿Qué tamaño tiene el mercado de software de reservas para restaurantes y cuál es el TAM/SAM/SOM?"
-    why: Spanish trigger for the full sizing job — TAM/SAM/SOM explicitly requested.
+    why: Spanish-language ask for the full sizing job — TAM/SAM/SOM explicitly requested.
   - prompt: "Quina mida té el mercat d'apps de reserves i hi ha demanda real?"
-    why: Catalan trigger combining market size and demand validation — both core jobs.
+    why: Catalan-language ask combining market size and demand validation — both core jobs.
 
 should_not_trigger:
   - prompt: "Profile Competitor X — their pricing tiers, feature gaps, and recent product launches."

package/skills/meeting-notes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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)."
+description: "Use when a meeting just ended and a transcript or rough notes must become a record the absent can act on — decisions with their why, actions with an owner and a real date, open questions, a recap inside 24–48h — or to clean an AI-notetaker draft that invented tasks or swapped speakers. NOT the durable ADR with alternatives weighed (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
@@ -12,16 +12,16 @@ origin: risco
 
 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
+## Not this skill
 
-- 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.
+| If the ask is… | Route to |
+|---|---|
+| The **durable decision record** — full rationale, alternatives weighed, reversibility argued, 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; their lifecycle is not its job |
+| **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) |
 
 ## The capture loop
 
@@ -69,15 +69,11 @@ go/no-go by Jun 12, payments integration is still open.
 - 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.)
+Four filled versions of this skeleton — decision meeting, standup/sync, retro, 1:1 — plus copy-paste action-item and decision rows are in [`references/templates.md`](references/templates.md).
 
 ## 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".
+A complete action item is **`verb, owner, by <real date>`**: verb-first ("Draft…", "Spike…", "Send…", "Confirm…"), **one named person** — not "the team", not "we", since shared ownership means nobody owns it — and **a real date** ("by Tue Jun 9", never "next week", "soon", or "ASAP"). Explicit dates and named owners raise completion and ownership. (Umbrex, accessed 2026-06-02.)
 
 Bad → Good:
 
@@ -98,7 +94,7 @@ Add **RACI only when ownership is genuinely contested** — a cross-team decisio
 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.)
+2. **One sentence of why** — the trade-off or context. Every major decision gets one; a decision with no why rots, and six weeks later nobody remembers what trade-off it solved. (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.)
@@ -109,7 +105,7 @@ 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.
+When a decision needs the full ADR — alternatives weighed, reversibility argued, a review date — that is [`decision-records`](../decision-records/SKILL.md)' job. Capture it here in context, then hand it off. Don't grow an ADR inside the meeting notes.
 
 ## Working with AI transcripts
 
@@ -129,14 +125,7 @@ Recording a conversation carries real legal and confidentiality exposure. (Justi
 
 - **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.
+- **Redact** names, secrets, and confidential details before distribution if the audience is wider than the room — and tighten distribution on anything sensitive.
 
 ## Distribution
 
@@ -162,7 +151,3 @@ Then route, don't fork. Action items → a tracker via [`project-ops`](../projec
 | 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.