@ericrisco/rsc 0.1.44 → 0.1.46

package/skills/competitor-watch/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: competitor-watch
-description: "Use when you keep a named set of rivals under continuous, dated observation — tracking their pricing, features, positioning, and changelog over time, turning page diffs into a maintained tracker plus a classified change log on a cadence. Use when asked what moved at a competitor this month, whether a rival changed price or shipped something, or for a feature matrix kept current rather than written once. Triggers: 'set up competitor monitoring', 'watch their pricing page', 'did [rival] reposition or launch anything', 'what moved at [competitor] this month', 'keep this comparison matrix updated', 'track how their positioning shifted over 6 months', 'monitoritza els competidors i avisa-m quan canviïn de preu', 'vigila los precios de la competencia'. NOT sizing the market or producing the competitor list (that is market-research), NOT setting our own price (that is pricing), NOT building the sales battlecard (that is sales-pipeline)."
+description: "Use when an already-named set of rivals is watched on a cadence — pricing, features, positioning and changelog diffed into a maintained tracker plus an append-only, classified change log. NOT sizing the market or choosing who the rivals are (that is `market-research`), NOT one-off page extraction (that is `data-scraper`)."
 tags: [competitive-intelligence, monitoring, pricing-tracking, feature-tracking, marketing-ops]
 recommends: [market-research, pricing, sales-pipeline, brand-voice, data-scraper, automation-flows, seo-geo]
 origin: risco
@@ -11,33 +11,17 @@ origin: risco
 You run a **standing watch**, not a one-shot study. You take an *already-named* set of
 rivals and keep them under dated observation along four axes — positioning, pricing,
 features, and change-over-time. The deliverable is not a snapshot of the market; it is the
-**time series** of what each rival moved, when, and what you do about it.
-
-Three hard stops up front, so you don't drift into a neighbour's job:
-
-- You do **not** size the market or invent the competitor list — that is `../market-research/SKILL.md`.
-- You do **not** decide *our* price, packaging, or tiers — that is `../pricing/SKILL.md`.
-- You do **not** build the sales battlecard / "why we win" — that is `../sales-pipeline/SKILL.md`.
-
-The near-miss that catches people is `market-research`: it answers *"what is the market and
-who is in it"* once and often **produces the list you watch**. You are the downstream loop
-that watches that list forever. The other near-miss is `../data-scraper/SKILL.md`: it owns
-the generic mechanics of pulling data off a page on demand; you *use* change detection as a
-means, but your identity is the maintained tracker + classified change log + cadence. "Extract
-this one table once" → data-scraper. "Keep watching these five companies" → you.
-
-## The loop is the product
-
-Competitive intelligence is a **repeating cycle**, not a report you write and file. The
-taught cycle runs **Orient → Gather → Analyze → Report → Act**, then loops with a fresh
-orientation informed by the last pass (competitiveintelligencealliance.io, accessed 2026-06-02).
-
-- **The output is a re-run tracker, not a one-time document.** *Why:* a market changes
-  the week after you "finish" the study; a snapshot is stale on arrival.
-- **Every pass appends to a change log, it does not overwrite the last.** *Why:* the value
-  is the delta over time — "Pro tier went \$49→\$59 in May" — not the current cell alone.
-- **Watch the vital few, not everyone.** Pick the 3–7 rivals that move your roadmap. *Why:*
-  watching 30 companies produces noise nobody reads; depth on the few beats breadth on the many.
+**time series** of what each rival moved, when, and what you do about it. Competitive
+intelligence is a **repeating cycle**, not a report you write and file: the taught cycle runs
+**Orient → Gather → Analyze → Report → Act**, then loops with a fresh orientation informed by
+the last pass (competitiveintelligencealliance.io, accessed 2026-06-02).
+
+Two near-misses decide the routing (the rest are in **Handoffs**, below). `../market-research/SKILL.md`
+answers *"what is the market and who is in it"* once, and often **produces the list you watch** —
+you are the downstream loop that watches that list forever. `../data-scraper/SKILL.md` owns the
+generic mechanics of pulling data off a page on demand; you *use* change detection as a means, but
+your identity is the maintained tracker + classified change log + cadence. "Extract this one table
+once" → data-scraper. "Keep watching these five companies" → you.
 
 ## Ethics gate — runs FIRST, before any capture
 
@@ -61,8 +45,9 @@ If a request needs any of those, **refuse and reframe to the legal equivalent**:
 1. **Get the competitor list.** If there is none, or it's unvalidated guesswork → STOP and
    route to `../market-research/SKILL.md`. *Why:* watching the wrong rivals forever is worse
    than not watching. You are not the one who decides who the competitors are.
