@ericrisco/rsc 0.1.44 → 0.1.45

package/skills/content-engine/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: content-engine
-description: "Use when a content operation needs a SYSTEM — a dated editorial calendar built top-down from pillars and a production pipeline that moves every slot through stages — not when writing one piece. Use for building/refreshing an editorial calendar, defining pillars/clusters/cadence/mix, standing up stage gates and a brief template, planning the 1:10 atomization of a flagship into derivatives, or setting WIP limits and the calendar of record. Triggers: 'build a content calendar', 'set up a content pipeline', 'what should we post and when', 'turn this pillar post into everything', 'our content is chaos, nobody knows what to post' (symptom, no calendar word), 'móntame un calendario de contenidos', 'atomiza este artículo en piezas'. NOT writing the pieces (that is article-writing), NOT distributing them (that is social-publisher), NOT keyword/cluster research (that is seo-geo), NOT codifying tone (that is brand-voice)."
+description: "Use when a content operation needs a SYSTEM: a dated editorial calendar built top-down from pillars, plus the stage gates, briefs, WIP limits and 1:10 atomization plan that move each slot to publish-ready. NOT writing the pieces (that is `article-writing`), NOT publishing them (that is `social-publisher`), NOT keyword research (that is `seo-geo`)."
 tags: [content, editorial-calendar, content-pipeline, repurposing, marketing-ops]
 recommends: [brand-voice, seo-geo, social-publisher, article-writing, video-shorts, newsletter, automation-flows]
 origin: risco
@@ -8,17 +8,10 @@ origin: risco
 
 # Content Engine — The Calendar and the Pipeline That Feeds It
 
-*The factory floor and the production schedule, not the words off any single station.* You own two machines: the **calendar** (what gets made and when) and the **pipeline** (how each slot moves from idea to publish-ready). You do not write the pieces and you do not publish them — you decide what gets made, you spec the brief, and you route each station to a specialist.
+*The factory floor and the production schedule, not the words off any single station.* You own two machines: the **calendar** (what gets made and when — a dated, slotted plan anchored to pillars, so "what do we post Thursday?" is a lookup, not a weekly panic) and the **pipeline** (how each slot moves from idea to publish-ready through stage gates, so output is consistent regardless of who writes). You do not write the pieces and you do not publish them — you decide what gets made, you spec the brief, and you route each station to a specialist.
 
 Content fails not from one bad post but from **no system**: no documented cadence, no brief, no stage gate, pillars that never get atomized. ~78% of high-performing content teams run a documented strategy and see ~3x the engagement of teams without one (InfluenceFlow, 2026). This skill is that system.
 
-## The two machines
-
-- **Calendar = what + when.** A dated, slotted plan anchored to pillars. "What do we post Thursday?" becomes a lookup, not a weekly panic.
-- **Pipeline = how it moves.** Every slot travels `idea → brief → draft → edit → atomize → publish-ready` through stage gates, so output is consistent regardless of who writes.
-
-**Hard rule: build top-down, slot last.** Personas → Pillars → Clusters → Assets, in that order. The calendar is derived from this architecture; it is never a bottom-up pile of "post ideas." Bottom-up calendars are the #1 failure mode — they have no theme, no leverage, and no reason any given post exists. *Why: structure makes topic choice a lookup, not a creative emergency every Monday.*
-
 ## Ground first (STOP gate)
 
 You plan content for a real brand; you do not invent its strategy. Before building anything, read what already exists.
@@ -31,6 +24,8 @@ You plan content for a real brand; you do not invent its strategy. Before buildi
 
 ## Build the calendar
 
+**Build top-down, slot last.** Personas → Pillars → Clusters → Assets, in that order. The calendar is derived from this architecture; it is never a bottom-up pile of "post ideas." Bottom-up calendars are the #1 failure mode — they have no theme, no leverage, and no reason any given post exists. *Why this one is absolute: structure makes topic choice a lookup, not a creative emergency every Monday.*
+
 **Four-layer architecture (counts are defaults, state them):**
 
 | Layer | Count | What it is |
@@ -105,13 +100,6 @@ Full template with a filled example → `references/brief-and-pipeline.md`. *Why
 
 **WIP limits matter more than throughput.** Cap in-flight slots per the team-size table; pulling a new idea before finishing the last one is how the calendar becomes a graveyard.
 
-**Who fills each station — route, do not write:**
-
-- Draft/edit of a long-form article → `../article-writing/SKILL.md`.
-- Newsletter issue copy → `newsletter`.
-- Short-form video script/storyboard → `video-shorts`.
-- Landing/launch page copy → `../marketing/SKILL.md`.
-
 **AI is a station, not the author.** Use AI for research, outlines, drafts, repurposing, and angle-testing. Humans decide which pillars matter, which stories to tell, and what "good" is. Voice is grounded via `brand-voice`, never invented (Entasher 2025-11-29).
 
 ## Atomization (1:10)

package/skills/context-budget/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: context-budget
-description: "Use when a long-horizon task is filling the context window and you must decide what to keep, offload, drop, or hand off — large refactors and migrations that won't fit one window, multi-hour research/agent runs, planning a harness that survives across fresh sessions, or deciding when to compact and whether to spawn a subagent. Triggers: 'we're 80% through context, compact before it breaks', 'context is 80% full', 'make this survive a fresh window', 'this conversation is getting huge', 'should I spawn a subagent for this huge log read or just inline it', 'the agent keeps re-reading the same files and forgetting decisions it made earlier', 'se está llenando el contexto, ¿qué guardo y qué tiro?', 'compacta abans que peti'. NOT dollar spend or budget caps (that is cost-tracking), NOT fetching context via embeddings (that is rag)."
+description: "Use when a long-horizon task is filling the context window and you must decide what to keep, offload, drop, or hand off to a fresh window — when to compact, what the summary must preserve, and whether to isolate a read-heavy subtask in a subagent. NOT dollar spend or caps (that is cost-tracking), NOT finding context via embeddings (that is rag)."
 tags: ["context-window", "token-budget", "compaction", "context-rot", "long-running-agents", "handoff", "subagents"]
 recommends: ["cost-tracking", "rag", "parallel", "building-agents", "harness"]
 origin: risco
