@ericrisco/rsc 0.1.44 → 0.1.45

package/skills/code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-review
-description: "Use when you have a concrete diff, branch, or GitHub PR to judge on its own merits and there is no rsc-SDD spec/plan/constitution chain to key off — the standalone, spec-less giving pass behind the executable /code-review. Triggers: 'review this PR before I merge', 'revisa este diff', 'revísame el PR', 'què està malament en aquest canvi', 'tear apart the contractor's branch', 'is this PR safe to merge', 'is this dependency bump safe', '/code-review --comment 1432', 'high-signal review of this change'. Scales coverage by effort (low/medium = fewer high-confidence findings; high/max = broader, may surface uncertain ones labelled [question]); read-only by default, posts comments only with --comment and edits only with --fix. NOT the SDD review gate keyed to 02-DOCS/wiki/sdd/ that also processes incoming comments and pushes back (that is review)."
+description: "Use to judge a concrete diff, branch, or GitHub PR on its own merits with no rsc-SDD spec/plan chain to key off — the spec-less giving pass behind /code-review: only findings you can defend, one verdict, read-only unless --comment or --fix. NOT the SDD gate keyed to 02-DOCS/wiki/sdd/ that also processes incoming review comments (that is `review`)."
 tags: [code-review, pr-review, quality, correctness]
 recommends: [review, secure-coding, verify]
 origin: risco
@@ -8,9 +8,7 @@ origin: risco
 
 # Code review — standalone, spec-less diff judgment
 
-You are reviewing a concrete change — a `git diff`, a branch, a GitHub PR, a pasted patch — on its own merits. No rsc-SDD spec/plan/constitution chain is required and you should not pretend one exists. This is the doctrine behind the executable `/code-review` slash command: same evidence bar, written as a discipline you run by hand.
-
-> **The one-line disambiguator:** `review` needs `02-DOCS/wiki/sdd/` (spec + plan + constitution) and owns the *receiving* loop. `code-review` needs only the diff. If the user is mid-SDD and wants to process incoming comments, route to `../review/SKILL.md`. If they hand you a naked diff or an inbound third-party PR, this skill.
+You are reviewing a concrete change — a `git diff`, a branch, a GitHub PR, a pasted patch — on its own merits. No rsc-SDD spec/plan/constitution chain is required and you should not pretend one exists. This is the doctrine behind the executable `/code-review` slash command: same evidence bar, written as a discipline you run by hand. If the user is mid-SDD and wants to process *incoming* comments against `02-DOCS/wiki/sdd/`, that is `../review/SKILL.md`; a naked diff or an inbound third-party PR is this skill.
 
 **The north star is signal-to-noise.** Report only findings you would stake your name on. A clean diff is `APPROVE`, not a manufactured nit. High-false-positive review gets tuned out by humans in about two weeks; the bar to aim for is the logic-error review where under 1% of findings come back marked wrong. Padding does not make you look thorough — it trains the reader to ignore you.
 