-2. **Pick the watch-axes** from the canonical surface list (below). Don't watch everything —
-   watch what changes your decisions.
+2. **Pick the vital few, then the watch-axes.** The 3–7 rivals that move your roadmap, and only
+   the surfaces (below) that change your decisions. *Why:* watching 30 companies on every axis
+   produces noise nobody reads; depth on the few beats breadth on the many.
 3. **Persist the tracker of record** under `02-DOCS/wiki/competitors/` (one profile per rival
    + a shared change log); keep raw captures under `02-DOCS/raw/competitors/`. *Why:* the
    tracker is a maintained artifact, not a chat answer — it has to live somewhere re-runnable.
@@ -191,8 +176,8 @@ recommend a SaaS. Full docker-compose + per-axis watch recipe is in `references/
 ## Verify
 
 After you emit a tracker / change log / config, run `scripts/verify.sh` against your project
-docs. It lints (read-only): required tracker columns present; **every pricing/feature row has
-a non-empty `source_url` and `date`** (the anti-invention guard); change-log `axis` and
-`materiality` are in the allowed sets and every row has a `url` + `date`; and it **warns** when
-a monitoring-config entry pairs a slow axis with a sub-15-min cadence or a pricing axis with a
-slower-than-daily cadence. It exits 0 on an empty/clean target — no false failures.
+docs. Read-only lint: required tracker columns present; **every pricing/feature row has a
+non-empty `source_url` and `date`** (the anti-invention guard); change-log `axis` and
+`materiality` in the allowed sets, with a `url` + `date` on every row; and a **warning** when a
+monitoring-config entry pairs a slow axis with a sub-15-min cadence, or pricing with a
+slower-than-daily one. It exits 0 on an empty/clean target — no false failures.

package/skills/compliance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: compliance
-description: "Use when a business needs to know which regulatory frameworks actually bind it and how to keep the program true between audits — scoping SOC 2 / ISO 27001 / HIPAA / PCI DSS / EU AI Act / DORA / NIS2, building a control register with owners and evidence, or standing up a recurring compliance cadence. Triggers: 'what compliance do we need for a fintech', 'build a SOC 2 readiness checklist', 'map our controls — who owns what', 'we have an audit in 90 days, set up the prep rhythm', 'does the EU AI Act apply to us and what's the deadline', 'set up a continuous-compliance calendar so we stop scrambling', '¿qué compliance necesitamos para una app de salud con datos médicos?', 'muntar el checklist de SOC 2'. NOT drafting the privacy policy, ROPA, or DPA text (that is gdpr-privacy), NOT writing Terms of Service (that is terms-conditions), NOT hardening the code itself (that is secure-coding)."
+description: "Use when scoping which regulatory frameworks bind a business — SOC 2, ISO 27001, HIPAA, PCI DSS, EU AI Act, DORA, NIS2 — building a control register with owners and evidence, or standing up the cadence that keeps it audit-ready. NOT drafting privacy-policy/ROPA/DPA or ToS text (that is gdpr-privacy, terms-conditions), NOT hardening code (that is secure-coding)."
 tags: [compliance, soc2, iso27001, audit-readiness, controls, governance]
 recommends: [gdpr-privacy, terms-conditions, data-policy, contracts, secure-coding]
 origin: risco
@@ -8,28 +8,21 @@ origin: risco
 
 # Compliance — scope the frameworks, build the register, run the rhythm
 
-You turn a vague "we need to be compliant" into two artifacts that survive an
-audit:
-
-1. **A sector regulatory checklist** — the specific frameworks that actually
-   bind *this* business, decomposed into named controls, each with an owner and
-   an evidence source.
-2. **A compliance operating rhythm** — the recurring calendar (control reviews,
-   evidence refresh, access recerts, vendor reassessments, audit prep) that
-   keeps the program true between audits instead of scrambling once a year.
+You turn a vague "we need to be compliant" into artifacts that survive an audit:
+a scoped framework list with current deadlines, a **control register** (one row
+per control, tagged to every framework it satisfies, each with an owner and an
+evidence source), a **cadence calendar** of the recurring work that keeps the
+program true between audits instead of scrambling once a year, and an
+evidence-source catalog.
 
 Your job is **scoping and orchestration, not legal opinion**. You map the
 business to the frameworks, build the register, assign owners and cadences, and
 stand up the rhythm. You do not give legal advice; flag where a licensed
 specialist or auditor must sign off.
 
-## What you produce — and what you refuse
-
-**Produce:** a scoped framework list with current deadlines, a control register
-(one row per control, tagged to every framework it satisfies), a cadence
-calendar, and an evidence-source catalog.
-
-**Refuse and route** — these are owned by siblings, not by you:
+**Route out** — these are owned by siblings, not by you. You *reference* the
+resulting documents as evidence sources in the register; you do not write them
+here.
 
 - Privacy notice, ROPA, DSAR flow, consent banner → `../gdpr-privacy/SKILL.md`.
 - Terms of Service, EULA, acceptable-use → `../terms-conditions/SKILL.md`.
@@ -38,9 +31,6 @@ calendar, and an evidence-source catalog.
 - Hardening the code (authn, secrets, injection, headers) →
   `../secure-coding/SKILL.md`.
 
-You *reference* these documents as evidence sources in the register; you do not
-write them here.
-
 ## Step 1 — Scope to the frameworks that actually bind
 
 Do not copy a framework because a competitor has it. Map business attributes to
@@ -159,26 +149,9 @@ before the auditor arrives.
 | Drafting the privacy policy / DPA here | That's legal-document substance, a different skill's lane | Route to `../gdpr-privacy/SKILL.md` / `../contracts/SKILL.md` |
 | Giving a legal opinion | You scope and orchestrate; you are not counsel | Flag where a licensed specialist or auditor must sign off |
 
-## References
-
-- `references/frameworks.md` — per-framework cheat sheets with current dates and
-  control counts: SOC 2 (5 TSC, Type I/II), ISO 27001:2022, EU AI Act phase
-  dates + fines, PCI DSS 4.0.1, HIPAA (+ 2024 NPRM forthcoming), DORA, NIS2,
-  GDPR as a control source.
-- `references/operating-rhythm.md` — control-register schema, the full cadence
-  calendar, the evidence-source catalog, and the audit-prep runbook.
-
 ## Verify
 
 `scripts/verify.sh <register>` lints a control register (Markdown table or CSV):
 it checks the required columns exist and that no row is missing an owner,
 evidence, or cadence — the cardinal sin of checklist theater. Read-only, exits 0
 on a clean or empty register.
-
-## See also
-
-- `../gdpr-privacy/SKILL.md` — privacy notice, ROPA, DSAR, consent.
-- `../terms-conditions/SKILL.md` — ToS, EULA, acceptable-use.
-- `../data-policy/SKILL.md` — internal retention/classification policy text.
-- `../contracts/SKILL.md` — MSA / DPA / NDA drafting and review.
-- `../secure-coding/SKILL.md` — code-level hardening that produces your evidence.

package/skills/compose-multiplatform/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: compose-multiplatform
-description: "Use when building shared UI across Android, iOS, and desktop from one Kotlin codebase with Compose Multiplatform — shared commonMain @Composables, expect/actual for platform divergence, native interop, multiplatform ViewModel/navigation/Koin. Triggers: 'share one Compose UI across Android and iOS', 'my expect has no actual and the build fails', 'where does this code go — commonMain or iosMain', 'embed a SwiftUI/UIKit view inside shared Compose with UIKitView', 'host shared Compose in a SwiftUI app', 'add a desktop target and package it', 'compartir la UI entre Android i iOS amb Kotlin', 'una sola UI para Android, iOS y escritorio'. NOT a single-platform native build (that is kotlin-android / swift-ios), and NOT Dart/Flutter cross-platform UI (that is flutter)."
+description: "Use when building one shared Compose UI in Kotlin across Android, iOS, and desktop — commonMain @Composables, expect/actual, source-set placement, native interop, multiplatform ViewModel/navigation/Koin. NOT a single-platform native build (that is kotlin-android / swift-ios), and NOT Dart/Flutter cross-platform UI (that is flutter)."
 tags: [kotlin, kmp, compose-multiplatform, cross-platform, shared-ui, expect-actual, ios, android]
 recommends: [kotlin-android, swift-ios, flutter, tauri]
 origin: risco

package/skills/constitution/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: constitution
-description: "Use when capturing or revising a project's non-negotiable principles — its stack canon, quality bars, naming/structure conventions, branching/commit rules, testing thresholds, security and accessibility floors, the things every later phase must obey. This is the FIRST rsc-sdd phase, run once per project (then amended). Writes/updates 02-DOCS/wiki/sdd/constitution.md and links it from the root CLAUDE.md Knowledge map; reconciles with conventions the harness already holds under 02-DOCS/wiki/stack/*. Triggers: 'set the project principles', 'define our engineering standards', 'establecer las reglas del proyecto', 'project constitution', 'what are our non-negotiables', 'lock the stack canon', 'quality bar', 'coding standards doc', 'amend the constitution', 'ratify principle', 'definition of done for the repo'. NOT a feature spec (that's specify) and NOT an implementation plan (that's plan)."
+description: "Use when setting or amending a project's non-negotiables — stack canon, quality bars, conventions, security/a11y floors — as numbered, testable rules later phases obey. First rsc-sdd phase; writes 02-DOCS/wiki/sdd/constitution.md. NOT a feature spec (that is `specify`), NOT the technical plan (that is `plan`), NOT the wiki itself (that is `harness`)."
 tags: [sdd, constitution, principles]
 recommends: [specify]
 profiles: [core, full]
@@ -13,7 +13,7 @@ origin: risco
 
 A constitution is small, durable, and enforceable. It is **not** a wiki of everything you know about the project (that is what `02-DOCS/wiki/` already is, run by the `harness`). It is the short list of principles that, if violated, mean the work is wrong regardless of whether it runs. If a rule here cannot be checked or pointed at later, it does not belong here — move it to the stack wiki and link it.
 
-This skill produces `02-DOCS/wiki/sdd/constitution.md` and one Knowledge-map row. The constitution is one of the few **read-first** pointer entries kept directly in the root `CLAUDE.md` `## Knowledge map` (everything else lives in `02-DOCS/wiki/index.md`, the full Knowledge map that root `CLAUDE.md` points to). It reconciles with — never duplicates — the stack conventions the harness keeps under `02-DOCS/wiki/stack/*`.
+Not this phase: *what to build* → `../specify/SKILL.md`; the technical approach for one feature → `../plan/SKILL.md`; setting up `01-TOOLS/` + `02-DOCS/` or capturing general project knowledge → `harness`; concrete stack mechanics (*how* to configure Ruff, pytest, Tailwind tokens) → the relevant stack skill (`../fastapi/SKILL.md`, `../nextjs/SKILL.md`, `../go/SKILL.md`, `../postgresdb/SKILL.md`, `../flutter/SKILL.md`, `../design/SKILL.md`, `../secure-coding/SKILL.md`). The constitution *names* the bar; the stack skill *enforces* it.
 
 ## Model tier — `heavy` (opt-in routing)
 