@@ -12,21 +12,7 @@ The context window is RAM, not a hard drive. Full ≠ free: a window stuffed to
 
 > **The one rule:** if you can reconstruct a thing from a file or from git, it does not belong resident in the window. Keep load-bearing-right-now; evict the rest. The cost of forgetting is one re-read; the cost of hoarding is silent quality rot on every turn that follows.
 
-## When to use this
-
-- A task is plainly bigger than one window: a large refactor, a multi-file migration, "build the whole app", a multi-hour research or agent run.
-- You feel degradation before the gauge confirms it: repeating yourself, re-reading files you already read, drifting from the plan, contradicting an earlier decision.
-- You are setting up a harness that must survive across many sessions and fresh windows.
-- You are deciding *when* to compact, *what* to preserve, or *whether* to spawn a subagent vs. inline a big read.
-
-## When NOT to use (and where to go)
-
-- Pricing tokens, ledgering spend, firing a budget alert or a hard `$` cap → `../cost-tracking/SKILL.md`. That skill owns *money*; this one owns *working-memory quality*. Same words ("token budget"), different unit: dollars vs. attention.
-- Finding the *right* context to inject via embeddings/chunking → `../rag/SKILL.md`. RAG is *how you find* context; this is *how much* you let live and *when to evict*.
-- Crafting the prompt text, few-shot, or output format → `../prompt-engineering/SKILL.md`.
-- Designing the agent loop, tool schemas, or provider adapter → `../building-agents/SKILL.md`.
-- Fanning out genuinely independent work → `../parallel/SKILL.md`. This skill *uses* subagents as a context-isolation tactic and points there, but does not own the partition-then-gather discipline.
-- The 01-TOOLS / 02-DOCS control plane of a whole workspace → `../harness/SKILL.md`.
+Neighbours, so you don't do their job here: pricing tokens, spend ledgers and hard `$` caps are `../cost-tracking/SKILL.md` — same words ("token budget"), different unit, dollars vs. attention. Finding the *right* context via embeddings/chunking is `../rag/SKILL.md`; RAG is *how you find* context, this is *how much* you let live and *when to evict*. Prompt text, few-shot and output format are `../prompt-engineering/SKILL.md`; the agent loop, tool schemas and provider adapters are `../building-agents/SKILL.md`; partition-then-gather fan-out of independent work is `../parallel/SKILL.md` (this skill *uses* subagents as a context-isolation tactic but does not own that discipline); the 01-TOOLS / 02-DOCS control plane is `../harness/SKILL.md`.
 
 ## Read the gauge first
 
@@ -102,7 +88,7 @@ drop: the exploratory diffs and the debugging transcript.
 
 When the task is bigger than one window, the win is making a *fresh* window resume the work in a single read. The long-running harness pattern (Anthropic, "Effective harnesses for long-running agents", published 2025-11-26, accessed 2026-06-02) is: an initializer session sets up the work, then each coding session works **one unit at a time** and leaves a structured update — a progress log (e.g. `claude-progress.txt`) plus git history plus a structured feature list — so the next window reconstructs state without you re-explaining it.
 
-Write the handoff *before* you run out of room, not after quality already cratered. The template (Goal / Done / In-progress / Next / Gotchas / Key paths) is in `references/handoff-and-compaction.md`.
+Write the handoff *before* you run out of room, not after quality already cratered. The template (Goal / Done / In-progress / Next / Gotchas / Key paths) and a good-vs-bad summary checklist are in `references/handoff-and-compaction.md`.
 
 ## Budget allocation heuristic
 
@@ -126,7 +112,3 @@ A starting split for a production agent's window — a **heuristic, not a law**
 | Paste a subagent's full transcript back into the parent | Defeats the entire point of isolation — the child's bloat lands in the parent | Take back only the answer/artifact, never the transcript |
 | Treat the window as infinite because the model "has 1M" | Context rot scales with tokens regardless of the limit | Budget against attention, not the advertised ceiling |
 | Carry dead-end exploration forward | The journey isn't the decision; it's pure noise | Reduce to the conclusion + the commit that proves it |
-
-## Reference
-
-`references/handoff-and-compaction.md` — the server-side compaction API contract (exact header, edit type, trigger defaults/min, `pause_after_compaction`, the append-the-block rule, default summary prompt), a copy-paste progress-file template, and a good-vs-bad summary checklist. Offloaded here because it's API-version-specific and rots fastest.

package/skills/continuous-learning/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: continuous-learning
-description: "Use when something went wrong, got corrected, surprised you, or otherwise taught the workspace something and you want it to stick — a retro or postmortem after an incident or sprint, the same agent mistake corrected 2+ times, a wrong assumption that just surfaced, a resolved bug worth never repeating, or scattered notes-to-self that need a durable home. Triggers: 'run a retro', 'capture this lesson', 'write this down so we don't repeat it', 'you keep doing X — make it stop for good', 'harvest the corrections and notes-to-self into wherever they belong', 'guarda esta lección para que no vuelva a pasar', 'apúntalo para no repetir el error'. NOT capturing a forward design choice with alternatives (that is decision-records)."
+description: "Use when a mistake, correction, or surprise taught the workspace something that must stick — a retro or postmortem, the same agent error corrected twice, a resolved bug's root cause, scattered notes-to-self — and route that lesson to the durable surface that fires next time. NOT a forward choice with alternatives (that is `decision-records`)."
 tags: [learning, retro, postmortem, feedback-loop, knowledge, meta]
 recommends: [decision-records, author-skill, debug, harness, knowledge-ops]
 origin: risco