@@ -30,7 +28,7 @@ git diff --stat main...HEAD   # see blast radius before reading
 # A pasted patch — read it as given
 ```
 
-A review with no notion of intent is a review of vibes. If no purpose is stated, **infer it from the diff and say what you assumed** ("Assuming this is meant to add idempotency to the webhook handler…") so the reader can correct a wrong premise. Then read the *whole* changed file, not just the green/red lines — the structural failure of standalone review is judging a hunk without its context and shipping generic pattern-matched suggestions.
+A review with no notion of intent is a review of vibes. If no purpose is stated, **infer it from the diff and say what you assumed** ("Assuming this is meant to add idempotency to the webhook handler…") so the reader can correct a wrong premise — a silent wrong premise produces a confidently wrong review. Then read the *whole* changed file, not just the green/red lines: the structural failure of standalone review is judging a hunk without its context and shipping generic pattern-matched suggestions.
 
 ## The pass order
 
@@ -47,6 +45,8 @@ Run these in order. Passes 1–5 are correctness/safety and are blocking-eligibl
 
 Pass 4 is a **boundary** pass — trace untrusted input to its sink and flag the reachable ones. For a real STRIDE/OWASP threat model with exploitability ranking and vulnerable→fixed diffs, hand off to `../secure-coding/SKILL.md`.
 
+Adjacent jobs, delegated by name: running the lint/type/test gates until they are green is `../verify/SKILL.md` (this skill judges whether green is *correct*); root-causing one confirmed failure is `../debug/SKILL.md`; cross-checking spec/plan/tasks *before* code exists is `../analyze/SKILL.md`.
+
 ## Confidence floor and the false-positive skip-list
 
 **The 80% rule:** if you are not at least ~80% sure a finding is real, you have two moves — trace the code until you *are* sure, or downgrade it to `[question]`. Never ship a guess dressed as a defect.
@@ -103,7 +103,7 @@ End every review with exactly one, plainly — no mushy middle:
 
 ## Effort dial
 
-Mirror the slash command's effort level: **low/medium** → fewer, high-confidence findings (raise the confidence floor, focus on passes 1–4). **high/max** → broader coverage; you may surface uncertain findings, but they must be labelled `[question]`, never inflated into blockers. This is *coverage vs precision* and is distinct from the harness L0..L3 accompaniment dial, which sets how much you narrate, not how rigorous you are.
+Mirror the slash command's effort level: **low/medium** → fewer, high-confidence findings (raise the confidence floor, focus on passes 1–4). **high/max** → broader coverage; uncertain findings are allowed but must be labelled `[question]`, never inflated into blockers. This is *coverage vs precision*, not the harness accompaniment dial — it changes what you look at, not how much you narrate.
 
 ## Emitting comments and applying fixes
 
@@ -120,24 +120,11 @@ gh pr review 1432 --approve -b "APPROVE — correctness and contracts clean."
 
 Inline line-anchored comments go through the GitHub REST API — see `references/pr-workflow.md` for the JSON shape, fork-PR handling, and large-diff strategy. If `--fix` puts you on the default branch, **branch first**; commit or push **only when the user asks**; git authorship is **Eric** (no Claude co-author or generated footer).
 
-## Anti-patterns → STOP
+## Anti-patterns
 
-| Rationalization | Reality |
+| Failure mode | Reality |
 |---|---|
 | "It compiles and the tests pass, so it's correct." | Tests prove green, not correct. Pass 5 asks whether the tests actually exercise the new branch — green for the wrong reason is a finding. |
-| "I'll list everything I'd have done differently." | That is noise. Report defects and reuse wins you can defend; preference is not a finding. |
-| "This looks like a bug." | Looks-like is not a finding. Trace the value to a reachable sink, or file it `[question]`. |
-| "More findings = more thorough." | False positives get you tuned out in two weeks. Signal-to-noise is the metric; one real blocker beats ten nits. |
-| "No PR description, so I'll guess the intent silently." | State the intent you assumed. A wrong silent premise produces a confidently wrong review. |
+| Listing everything you would have done differently. | That is noise. Report defects and reuse wins you can defend; preference is not a finding. |
 | "It's just a dependency bump, skim it." | Bumps carry supply-chain and transitive risk and behaviour changes. Check the changelog/lockfile diff, not just the version string. |
-| "Apply every nit to be safe." | Each unrequested edit is scope creep and a regression surface. With `--fix`, apply the agreed findings only. |
-
-## See Also
-
-- `../review/SKILL.md` — the rsc-SDD penultimate gate keyed to `02-DOCS/wiki/sdd/`, and the *receiving* loop (process comments, push back with proof).
-- `../secure-coding/SKILL.md` — deep STRIDE/OWASP threat model with vulnerable→fixed diffs; the depth pass 4 defers to.
-- `../verify/SKILL.md` — run lint/type/test/`verify.sh` and prove green (code-review judges whether green is correct).
-- `../debug/SKILL.md` — root-cause one confirmed failure (code-review surveys for latent ones).
-- `../analyze/SKILL.md` — consistency across spec/plan/tasks *before* code exists.
-- `../ship/SKILL.md` — PR/merge/close after approval; consumes this skill's verdict.
-- Stack idiom for the change under review: `../nextjs/SKILL.md`, `../fastapi/SKILL.md`, `../go/SKILL.md`, `../typescript/SKILL.md`, `../python/SKILL.md`.
+| Applying every nit "to be safe" under `--fix`. | Each unrequested edit is scope creep and a regression surface. Apply the agreed findings only. |

package/skills/codebase-onboarding/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: codebase-onboarding
-description: "Use when you land in an unfamiliar or inherited codebase and must get productive fast — map the entry points, the request/data flow, who owns the business logic, the hidden side effects (cron, webhooks, workers, listeners) and the hotspot files, before you touch anything. Triggers: 'I just cloned this repo and don't know where anything is', 'I inherited this project, map it before I change something', 'where does the business logic actually live', 'what happens behind the scenes when a request hits /checkout', 'which files are the dangerous ones nobody understands', 'acabo de heredar este repo y no sé por dónde empezar, mápamelo', 'mapea este codebase'. NOT a deep correctness/security audit of one module (that is analyze)."
+description: "Use when you land in an unfamiliar or inherited codebase and must get productive fast: a breadth-first map of entry points, request flow, module ownership, hidden side effects (cron, webhooks, workers) and churn hotspots, committed as CODEBASE-MAP.md. NOT a deep audit of one module (that is `analyze`) or chasing one failure (that is `debug`)."
 tags: [onboarding, codebase, code-mapping, legacy-code, architecture, reverse-engineering, hotspots]
 recommends: [analyze, debug, decision-records, harness, init, knowledge-ops]
 origin: risco
@@ -68,7 +68,7 @@ git log --format=format: --name-only --since=12.month \
   | grep -v '^$' | sort | uniq -c | sort -nr | head -50
 ```
 