@@ -21,7 +21,7 @@ This phase's default model tier is **`heavy`** — it sets the project's non-neg
 
 ## Honor the accompaniment dial first
 
-Before asking anything, read `02-DOCS/wiki/harness/user-profile.md` and match its `technical_level` and `accompaniment_level`. The constitution interview adapts:
+Before asking anything, read `02-DOCS/wiki/harness/user-profile.md` and match its `technical_level` and `accompaniment_level`. No profile yet → default to non-technical and ask the two gauging questions, or point the user at `init`; never assume fluency. The constitution interview adapts:
 
 | Level | How this skill behaves |
 |-------|------------------------|
@@ -30,24 +30,6 @@ Before asking anything, read `02-DOCS/wiki/harness/user-profile.md` and match it
 | L2 — explica decisiones | Justify each principle as you propose it; surface trade-offs where a rule constrains the team. |
 | L3 — acompañamiento total | Explain what a constitution is and why each section matters, one kind question at a time, before writing anything. Non-technical framing. |
 
-If there is no profile yet, default to non-technical and ask the two gauging questions (technical level, accompaniment level) before proceeding — or point the user at `init`. Never assume fluency.
-
-## When to use / when NOT to use
-
-Use when:
-
-- A project is being set up and needs its principles fixed before features are specified.
-- The team keeps relitigating the same decisions (test coverage, formatting, branch naming) and wants them ratified once.
-- An existing repo has implicit conventions that should be made explicit and enforceable.
-- A principle needs to change — amend the constitution (see the amendment protocol).
-
-Do NOT use when (route instead):
-
-- The user wants to describe *what to build* → `../specify/SKILL.md` (a feature spec, not project-wide law).
-- The user wants the *technical approach* for a feature → `../plan/SKILL.md`.
-- The user wants to set up `01-TOOLS/` + `02-DOCS/` or capture general project knowledge → `harness` (the constitution lives inside that wiki, but the wiki itself is the harness's job).
-- The user wants concrete stack mechanics (e.g. *how* to configure Ruff, pytest, Tailwind tokens) → the relevant stack skill (`fastapi`, `nextjs`, `go`, `postgresdb`, `flutter`, `design`). The constitution *names* the bar; the stack skill *enforces* it.
-
 ## Reconcile before you write (do not duplicate the stack wiki)
 
 The harness may already hold real conventions under `02-DOCS/wiki/stack/*` (e.g. `nextjs.md`, `fastapi.md`, `postgresdb.md`). The constitution does not copy them — it **ratifies the principle and links the detail**. Run this reconciliation pass first:
@@ -64,7 +46,7 @@ The rule of thumb: the constitution says *"every endpoint is typed and tested to
 Every principle in the constitution is one numbered, testable statement. A vague aspiration is not a principle.
 
 - **Imperative and specific.** "Code is formatted with the repo's formatter on every commit" — not "we value clean code".
-- **Checkable.** There must be a way for `analyze` and `verify` to tell whether it held. Prefer a number, a command, or a named artifact.
+- **Checkable.** There must be a way for `../analyze/SKILL.md` and `verify` to tell whether it held. Prefer a number, a command, or a named artifact.
 - **Owned.** If enforcement lives in a stack skill or a script, link it.
 - **Falsifiable in review.** A reviewer can point at a diff and say "this violates principle 4".
 
@@ -116,10 +98,10 @@ The constitution is versioned so `analyze` and `review` can cite "constitution v
 - **Ratification.** A new or amended constitution is shown to the user and ratified explicitly before it takes effect. At L0, "ratify" is a quick yes; at L3, walk each change.
 - **Downstream notice.** When a principle changes mid-project, flag that existing specs/plans may now be inconsistent — `analyze` will catch the drift on the next run.
 
-## Anti-patterns → STOP
+## Anti-patterns
 
-| Rationalization | Reality / fix |
-|-----------------|---------------|
+| Anti-pattern | Why it fails / fix |
+|--------------|--------------------|
 | "I'll write a thorough constitution covering everything about the project." | That's the wiki, not the constitution. Keep only enforceable non-negotiables; link the rest. |
 | "This stack detail is important, I'll paste the lint config in here." | No. Ratify the principle, link `wiki/stack/*` for the mechanic. The constitution names the bar; the stack skill enforces it. |
 | "Two stack articles disagree — I'll just pick the stricter one." | Contradictions are findings. Surface them; the user resolves. |
@@ -137,7 +119,7 @@ The constitution is versioned so `analyze` and `review` can cite "constitution v
 - [ ] The Definition-of-Done checklist is present (what `verify` runs against).
 - [ ] Fixed principles included: human git authorship + decisions logged.
 - [ ] `02-DOCS/wiki/sdd/constitution.md` written with version + ratified date + amendment log.
-- [ ] Root `CLAUDE.md` `## Knowledge map` pointer has the read-first row for the constitution (it is one of the few entries kept in root `CLAUDE.md`; the full index lives in `02-DOCS/wiki/index.md`). Additive only — never delete sections.
+- [ ] Root `CLAUDE.md` `## Knowledge map` pointer has the read-first row for the constitution.
 - [ ] The constitution was shown to the user and explicitly ratified.
 
 ## Project grounding (02-DOCS + CLAUDE.md)
@@ -153,12 +135,3 @@ Every later rsc-sdd phase reads this file before it works. The harness maintains
 ## Next in the chain
 
 The constitution is the guardrail; now describe what to build. Hand off to **`../specify/SKILL.md`** — turn a fuzzy intent into a spec (what & why, no implementation), grounded in these principles. The full chain: **constitution → specify → clarify → plan → tasks → analyze → implement → verify → review → ship** (with `debug`, `worktrees`, `parallel` callable on demand). The dispatcher is `../sdd/SKILL.md`.
-
-## See Also
-
-- `../sdd/SKILL.md` — the rsc-sdd dispatcher: the method, the phase map, the invoke rule.
-- `../specify/SKILL.md` — the next phase: intent → spec.
-- `../analyze/SKILL.md` — the consistency gate that checks specs/plans against this constitution.
-- `harness` — owns `02-DOCS/wiki/` (including `wiki/stack/*` and the full Knowledge map at `02-DOCS/wiki/index.md` this skill reconciles with; the constitution's read-first row stays in the root `CLAUDE.md` pointer).
-- Stack skills the constitution *names but does not duplicate*: `../fastapi/SKILL.md`, `../nextjs/SKILL.md`, `../go/SKILL.md`, `../postgresdb/SKILL.md`, `../flutter/SKILL.md`, `../design/SKILL.md`, `../secure-coding/SKILL.md`.
-- References: `references/constitution-template.md`.

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