@@ -12,43 +12,21 @@ This is the engine that makes the system get better every time it is wrong. When
 
 One premise is load-bearing: **a lesson that lives only in chat is gone at the next compaction.** Verbal reflection only changes future behaviour when it is persisted to memory the agent actually reads next time (this is the Reflexion mechanism — self-reflection written to durable memory, not held in the conversation). In this harness, "memory" is a concrete set of surfaces: a `SKILL.md` body, `02-DOCS/wiki/harness/decisions.md`, `02-DOCS/wiki/harness/user-profile.md`, a root `CLAUDE.md` rule, or a `verify.sh` check. **Chat is not memory.** A lesson is "captured" only when it has landed in one of those.
 
-You sit between three siblings. `harness` self-improves the *wiki*. `decision-records` captures *forward* choices (we will do X, here is why). You capture *backward* lessons — what we now know that we didn't, and the cheapest durable place to keep it from biting again. You do not own the craft of editing skills (that is `author-skill`) and you do not diagnose bugs in the moment (that is `debug`); you run *after* debug resolves and harvest the root cause.
+Read `02-DOCS/wiki/harness/user-profile.md` for the accompaniment dial before you narrate. It governs narration only — the capture loop runs identically at every level.
 
-## Read the user profile first
-
-Before you narrate anything, read `02-DOCS/wiki/harness/user-profile.md` for the **accompaniment dial**, same convention as every harness skill:
-
-- **L0** — capture the lesson silently, land the durable write, move on. No play-by-play.
-- **L1–L2** — state the root cause and the home in a line or two.
-- **L3** — walk the root-cause reasoning out loud and confirm the durable home with the user before writing.
-
-The dial governs narration only. The capture loop runs at every level — the difference is how much you say while doing it.
-
-## When to use
-
-- A retro / postmortem: "what did we learn from this incident or this sprint".
-- A recurring correction — the user has fixed the same agent mistake 2+ times ("you keep doing X — stop").
-- A surprise: an assumption was wrong, a command failed in a non-obvious way, a provider behaved unexpectedly, an eval missed a real bug.
-- After `debug` resolves: distil the non-obvious root cause into a durable note before it evaporates.
-- A periodic sweep: harvest scattered corrections / TODOs / notes-to-self into their right durable homes.
-
-## When NOT to use
-
-- **A forward decision with alternatives** (we chose X over Y, here is why) → `../decision-records/SKILL.md`. A choice is not a lesson from a mistake.
-- **Authoring/editing a skill's body, description, or evals** as the task → `../author-skill/SKILL.md`. You *decide* a lesson belongs in skill Z and hand the edit over; you do not own SKILL.md craft.
-- **Diagnosing the bug right now** → `../debug/SKILL.md`. You come after.
-- **Generic doc/wiki consolidation or inbox sweep** → `../harness/SKILL.md` 02-DOCS engine. You produce the occasional wiki article *via* that protocol; your trigger is "we learned something the hard way", not "organise these docs".
-- **Scheduling a recurring task** → `loop` / `schedule` harness CLI. You may *recommend* a cadence; you are not a scheduler.
-- **Curating reference knowledge / "what do I know about X"** → `../knowledge-ops/SKILL.md`. That is reference knowledge; you handle experiential, mistake-derived knowledge.
+## Boundaries
 
 | Situation | Owner | Why |
 |---|---|---|
-| "We chose Postgres over Mongo, here's the why + the rejected options" | `decision-records` | forward choice with alternatives |
+| "We chose Postgres over Mongo, here's the why + the rejected options" | `../decision-records/SKILL.md` | forward choice with alternatives; a choice is not a lesson from a mistake |
 | "The migration failed because Postgres rejects NULL on the PK — never assume that again" | `continuous-learning` | backward lesson from a mistake |
-| "Find the bug causing the 500" | `debug` | in-the-moment diagnosis |
+| "Find the bug causing the 500" | `../debug/SKILL.md` | in-the-moment diagnosis; you run after it resolves |
 | "Now that debug found it, make sure we never ship that pattern again" | `continuous-learning` | post-resolution capture |
-| "Write the SKILL.md and evals for pr-describe" | `author-skill` | skill craft |
-| "This lesson means the deploy skill needs a new guardrail" | `continuous-learning` → hands edit to `author-skill` | decides home, delegates craft |
+| "Write the SKILL.md and evals for pr-describe" | `../author-skill/SKILL.md` | skill craft — body, description, evals |
+| "This lesson means the deploy skill needs a new guardrail" | `continuous-learning` decides the home → `../author-skill/SKILL.md` makes the edit | you route, it writes |
+| "Consolidate these docs / sweep the inbox" | `../harness/SKILL.md` | generic 02-DOCS filing; your trigger is "we learned something the hard way" |
+| "What do I know about X" | `../knowledge-ops/SKILL.md` | reference knowledge, as opposed to mistake-derived experiential knowledge |
+| "Run this sweep every week" | `loop` / `schedule` harness CLI | you may recommend a cadence; you are not a scheduler |
 
 ## The capture loop
 
@@ -126,11 +104,3 @@ To harvest scattered corrections and notes-to-self on a cadence, do not reimplem
 | Capturing a forward choice here | that is a decision, not a lesson | route to `decision-records` |
 | A vague vector-blob note | won't retrieve, can't be acted on | situation-tag it in the entry format |
 | Starting to diagnose the bug | that is `debug`'s job | come here *after* it resolves, with the root cause |
-
-## Cross-references
-
-- `../decision-records/SKILL.md` — forward choices with alternatives.
-- `../author-skill/SKILL.md` — the writer for any lesson whose home is a skill body, description, or eval.
-- `../debug/SKILL.md` — in-the-moment diagnosis; you run after it.
-- `../harness/SKILL.md` — the wiki ingest/sweep engine and the durable surfaces you route into.
-- `../knowledge-ops/SKILL.md` — reference knowledge, as opposed to mistake-derived experiential knowledge.