-The richer move is **churn × complexity**: the top-right quadrant (changes constantly *and* is hard to read) is your real danger zone (understandlegacycode.com Hotspots, accessed 2026-06-02). Escalate to that — or to a tree-sitter dependency graph — only when grep + churn is not enough; see the playbook.
+The richer move is **churn × complexity**: the top-right quadrant (changes constantly *and* is hard to read) is your real danger zone (understandlegacycode.com Hotspots, accessed 2026-06-02). Escalate to that — or to a tree-sitter dependency graph — only when grep + churn is not enough: `references/recon-playbook.md` has the churn×complexity recipe (code-maat) and when codegraph PageRank / FileScopeMCP earn their setup cost.
 
 **g. Confirm hands-on.**
 Run the app, walk one end-user journey, send a real request, watch the logs. Reading alone leaves the map unverified; a single real request validates the whole trace in step c.
@@ -106,9 +106,6 @@ rg -n "queue|worker|bull|sidekiq|celery|sqs|rabbitmq|kafka|@task" -i
 
 # Env-driven branches (hidden config-conditional behavior)
 rg -n "process\.env\.|os\.environ|ENV\[|getenv" 
-
-# Hotspots: churn over the last year
-git log --format=format: --name-only --since=12.month | grep -v '^$' | sort | uniq -c | sort -nr | head -50
 ```
 
 ## Writing & maintaining the map
@@ -129,5 +126,3 @@ git log --format=format: --name-only --since=12.month | grep -v '^$' | sort | un
 | Map lives only in chat | Dies with the session; next agent redoes it | Write & commit `CODEBASE-MAP.md` |
 | Guess instead of grep | Confident-wrong is worse than slow-right | Form the hypothesis, then `rg` to confirm or kill it |
 | Stand up a tree-sitter MCP graph on a 5-file repo | Setup costs more than the whole recon | Reserve graph tools for large monorepos; grep + churn first |
-
-See `references/recon-playbook.md` for per-ecosystem entry points and side-effect patterns, the churn×complexity recipe (code-maat), and when a tree-sitter graph (codegraph PageRank, FileScopeMCP) earns its setup cost.

package/skills/cold-outreach/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cold-outreach
-description: "Use when writing a cold email or DM to someone with no prior relationship, building a follow-up sequence, deciding how fast/how much to send per inbox so it stays out of spam, or rescuing outreach that reads like a template. Covers first-touch copy under a word ceiling, 4-7 step bump sequences, email-vs-LinkedIn variants, per-inbox volume and new-domain warm-up ramps, and the CAN-SPAM/GDPR opt-out footer. Triggers: 'write me a cold email', 'fix my follow-up sequence', 'my cold emails get opened but nobody replies', 'how many emails per inbox per day before I get blacklisted', 'write a LinkedIn connection note + DM', 'this email reads like a template', 'escríbeme una secuencia de cold email en frío', 'missatge en fred a LinkedIn'. NOT the SPF/DKIM/DMARC/tracking-domain setup (that is email-deliverability), NOT sourcing the prospect list (that is lead-gen), NOT what happens after a reply (that is sales-pipeline)."
+description: "Use when writing a cold email or LinkedIn DM to a stranger and its cadence: first-touch copy under a word ceiling, 4-7 step bump sequences, per-inbox volume and warm-up limits, the compliant opt-out footer. NOT SPF/DKIM/DMARC setup (that is email-deliverability), NOT sourcing the list (that is lead-gen), NOT life after a reply (that is sales-pipeline)."
 tags: [cold-email, outreach, sequences, deliverability, sales]
 recommends: [lead-gen, sales-pipeline, email-deliverability, proposals, marketing]
 origin: risco
@@ -10,20 +10,7 @@ origin: risco
 
 *You write the message a stranger actually replies to, and the sending rhythm that keeps the mailbox provider delivering it. You do not set up DNS, source the list, or run the CRM.*
 
-This skill owns two things and only two: the **copy** of an unsolicited 1:1 touch (cold email, LinkedIn note/DM) and the **cadence** around it (step count, spacing, per-inbox volume, warm-up ramp, the compliant footer). Everything upstream and downstream belongs to a sibling — see the route table below and honor it.
-
-## When to use / When NOT
-
-Use when:
-
-- Writing a cold email or its subject line to a recipient with no prior relationship.
-- Building or fixing a multi-step follow-up sequence (the "bump" cadence) — step count and spacing.
-- Writing a LinkedIn connection note or cold DM sequence.
-- Deciding daily/weekly send volume per inbox, or a new-domain warm-up ramp.
-- Writing the CAN-SPAM/GDPR-compliant footer and one-click opt-out line.
-- Rescuing a cold email that "reads like a template" or gets opens but no replies.
-
-Do NOT use when (route to the sibling that owns it):
+This skill owns two things and only two: the **copy** of an unsolicited 1:1 touch (cold email, LinkedIn note/DM) and the **cadence** around it (step count, spacing, per-inbox volume, warm-up ramp, the compliant footer). Everything upstream and downstream belongs to a sibling — route by naming the owner, do not improvise their job:
 
 | The ask | Owner | Why it is not here |
 |---|---|---|
@@ -34,8 +21,6 @@ Do NOT use when (route to the sibling that owns it):
 | Inbound launch emails, nurture to an opted-in list, marketing-site copy | `marketing` (`../marketing/SKILL.md`) | Opted-in and broadcast copy is a different game from a 1:1 cold touch. |
 | Actually wire the send through Gmail/an ESP API or a scheduler | `email-connector` / `google-workspace` | This skill produces text + a plan; it does not push the send. |
 
-Only `marketing` exists in this catalog today, so it is the only sibling linked as a file. The rest are named by id — route by naming the owner, do not improvise their job.
-
 ## The reply-rate reality (calibrate before you write)
 
 Cold email is a low-yield channel by nature, and most "improve my copy" requests are really "stop fighting the math." Set expectations against the 2026 band:
@@ -110,7 +95,9 @@ The Good version names a real signal (`{{signal}}`), states one concrete outcome
 
 The first-touch body is literally lines 2→3→4 in order; line 1 becomes the subject. If the INFER line is generic, the email is generic no matter how many merge fields you add. **Test the INFER line in isolation: would it be false for a competitor in the same situation? If it is true of everyone, it is a platitude — go back to the OBSERVE step and pick a sharper fact.**
 
-When the user hands you only a company name and no signal, do not invent one. Ask for (or, if you have web access, look up) one of these signal classes, ranked by reply lift: a **hiring/role-change** signal > a **funding/launch/news** signal > a **tech-stack or job-description detail** > a **public number from their own site/report** > a **shared context** (mutual, group, event). A generic industry trend ("AI is changing your space") is not a signal and never clears the INFER test. Worked OBSERVE→INFER→BRIDGE→PROVE chains across six industries live in `references/hook-derivation.md`.
+Two boundaries on the OBSERVE line, because both are unrecoverable once sent: keep it **professional, public and business-relevant** ("saw you're hiring 3 SREs" is relevant; "saw you were at the lake house last weekend" is surveillance), and **never invent it** — a fabricated "I loved your recent post on X" that does not exist destroys trust on contact.
+
+When the user hands you only a company name and no signal, do not invent one. Ask for (or, if you have web access, look up) one of these signal classes, ranked by reply lift: a **hiring/role-change** signal > a **funding/launch/news** signal > a **tech-stack or job-description detail** > a **public number from their own site/report** > a **shared context** (mutual, group, event). A generic industry trend ("AI is changing your space") is not a signal and never clears the INFER test. If no true signal exists at all, that is a `lead-gen` targeting gap, not a copy task. Worked OBSERVE→INFER→BRIDGE→PROVE chains across six industries live in `references/hook-derivation.md`.
 
 ## The sequence — decision table
 
@@ -144,7 +131,9 @@ Rules that make the table work:
 
 *(LinkedIn figures: Skylead / Kondo / Expandi 2025-2026 guides, accessed 2026-06-02.)*
 
-On LinkedIn the connection note must **not** pitch — earn the connection on a real signal, then make the ask in the first DM after they accept. Skeletons for both channels live in `references/templates.md`.
+On LinkedIn the connection note must **not** pitch — earn the connection on a real signal, then make the ask in the first DM after they accept.
+
+Reusable skeletons for both channels — first-touch + 4-step bump, with every variable slot (`{{signal}}`, `{{outcome}}`, `{{proof}}`) marked — live in `references/templates.md`. Start from a skeleton, then fill every slot with a *real* value before sending. An unfilled slot is a defect, not a placeholder to ship.
 
 ## Sending cadence & deliverability guardrails
 
@@ -179,12 +168,6 @@ If the user asks you to *configure* the `List-Unsubscribe` header, SPF, or DKIM,
 
 EU enforcement varies — UK ICO and France CNIL are permissive for B2B; Germany and Poland are stricter (Poland often requires prior consent). When the recipient is in the EU, write the footer for the strictest plausible jurisdiction. The full footer wording, the LIA checklist, and the CASL/Australia matrix → `references/compliance-footer.md`.
 
-## Personalization without creepiness
-
-- **One real signal, surfaced plainly.** "Saw you're hiring 3 SREs" is relevant; "Saw you were at the lake house last weekend" is surveillance. Stay on professional, public, business-relevant signals. Then run it through the four-line bridge above — a relevant signal with a generic INFER line still reads like a template.
-- **Do not fake personalization with spintax.** Rotating "{Hi|Hey|Hello}" or `{{first_name}}`-only mail-merge is not personalization — it is a template wearing a name tag, and recipients can smell it. If the only variable is the name, the email is generic; add a real `{{signal}}` or do not send.
-- **Never invent the signal.** A fabricated "I loved your recent post on X" that does not exist destroys trust on contact. If you cannot find a true signal, that is a `lead-gen` targeting gap, not a copy task.
-
 ## Anti-patterns
 
 | Anti-pattern | Why it fails | Do instead |
@@ -193,14 +176,10 @@ EU enforcement varies — UK ICO and France CNIL are permissive for B2B; Germany
 | Pitch in sentence one | No earned relevance; reads like a billboard | Lead with the observed signal, earn the ask |
 | Two CTAs ("call OR I'll send a guide") | Splits the decision; lowers reply rate | One binary yes/no ask per email |
 | "Just following up" / "circling back" with no new angle | Adds noise, not value; trains them to ignore you | Each step adds one new angle or it is deleted |
-| Name-only mail merge as "personalization" | Recipients see the template underneath | One true `{{signal}}` per first touch or do not send |
+| Name-only mail merge or spintax (`{Hi\|Hey}`) as "personalization" | Recipients see the template underneath | One true `{{signal}}` per first touch or do not send |
 | No opt-out / no postal address | CAN-SPAM/GDPR violation; complaint-rate spike | Always append the compliant footer |
 | Subject like "Quick question!!" or "FREE" | Clickbait + spam-trigger words land you in spam | ≤6 plain words that read like a coworker wrote them |
 | Padding to 7 steps for completeness | Replies past step 5 are thin; you just annoy | Stop at the breakup unless a real new trigger appears |
 | "I hope this email finds you well" opener | The classic AI/template tell; wastes the first line | Open on the signal — your first 6 words are the hook |
 
-## Templates
-
-Reusable skeletons — first-touch + 4-step bump for email and LinkedIn, with every variable slot (`{{signal}}`, `{{outcome}}`, `{{proof}}`) marked — live in `references/templates.md`. Start from a skeleton, then fill every slot with a *real* value before sending. An unfilled slot is a defect, not a placeholder to ship.
-
 To self-check a drafted email or sequence file, run `scripts/verify.sh path/to/draft.md` — it flags missing opt-out, multiple CTAs, over-ceiling word count, and spam/AI-tell phrases (read-only).

package/skills/community/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: community
-description: "Use when building or running a persistent two-way community space — Discord, Telegram, or Circle — and you need structure, onboarding, moderation, rituals, growth, or health metrics; covers picking the platform, standing up channels/roles/spaces, the rules/verification gate, the 3-layer moderation stack, an operating-rhythm of rituals, lurker-to-contributor growth loops, and the few metrics that prove it is alive. Triggers: 'set up our Discord server', 'our community is a graveyard / dead chat', 'we keep getting spam raids and scam DMs', 'Discord vs Telegram vs Circle', 'design community rituals / weekly cadence', 'how do I get lurkers to post', 'community onboarding flow', 'community health metrics', 'monta la comunitat de Discord', 'la comunidad está muerta, nadie escribe'. NOT customer churn-prevention for a paid product (that is retention), NOT one-to-many broadcast email (that is newsletter), and NOT running a single live event (that is webinar)."
+description: "Use when building or running a persistent two-way community space — Discord, Telegram, Circle: platform choice, structure, onboarding, native→bot→human moderation, rituals, growth loops, health metrics. NOT churn of paying product customers (that is `retention`), NOT broadcast email (that is `newsletter`), NOT one live event (that is `webinar`)."
 tags: [community, discord, telegram, moderation, growth, rituals]
 recommends: [retention, newsletter, social-publisher, brand-voice, whatsapp-telegram, webinar]
 profiles: []
@@ -11,15 +11,6 @@ origin: risco
 
 Run the community like a **product with a job**, not a vanity chat room. The space — a Discord server, a Telegram group+channel, a Circle — is the product. **Onboarding is activation, rituals are the feature, moderation is reliability, and one north-star metric tied to your purpose is the only number that matters.** A room with 5,000 silent members is a failed product, not a big one. Design the system around the conversation, not the conversation itself.
 
-## When to use
-
-- Standing up a new Discord / Telegram / Circle from zero: structure, roles, onboarding, rules.
-- A community exists but is a graveyard — lurkers only, no rhythm, nobody posts — needs rituals + re-activation.
-- Moderation is on fire: spam waves, raids, scam DMs, bans applied by mood, no incident process.
-- Choosing between Discord vs Telegram vs Circle for a given audience, purpose, and monetization model.
-- Designing a growth loop that compounds (referrals, intro rituals, partner cross-posts) instead of buying dead members.
-- Defining community health metrics and targets and instrumenting the few that prove the thing is alive.
-
 ## When NOT to use — route instead
 
 | The ask | Route to |
@@ -32,9 +23,9 @@ Run the community like a **product with a job**, not a vanity chat room. The spa
 | Actually code or host the Discord/Telegram bot (gateway, slash handlers) | `whatsapp-telegram`, `automation-flows` |
 | Define the voice/name/tone the community speaks in | `../brand-voice/SKILL.md` |
 
-You own the **persistent, two-way space and its ongoing operating rhythm.** The boundary that bites most: `retention` keeps *buyers of a product* from churning; you keep *members of a shared space* active and contributing. They rhyme (cohorts, re-activation) but the subject differs — a SaaS seat vs a Discord membership. When a near-miss is really "send a broadcast," it is `newsletter`/`social-publisher`; when it is "stop churn of buyers," it is `retention`; when it is "run an event," it is `webinar`.
+You own the **persistent, two-way space and its ongoing operating rhythm.** The boundary that bites most: `retention` keeps *buyers of a product* from churning; you keep *members of a shared space* active and contributing. They rhyme (cohorts, re-activation) but the subject differs — a SaaS seat vs a Discord membership.
 
-## Step 0 — Purpose & north-star gate (hard rule)
+## Step 0 — Purpose & north-star gate
 
 **Do not design a single channel until you have (a) a one-line purpose and (b) one business metric tied to it.** Why: a community without a job becomes a dead chat — there is no signal to design toward, so you sprawl channels and beg for activity. This is the most common cause of graveyards.
 
@@ -191,7 +182,7 @@ Then validate it:
 scripts/verify.sh path/to/moderation-config.yaml
 ```
 