package/skills/contracts/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: contracts
-description: "Use when drafting or reviewing everyday business contracts and clauses in plain language — NDAs, MSAs, SOWs, consulting/contractor agreements, and the boilerplate that allocates risk (liability caps, indemnity, force majeure, termination, governing law); symptoms include a counterparty's paper you must redline, a one-sided clause, or a draft a founder can't read. Triggers: 'draft an NDA', 'review this MSA', 'write an SOW under our MSA', 'redline their termination clause', 'add a liability cap', 'make this indemnity mutual', 'rewrite this clause in plain English', 'revisa este contrato', 'redacta un acord de confidencialitat'. NOT consumer website Terms of Service (that is terms-conditions) and NOT the signing workflow (that is e-signature)."
+description: "Use when drafting or reviewing business contracts and clauses in plain language — NDAs, MSAs, SOWs, contractor agreements, risk boilerplate (liability caps, indemnity, force majeure, termination, IP) — or redlining a counterparty's paper. NOT consumer Terms of Service (that is terms-conditions) and NOT the signing workflow (that is e-signature)."
 tags: [contracts, legal, ndas, msa, sow, clauses, redlining, risk-allocation]
 recommends: [terms-conditions, e-signature, gdpr-privacy, proposals, ip-trademark, invoicing]
 origin: risco
@@ -10,12 +10,6 @@ origin: risco
 
 You draft and review everyday business contracts and individual clauses in plain language. You are not a lawyer and you never say you are. Your job is to produce a clean, redline-ready draft or a risk-flagged review that a founder can actually read — and to hand off anything that allocates real liability to a licensed attorney before it is signed.
 
-Three rules sit above everything below. Break them and the output is worse than useless — it is a false sense of safety.
-
-1. **Plain English by default.** A contract nobody can read is a contract nobody can negotiate. Define a term once, then reuse it; one obligation per sentence; numbers for money and days.
-2. **Name the risk each clause allocates.** Every clause moves money or blame from one party to the other when something goes wrong. State who pays, in one line, beside the clause.
-3. **Always recommend licensed-attorney review before signing** anything that allocates real liability or crosses a jurisdiction you cannot verify. Non-lawyers — and AI — cannot give legal advice (UPL statutes exist in every US state; ABA Formal Opinion 512, issued 2024-07-29, keeps the attorney fully responsible for AI-generated legal work). You draft and flag; a lawyer signs off.
-
 ## First move: identify the instrument and the side
 
 Before drafting a word, fix two things: **which instrument** this is, and **which side the operator is on**. Every default flips on the side. A liability cap that is generous to the buyer is dangerous to the seller; an indemnity that protects the discloser exposes the recipient. Ask "are we the buyer or the seller? the discloser or the recipient?" first.
@@ -63,7 +57,7 @@ Good: Either party may terminate if the other materially breaches and fails to
 
 ## The clauses that allocate risk
 
-These are the heart of any commercial agreement. For each: what it allocates, the safe default, the carve-outs. Copy-ready text lives in `references/clause-library.md`.
+Every clause below moves money or blame from one party to the other when something goes wrong, so state who pays in one line beside the clause you emit. For each: what it allocates, the safe default, the carve-outs. Copy-ready text lives in `references/clause-library.md`.
 
 **Limitation of liability** — allocates *how much* one party can lose when the deal goes wrong. Safe default: aggregate liability capped at the fees paid in the trailing 12 months. Carve-outs (uncapped) for breach of confidentiality and indemnity obligations. You *cannot* cap liability for fraud, intentional misconduct, or bodily harm — courts will strike those exclusions, so don't write them.
 
@@ -89,7 +83,7 @@ When the operator hands you the other side's draft, pass through it in this orde
 
 Separate **non-negotiables** (uncapped liability, one-way indemnity, IP grab that takes your background IP) from **nice-to-haves** (a longer cure period, tighter notice). Spend your leverage on the first list.
 
-Tells of a one-sided draft: uncapped indemnity; "mutual" obligations that only bind you on inspection; auto-renewal with a long opt-out notice window; a termination-for-convenience right only the counterparty holds; a liability cap with no confidentiality/indemnity carve-out (good for them, bad for you). The full demand/concede/flag checklist is in `references/review-playbook.md`.
+Tells of a one-sided draft: uncapped indemnity; "mutual" obligations that only bind you on inspection; auto-renewal with a long opt-out notice window; a termination-for-convenience right only the counterparty holds; a liability cap with no confidentiality/indemnity carve-out (good for them, bad for you). The full demand/concede/flag checklist per clause, plus the MSA↔SOW reconciliation steps, is in `references/review-playbook.md`.
 
 ## MSA + SOW: rulebook and playbook
 
@@ -97,10 +91,10 @@ The MSA is the rulebook — it governs services, payment, and liability for the
 
 Before signing an SOW under an existing MSA, cross-check that the SOW does not contradict the MSA (a different liability cap or payment term hidden in the SOW is a trap). Reconcile any conflict explicitly — state which document controls — before either is signed.
 
-## The legal boundary (non-negotiable)
+## The legal boundary
 
-- **You do not give legal advice.** Every US state's Unauthorized Practice of Law statutes bar non-lawyers from drafting legal documents for others or advising on them; AI providers disclaim liability for errors. You draft and review and flag — that's it.
-- **Emit the attorney-review line** on any full-contract draft or any edit that allocates real liability: "Have a licensed attorney review this before signing." Non-negotiable on liability-allocating work.
+- **You do not give legal advice.** Every US state's Unauthorized Practice of Law statutes bar non-lawyers from drafting legal documents for others or advising on them; ABA Formal Opinion 512, issued 2024-07-29, keeps the attorney fully responsible for AI-generated legal work, and AI providers disclaim liability for errors. You draft and review and flag — that's it.
+- **Emit the attorney-review line** on any full-contract draft, any edit that allocates real liability, or any jurisdiction you cannot verify: "Have a licensed attorney review this before signing." This one is absolute — without it a draft reads as cleared to sign, which is the false sense of safety that gets people hurt.
 - **Warn before pasting confidential paper into untrusted AI tools.** ABA Op. 512 advises informed consent before inputting confidential information into self-learning public tools. If the operator is about to paste a counterparty's confidential contract somewhere unvetted, say so first.
 - **Hand off the edges:** the signing flow (signer order, audit trail, ESIGN/UETA/eIDAS compliance of the signature itself) → `../e-signature/SKILL.md`; consumer-facing site policies → `../terms-conditions/SKILL.md`; privacy substance of a DPA or how personal data is processed → `../gdpr-privacy/SKILL.md`; the pitch that wins the deal (not the binding paper) → `../proposals/SKILL.md`; trademark/IP strategy beyond a contract clause → `../ip-trademark/SKILL.md`; the customer invoice as a billing artifact → `../invoicing/SKILL.md`.
 
@@ -117,8 +111,3 @@ A note on signatures so you don't over-promise: a contract or signature cannot b
 | Exhaustive force-majeure list with no catch-all | The one event that happens is the one not listed | Defined term + catch-all + notice + mitigation + terminate-if-persists |
 | Claims the draft is "legally binding" or "safe" without attorney review | Crosses into legal advice and UPL; AI errors are disclaimed | State you are not a lawyer; emit the attorney-review line on liability-allocating work |
 | Pastes a counterparty's confidential contract into an untrusted tool | Leaks confidential terms; breaches ABA Op. 512 guidance | Warn the operator and get informed consent before inputting confidential text |
-
-## References
-
-- `references/clause-library.md` — copy-ready, plain-language clause templates with `[BRACKETED]` fill-ins and a one-line "what this allocates" note each.
-- `references/review-playbook.md` — the demand/concede/flag checklist per clause, one-sided-draft tells, and MSA↔SOW reconciliation steps.

package/skills/coolify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: coolify
-description: "Use when self-hosting apps, managed databases and deploys on a VPS you own with Coolify instead of paying a managed PaaS — installing Coolify on a fresh Ubuntu/Debian box, claiming the first-admin account, deploying from a Git repo (Nixpacks/Railpack/Dockerfile/compose), provisioning Postgres/MySQL/MongoDB/Redis in-product, wiring scheduled DB backups to S3-compatible storage, or custom domains + automatic SSL via the built-in Traefik proxy. Triggers: 'install Coolify', 'self-host my app on a cheap VPS', 'my Vercel/Heroku bill is killing me, move it to a box I own', 'control plane on my own server', 'nightly Postgres backups to R2 in Coolify', 'montar mi propio PaaS en un VPS barato con Coolify', 'autoallotjar les meves apps amb Coolify'. NOT the managed push-and-forget PaaS where someone else owns the box (that is railway), NOT sizing/hardening the VPS itself (that is hetzner / digitalocean), NOT generic Docker image authoring (that is docker)."
+description: "Use when self-hosting apps and databases with Coolify on a VPS you own — install, first-admin lockdown, Git-to-deploy (Nixpacks/Dockerfile/compose), managed Postgres/Redis, scheduled S3 backups, domains + auto-SSL. NOT a PaaS someone else runs (that is `railway`), NOT sizing/hardening the box (that is `hetzner`), NOT authoring Dockerfiles (that is `docker`)."
 tags: [coolify, self-hosting, paas, vps, docker, deployment, devops]
 recommends: [hetzner, digitalocean, docker, postgresdb, backups, domains-dns, github-actions]
 origin: risco
@@ -65,7 +65,9 @@ curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
 Why root: the installer wires Docker and system services; the docs state non-root is not fully supported.
 Why claim immediately: the registration page is open until someone takes it.
 
-Full install transcript, non-LTS/other-OS notes, and dashboard-domain setup → `references/install-and-proxy.md`.
+Full install transcript, non-LTS/other-OS steps, dashboard-domain setup, Traefik (default) vs Caddy,
+wildcard domains + the DNS-01 challenge, and common SSL failures with their fixes →
+`references/install-and-proxy.md`.
 
 ## Port & firewall matrix
 
@@ -106,7 +108,8 @@ Then:
 4. **Attach the domain + SSL** — add `app.example.com`, point its DNS A record at the box (DNS itself is
    the `domains-dns` skill), and the Traefik proxy provisions Let's Encrypt automatically on ports 80/443.
 
-Build-pack deep-dive + a worked, lint-clean compose example → `references/deploy-recipes.md`.
+Build-pack decision deep-dive plus a worked, lint-clean `docker-compose.yml` (env-ref secrets, named
+volumes, healthcheck, pinned image) — the verify.sh target → `references/deploy-recipes.md`.
 
 ## Managed databases
 
@@ -137,8 +140,8 @@ Backblaze B2, MinIO, Wasabi.
 4. **Run the restore drill — once, before you need it.** Download a dump, decompress, replay it into a
    throwaway DB, confirm the row counts. An untested backup is a guess. Schedule a recurring drill.
 
-Per-provider S3 setup, per-engine dump/restore commands, and the full restore runbook →
-`references/databases-and-backups.md`.
+S3 destination setup for R2/B2/MinIO/Wasabi/AWS, per-engine dump/restore commands, retention, the
+step-by-step restore runbook and its consistency caveats → `references/databases-and-backups.md`.
 
 ## Operate the box
 
@@ -174,15 +177,6 @@ without a named volume, a missing `healthcheck:`, or a floating `:latest` tag on
 and confirms the canonical port matrix (8000/80/443/6001/6002) is documented. Read-only, no network, no
 live deploy. Exits 0 on a clean/empty target.
 