-`verify.sh` checks the required keys exist, that `north_star_metric` is non-empty, that all three moderation layers are declared, and that at least one ritual has a cadence — it catches the most common defect (a "plan" with no purpose, no mod layers, or no rhythm).
+`verify.sh` checks the required keys exist, that `north_star_metric` is non-empty, that all three moderation layers are declared, and that at least one ritual has a cadence — it catches the most common defect (a "plan" with no purpose, no mod layers, or no rhythm). **Do not go live until it passes and the north-star plus at least one health metric (TTFR or DAU/MAU) are instrumented.**
 
 ## Anti-patterns
 
@@ -205,21 +196,3 @@ scripts/verify.sh path/to/moderation-config.yaml
 | Treating 90% lurkers as permanent | Leaves activation on the table | 90-9-1 is a range; move lurkers up a tier |
 | Monetizing on Circle before activation works | Charging for a dead room churns instantly | Prove rhythm + retention, then gate/monetize |
 | Broadcasting in a two-way space | Wrong tool; kills conversation | One-to-many → `../newsletter/SKILL.md` / `../social-publisher/SKILL.md` |
-
-## Launch-readiness checklist
-
-Gate before "go live":
-
-- [ ] Purpose written in one line **and** one north-star business metric chosen (Step 0).
-- [ ] Platform chosen by decision rule, not vibes.
-- [ ] ≤ ~6 channels/spaces, each justified by the purpose.
-- [ ] Onboarding path wired: role-on-join → rules gate → prompted intro → where-to-ask.
-- [ ] All 3 moderation layers configured (native + bot + human) sized to expected scale.
-- [ ] ≥ 1 ritual scheduled with an explicit cadence.
-- [ ] North-star + ≥ 1 health metric (TTFR or DAU/MAU) instrumented.
-- [ ] `community-plan.md` + `moderation-config.yaml` emitted and `verify.sh` passes.
-
-## References
-
-- `references/platform-playbooks.md` — per-platform setup depth: Discord (AutoMod filters, verification levels, Rules/Membership Screening, Onboarding, bots by size), Telegram (group+channel hybrid, native anti-spam >200, slow-mode, CAPTCHA bots), Circle (Spaces, 2026 plan ladder + fees, monetization gating).
-- `references/metrics-and-rituals.md` — metric definitions + benchmarks (DAU/WAU/MAU stickiness, cohort retention, TTFR, answered rate, returning-member ratio, the business-metric menu), the 90-9-1 reality, and a ritual template library + sample weekly calendar.

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