-## References
-
-- `references/install-and-proxy.md` — full install transcript, non-LTS/other-OS steps, Traefik (default)
-  vs Caddy, wildcard domains + DNS-01 challenge, common SSL failures and fixes.
-- `references/databases-and-backups.md` — per-engine dump commands, S3 destination setup for
-  R2/B2/MinIO/Wasabi/AWS, retention, the step-by-step restore runbook, consistency caveats.
-- `references/deploy-recipes.md` — build-pack decision deep-dive and a worked, lint-clean
-  `docker-compose.yml` (env-ref secrets, named volumes, healthcheck, pinned image) — the verify.sh target.
-
 ## Project grounding (02-DOCS + CLAUDE.md)
 
 When this skill runs in a project with a `02-DOCS/` layer (the harness Karpathy wiki), record this

package/skills/cost-tracking/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cost-tracking
-description: "Use when you need to track and cap what an AI or cloud app spends — capturing per-request tokens, pricing them against a current rate table, ledgering spend per user/feature/model/tenant, and firing budget alerts or a hard cap before the bill lands instead of after. Triggers: 'track token costs per request', 'cap our OpenAI/Claude spend', 'budget alert before we blow the bill', 'attribute cost per user or tenant', 'a runaway agent loop just burned $X', 'is prompt caching actually cheaper and where is the break-even', 'why is our bill 3x the estimate', 'reconcile billed usage against the response usage object', 'cuánto gastamos en tokens este mes', 'pon un tope de gasto a la API y avísame al 80%', 'controlar el cost de la IA'. NOT company cash runway or burn (that is finance-ops), NOT cost-per-unit margin (that is unit-economics), NOT the accounting record of the spend (that is bookkeeping)."
+description: "Use when metering and capping AI or cloud app spend — tokens read from the response `usage` object, priced off a dated rate table, ledgered per user/tenant/feature, with alerts and a hard cap before the bill. NOT cash runway (that is `finance-ops`), NOT cost-per-unit margin (that is `unit-economics`), NOT booking the spend (that is `bookkeeping`)."
 tags: ["cost-tracking", "token-accounting", "llm-spend", "budgets", "alerts", "prompt-caching", "billing-guardrails", "finops"]
 recommends: ["finance-ops", "unit-economics", "analytics", "stripe", "aws-essentials", "gcp-essentials"]
 origin: risco
@@ -110,7 +110,7 @@ CREATE TABLE llm_cost_ledger (
 );
 ```
 
-This is an *operational* ledger, not the accounting record — categorizing the spend into the books is `bookkeeping`.
+This is an *operational* ledger, not the accounting record — categorizing the spend into the books is `bookkeeping`, and the same rows feed the cost numerator in `unit-economics` and one input line in `finance-ops`. "Cost per active user" on the behavior side is `analytics`; charging customers for metered usage is `stripe`.
 
 ## Budgets, alerts, caps
 
@@ -144,7 +144,7 @@ App-level metering is your real-time guard. Cloud billing alerts are a **delayed
 - **AWS** Cost Anomaly Detection is ML-based, runs ~3x/day with up to 24h data delay → SNS → Lambda. AWS Budgets adds threshold alerts on the same pipe.
 - **GCP/Azure** are threshold-only. GCP's budget → Pub/Sub → Cloud Function is the one that can actually *pause or throttle* a workload programmatically.
 
-Route every cloud alert into the **same alert pipe** as your app-level budget alerts so there's one place to look. The 24h delay is exactly why the in-app cap exists: by the time AWS notices the anomaly, the loop already spent the money. Recipes and the alert-routing pattern are in `references/cloud-caps.md`.
+Route every cloud alert into the **same alert pipe** as your app-level budget alerts so there's one place to look. The 24h delay is exactly why the in-app cap exists: by the time AWS notices the anomaly, the loop already spent the money. Recipes and the alert-routing pattern are in `references/cloud-caps.md`; the cap plumbing in depth is `aws-essentials` / `gcp-essentials`.
 
 ## Build vs buy
 
@@ -173,11 +173,3 @@ Route every cloud alert into the **same alert pipe** as your app-level budget al
 ## Verify the artifact
 
 `scripts/verify.sh [path]` lints a candidate cost config/ledger (yaml/json/ts) and fails if: a pricing entry lacks `effective_date` or `source`; a model referenced in logic is missing from the table; the ledger schema lacks an idempotency/request key or any attribution key; the budget declares no soft+hard pair; or cost looks derived from a `len()`/char estimate instead of a `usage` field. It is read-only and exits 0 on a clean config and on no config found — no false failure.
-
-## Where this hands off
-
-- Company cash runway / burn / forecast → `finance-ops` (cost-tracking is one input line).
-- Cost-per-unit margin, contribution, CAC:LTV → `unit-economics` (this produces the cost numerator).
-- "Cost per active user" behavior side / product telemetry → `analytics`.
-- Billing customers, metered usage charges → `stripe`.
-- The AWS/GCP cap plumbing in depth → `aws-essentials` / `gcp-essentials`.

package/skills/course-builder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: course-builder
-description: "Use when you must turn a vague \"I want to teach X\" into a defensible course/curriculum skeleton — writing measurable learning outcomes, designing assessment that proves them, sequencing modules, scoping a workshop/bootcamp/cohort/onboarding track, or building an outcome×module×assessment alignment matrix. Triggers: 'structure my course', 'turn these topics into a curriculum', 'write learning outcomes / objectives', 'design the final project and quizzes', 'map my modules to outcomes', 'is my course actually aligned?', 'my course just ends with no real endpoint — what should they be able to DO?', 'estructura el temario de mi curso', 'define los resultados de aprendizaje', 'dissenya el pla docent', 'quina avaluació demostra cada objectiu'. NOT making a concept land emotionally (that is course-storytelling)."
+description: "Use when turning \"I want to teach X\" into a defensible course skeleton — measurable outcomes (Bloom + ABCD), assessment that proves each one, sequenced modules, and an outcome×module×assessment matrix — for a workshop, bootcamp, cohort or onboarding track. NOT making one concept land emotionally with story or analogy (that is course-storytelling)."
 tags: [course, curriculum, instructional-design, learning-outcomes, assessment]
 recommends: [course-storytelling, presentations, sop-builder]
 origin: risco
@@ -12,21 +12,10 @@ origin: risco
 
 This skill owns the **skeleton**: the measurable outcomes, the assessment that certifies each one, the module sequence that builds toward them, and the alignment matrix tying it all together. It does not own the *teaching* of any one concept.
 
-## What this skill owns / does NOT own
-
-**Owns:** desired results (outcomes), acceptable evidence (assessment), build order (module sequence), and the outcome×module×assessment matrix that proves nothing is orphaned or unproven.
-
-**Does NOT own:**
-
-- Making a single concept *click and stick* emotionally — epiphany, sticky names, grounded analogies. That is `../course-storytelling/SKILL.md`. Build the skeleton HERE first, then hand each module there to make it land.
-- Auditing a *finished* course for gaps, redundancy, anachronisms with a written report → `../review/SKILL.md`.
-- Turning a designed module into slides/decks → `../presentations/SKILL.md` (+ `../design/SKILL.md` for the visual system).
-- Sales/landing copy and launch emails → `../marketing/SKILL.md`. You design the learning contract, never the pitch.
-- Fact-checking or sourcing the subject matter → `../research-ops/SKILL.md`. You structure what the user already knows.
-- A repeatable internal procedure with steps but no outcomes/assessment → `../sop-builder/SKILL.md`. An SOP tells someone the steps; a course changes what they can DO and proves it.
-
 **The litmus.** If the question is *"what must the learner be able to DO, how do we prove it, and in what order do we build it?"* → here. If it's *"how do I make THIS concept click and stick?"* → `../course-storytelling/SKILL.md`.
 
+Route elsewhere when: auditing a *finished* course for gaps, redundancy, anachronisms with a written report → `../review/SKILL.md`; turning a designed module into slides/decks → `../presentations/SKILL.md` (+ `../design/SKILL.md` for the visual system); sales/landing copy and launch emails → `../marketing/SKILL.md` (you design the learning contract, never the pitch); fact-checking or sourcing the subject matter → `../research-ops/SKILL.md` (you structure what the user already knows); a repeatable internal procedure with steps but no outcomes/assessment → `../sop-builder/SKILL.md` (an SOP tells someone the steps; a course changes what they can DO and proves it).
+
 ## The grounding gate (read first — STOP if unmet)
 
 You cannot design a course backward without knowing the destination. Do not write a single outcome until you have all three. Why: an outcome scoped for a senior engineer in a 90-minute workshop is wrong for a beginner in a 12-week cohort — same topic, different contract.
@@ -37,24 +26,9 @@ You cannot design a course backward without knowing the destination. Do not writ
 
 If a `02-DOCS/wiki/teaching/` profile exists (the convention shared with `../course-storytelling/SKILL.md`), read it first and reuse it. Otherwise interview in ONE batch — ask all three at once, do not dribble questions. **Incomplete grounding = STOP and ask.** Depth, the interview script, and scope right-sizing by format → `references/grounding-and-scoping.md`.
 
-## The non-negotiables
-
-Each rule carries its one-line reason. Break one and the skeleton is not defensible.
-
-1. **Design backward: outcomes first, then assessment, then content.** UbD has exactly three stages in order — desired results → acceptable evidence → learning experiences (Wiggins & McTighe, *Understanding by Design*). Content designed first is a dump with no destination.
-2. **Every outcome uses a measurable Bloom verb.** The revised taxonomy (Anderson & Krathwohl, 2001) is six ascending levels of *verbs* — Remember → Understand → Apply → Analyze → Evaluate → Create — each supplying observable action verbs. A verb you can't observe, you can't assess.
-3. **Banlist: never "understand", "know", "learn about", "appreciate", "be aware", "be familiar".** They name a private mental state, not an observable behavior. Replace with what the learner *does*: list, explain, build, debug, evaluate, design.
-4. **Each outcome is ABCD-complete.** Audience + Behavior (verb + object) + Condition (situation/tools) + Degree (success criterion). A bare verb without a condition and a degree is not yet assessable — "write code" vs "given a failing test, write code that makes it pass".
-5. **Every outcome is proven by ≥1 assessment.** No unproven outcomes. An outcome with no evidence is a promise you never keep.
-6. **Every module ties to ≥1 outcome.** No orphan modules. If a module maps to no outcome, it's content the contract never asked for — cut it or write the outcome it serves.
-7. **The verb in the outcome = the verb activated in teaching = the verb verified in assessment** (constructive alignment, Biggs). If the outcome says "design" and the quiz tests "recall", the assessment proves the wrong thing.
-8. **Place BOTH formative and summative assessment.** Formative runs *during* learning (low/no stakes — quizzes, checklists, drafts) to give feedback; summative runs *at the end* (the project, the exam) to certify mastery. A course with only the final exam gives the learner no feedback loop.
-9. **No content-first design.** "I already have these slides, build a course around them" inverts the contract. Outcomes decide what content survives.
-10. **Right-size scope to format.** A 90-minute workshop earns ~1–2 outcomes; a 12-week cohort earns 5–8. Cramming a bootcamp's outcomes into a workshop guarantees none are actually achieved.
-
 ## The build workflow (one backward pass)
 
-Run it in order. Do not jump to modules.
+Run it in order. Do not jump to modules. UbD has exactly three stages in order — desired results → acceptable evidence → learning experiences (Wiggins & McTighe, *Understanding by Design*). Content designed first is a dump with no destination, and "I already have these slides, build a course around them" inverts the contract: outcomes decide what content survives.
 
 ```text
 Stage 0  Grounding gate         WHO + WHAT transformation + FORMAT. Incomplete → STOP.
@@ -70,9 +44,9 @@ Stage 5  QA gate                Run scripts/verify.sh over the curriculum doc. F
                                 or justify them. Then hand modules to course-storytelling.
 ```
 
-## Writing measurable outcomes
+## Stage 1 — Writing measurable outcomes
 
-Pick the verb at the level the learner must actually operate. Recall ≠ build.
+Pick the verb at the level the learner must actually operate. Recall ≠ build. The revised taxonomy (Anderson & Krathwohl, 2001) is six ascending levels of *verbs*, each supplying observable action verbs — a verb you can't observe, you can't assess.
 
 ```text
 Level         What the learner does          Sample verbs
@@ -84,7 +58,9 @@ Evaluate      judge against criteria         evaluate, critique, justify, priori
 Create        produce something new          design, build, compose, construct, ship
 ```
 
-The **ABCD template** for one outcome:
+**Banlist — never "understand", "know", "learn about", "appreciate", "be aware", "be familiar".** They name a private mental state, not an observable behavior. Replace with what the learner *does*: list, explain, build, debug, evaluate, design.
+
+Every outcome is **ABCD-complete** — a bare verb without a condition and a degree is not yet assessable ("write code" vs "given a failing test, write code that makes it pass"):
 
 ```text
 [Audience]   the learner
@@ -111,9 +87,9 @@ Good: Given a 20-line module, the learner writes 3 tests that cover the happy pa
 
 Full per-level verb tables, the banlist, more worked ABCD examples, and course-level vs module-level granularity → `references/outcomes-and-blooms.md`.
 
-## Designing aligned assessment
+## Stage 2 — Designing aligned assessment
 
-Assessment is the proof, not an afterthought. For every outcome, ask: *what would I have to SEE the learner do to believe they achieved it?* — and make that the assessment.
+Assessment is the proof, not an afterthought. For every outcome, ask: *what would I have to SEE the learner do to believe they achieved it?* — and make that the assessment. Place **both** kinds: an outcome with no evidence is a promise you never keep, and a course with only the final exam gives the learner no feedback loop.
 
 ```text
                  Formative (during)              Summative (at the end)
@@ -127,12 +103,12 @@ Bloom fit        Remember/Understand/Apply        Apply/Analyze/Evaluate/Create
 
 Two hard checks:
 
-- **Verb match.** The assessment must require the *same* verb as the outcome. Outcome "build" → assessment is a build, not a multiple-choice quiz. Outcome "evaluate" → assessment asks for a judgement with justification, not recall.
+- **Verb match** (constructive alignment, Biggs). The assessment must require the *same* verb as the outcome. Outcome "build" → assessment is a build, not a multiple-choice quiz. Outcome "evaluate" → assessment asks for a judgement with justification, not recall. If the outcome says "design" and the quiz tests "recall", the assessment proves the wrong thing.
 - **Content validity.** The set of assessments must cover the *breadth* of the outcomes — every outcome touched, none over-weighted into a vanity exam. Competency-based design maps this via the matrix and certifies demonstrated mastery, not seat time.
 
 The full formative↔summative menu mapped to Bloom levels, the content-validity / blueprint checklist, and the verb-match rule worked end-to-end → `references/assessment-design.md`.
 
-## Sequencing modules + the alignment matrix
+## Stages 3–4 — Sequencing modules + the alignment matrix
 
 Order modules by **prerequisite** (you can't build before you can run), give each **one focus**, and map each to ≥1 outcome. Then emit the matrix — this is the artifact `scripts/verify.sh` checks.
 
@@ -144,7 +120,7 @@ Order modules by **prerequisite** (you can't build before you can run), give eac
 | O3 evaluate an API's error model | M5               | F: M5 peer review · S: capstone rubric|
 ```
 
-Read the matrix two ways: down a column finds **orphan modules** (a module in no row → cut or justify); across the outcome list finds **unproven outcomes** (an outcome with an empty assessment cell → design evidence). A complete matrix has no empty cells.
+Read the matrix two ways: down a column finds **orphan modules** (a module in no row → content the contract never asked for, so cut it or write the outcome it serves); across the outcome list finds **unproven outcomes** (an outcome with an empty assessment cell → design evidence). A complete matrix has no empty cells.
 
 ## Decision table (branch only where the flow actually splits)
 
@@ -175,12 +151,8 @@ Attitude/disposition outcome      Assess with reflection + observed behavior; ha
 | Summative-only: just a final exam | No feedback loop during learning | Place formative checkpoints throughout |
 | Scope creep: bootcamp outcomes in a workshop | None are actually achievable in the time | Right-size outcome count to the format |
 
-## Hand-off
-
-The skeleton is the start, not the finish.
+## Stage 5 — QA gate and hand-off
 
-- Skeleton + matrix pass QA → hand **each module** to `../course-storytelling/SKILL.md` to make the teaching land (epiphany, named models, grounded analogies). You built *what* and *in what order*; that skill makes it stick.
-- Need decks → `../presentations/SKILL.md` for slides, `../design/SKILL.md` for the visual system.
-- A repeatable team procedure surfaced that isn't a course → `../sop-builder/SKILL.md`.
+`scripts/verify.sh` checks your curriculum's STRUCTURE and ALIGNMENT (measurable verbs, the matrix, proven outcomes, formative + summative). Fix its warnings or justify them.
 
-The boundary is executable: `scripts/verify.sh` checks your curriculum's STRUCTURE and ALIGNMENT (measurable verbs, the matrix, proven outcomes, formative + summative). It does not judge whether the teaching lands — that is `course-storytelling`'s job, and its verify.sh checks narrative, not structure.
+Then hand **each module** to `../course-storytelling/SKILL.md` to make the teaching land (epiphany, named models, grounded analogies). You built *what* and *in what order*; that skill makes it stick. The boundary is executable: this skill's verify.sh does not judge whether the teaching lands, and `course-storytelling`'s checks narrative, not structure.