create-religion 0.1.0

package/template/.claude/skills/complete/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: complete
+summary: run the final gate, archive the work, commit it, and close it out
+description: "Close out a finished feature, fix, or rollback. Runs the full Verify command and the final safety pass, applies the configured quality gates, archives the spec under religion/history/, ticks the build plan, prunes resolved findings into the archive, resets the active spec, and makes the work commit. Under branch-per-item it squash-merges only with explicit approval, then asks separately before pushing. Ends with a manual walkthrough of what landed. Use when the user runs /complete, or asks to finish, wrap up, close out, or merge the current work item once it is built and reviewed."
+---
+
+# complete - close out the finished work
+
+Where this sits:
+
+    implement  ->  [complete]  ->  next item
+    (built it)     (gate, archive, commit, merge)
+
+The work is built and reviewed. This skill decides whether it is actually done, records it
+in the project's history, and lands it.
+
+## Before you start
+
+**Read `religion/config.json`.** A missing file means defaults; an unparseable one stops
+here and points at /doctor.
+
+**Confirm there is something to complete.** `religion/context/current-work.md` holds a
+real spec, not the stub. Uncommitted step work is expected under `git.checkpoints: none`,
+so do not require the steps to be pre-committed.
+
+## Step 0 - the final safety pass
+
+Report blockers only. Stop before Step 1 if any of these fail.
+
+- **The full `Verify` command passed in this session.** Implementation verified each step
+  against what it touched; this is where the whole suite runs. If the entry file declares
+  no `Verify` command, run the build, plus the test command when one is declared and the
+  work touched logic. A check that cannot run is a blocker, not a pass.
+- **Every build step is ticked.** An unticked step is work the spec asked for that nobody
+  confirmed landed. To finish without it, remove it from the spec first and say why.
+- **No P0 or P1 finding is `open` or `fixed`** in `religion/context/findings.md`. `fixed`
+  blocks on purpose: the repair exists but no review has looked at it. Run /audit
+  to move it to `closed`. The only other ways past are `accepted`, which only the user may
+  set and which records their reason, and `invalid`, which needs review evidence. A
+  missing ledger means no findings.
+- **With `verification.logicTests: "required"`**, logic changes have a configured runner
+  and passing focused tests.
+- **With `verification.uiEvidence: "required"`**, interface outcomes have direct browser
+  evidence, not build output alone.
+
+Then **report, without blocking**, anything in the working tree that is not tied to this
+spec. A dirty findings ledger is expected. Anything else is about to be committed, so name
+the files and let the user decide before continuing.
+
+Never claim passed, verified, or working without naming the command, route, screenshot, or
+output that proves it.
+
+## Step 1 - apply the configured gates
+
+Read `qualityGates`. Reuse evidence already produced during this work item rather than
+repeating it.
+
+- **`audit`**: `manual` runs only on request. `when-sensitive` runs for authentication,
+  authorization, payments, secrets, personal data, migrations, destructive operations,
+  external side effects, security boundaries, or unusually broad changes. `always` runs
+  every time.
+- **`check`**: `manual` runs only on request. `when-behavioral` runs when an outcome needs
+  observed runtime behavior: a click, a request, a download, a background job, a flow
+  across screens. `always` runs every time.
+
+Run `check` first, then `audit`. A required gate that cannot run is a blocker. If an audit
+raises a new P0 or P1, completion stops and the repair goes back to /implement.
+
+Set the spec's status to `verified` once this passes, then archive it.
+
+## Step 2 - record the work
+
+Read the spec's type.
+
+- **Feature** - archive to `religion/history/features/NN-name.md`, where `NN` is the
+  build-plan number, and tick that item in the build plan, plus its parent once every
+  sub-item is ticked.
+- **Fix** - archive to `religion/history/fixes/name.md`. A fix is not a plan item, so
+  there is nothing to tick.
+- **Rollback** - archive to `religion/history/rollbacks/YYYY-MM-DD-NN-name.md`, leaving
+  the original feature archive intact. Untick the target item, and append a short note to
+  that line with the date and the rollback's archive path. Keep the number stable.
+
+The number lives in the path. It never appears in the commit message.
+
+**Record what landed.** After the work commit exists in Step 3, append a `## Landed`
+section to the archive with the exact commits this item produced, oldest first, and the
+commit that preceded them:
+
+    ## Landed
+
+    **Base:** <40-character sha of the commit before this item>
+    **Commits:** <40-character sha>, <40-character sha>
+    **Product paths:** src/export.ts, src/routes/export.ts
+
+Full identifiers only, never abbreviated. This is what makes a later reversal possible:
+without it, reconstructing which commits belong to an item means guessing from messages and
+dates, and guessing wrong reverses somebody else's work. Under `git.mode: trunk` the item's
+commits sit among others on the same branch, so this record is the only reliable boundary.
+
+**Prune the ledger.** Append every `closed`, `accepted`, and `invalid` entry to a
+`## Findings` section in the archive just written, at its final status, with the reason
+preserved for accepted entries. Prefix each identifier with the archive name so it is
+globally unique: item 12's `F-03` becomes `12/F-03`, and that prefixed form is the
+permanent reference.
+
+Then remove only those entries from the ledger. `open`, `fixed`, and `unverified` entries
+stay, with their identifiers, so nothing is silently dropped. A `fixed` P2 does not block
+completion but must survive verbatim for a later review. Reset the ledger to its stub only
+when nothing unresolved remains.
+
+**Reset the active spec** to its stub, exactly as shipped.
+
+**Discard consumed prototypes.** If this work built its look from throwaway static mockups
+and an early step ported their tokens into the real stylesheet, delete `prototypes/` as
+part of this work. Prototypes that are real components are not throwaway: leave them.
+
+Do not commit yet.
+
+## Step 3 - the work commit
+
+Stage everything: any uncommitted step work, plus the archive, plan, and ledger changes
+from Step 2. Make one commit.
+
+    feat: export reports as CSV
+
+    - streaming serializer for large result sets
+    - /reports/export route
+    - empty and error states
+
+Conventional prefix, a subject saying what the change does, and a short body naming what
+changed. Never a plan number, a roadmap reference, or any AI attribution: someone reading
+this history later has none of those documents open.
+
+If checkpoints already committed the steps, this commit carries the bookkeeping and the
+history reads as the build sequence followed by its closing entry. Then offer to squash
+the item into one commit. Squashing rewrites history, so it needs an explicit yes, and it
+is refused outright when any of those commits has already been pushed.
+
+## Step 4 - land it
+
+Under **`git.mode: trunk`** the work is already on the branch you were on. There is nothing
+to merge. Go to Step 5.
+
+Under **`branch-per-item`**:
+
+1. Squash-merge into the default branch, only with an explicit yes, so the item lands as
+   one commit however many checkpoints the branch carried.
+2. Delete the branch after a clean merge.
+3. Stop.
+
+Then, in either mode, ask separately whether to push. **Approval to merge is not approval
+to push.** Push only after an explicit yes to pushing, in this conversation. If there is no
+remote, say so rather than guessing.
+
+## Step 5 - say how to try it
+
+Always end with the manual walkthrough for what just landed: what to start, where to go,
+what to click or run, what to expect, and what would count as wrong. This is instructions
+for a person, never a claim that the review happened.
+
+For a rollback, say how to confirm the removed behavior is gone, and name one unaffected
+path that should still work.
+
+Then point at what is next: /feature for the next planned item, or /fix.
+
+## Rules
+
+- The work item is the unit of history.
+- Do not complete failing or unfinished work. The full `Verify`, or the fallback build and
+  tests, must pass first.
+- Never land work while a P0 or P1 finding is `open` or `fixed`. The recorded ways past
+  without code are `accepted`, by the user's explicit decision with their reason, or
+  `invalid`, backed by review evidence. Both travel into the archive; neither is a silent
+  drop.
+- A rollback preserves the original archive and adds its own. Never rewrite history to
+  make a feature look as though it never existed.
+- Merging and pushing are the user's calls, and they are two separate calls.
+- One item per completion. A parent with unticked sub-items stays unticked.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/debug/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: debug
+summary: reproduce and isolate a failure without changing anything
+description: "Diagnose a failing test, broken build, crash, error, regression, or unexpected behavior without editing source or project state. Reproduces the symptom with the smallest reliable command, localizes the failing path, then tests competing hypotheses in parallel subagents and reports the root cause with the evidence that established it. Hands confirmed repair work to /fix or /implement. Use when the user runs /debug, asks why something is failing or broken, wants a root-cause investigation, or wants to understand a failure before fixing it."
+---
+
+# debug - find out what is actually wrong
+
+Diagnosis is separate from repair on purpose. An agent that is allowed to fix while it
+looks will fix three things on the way to understanding one, and none of those changes were
+reviewed against a spec.
+
+This skill changes nothing: no source edits, no state files, no commits, no installs.
+
+## Step 1 - reproduce
+
+Find the smallest command that reliably shows the failure, and run it. Record the exact
+command, the output, and the exit status.
+
+If it does not reproduce, that is the finding. Say what you ran and what happened instead,
+and ask what differs about the environment where it fails. An intermittent failure is
+reported as intermittent, with how many attempts of what kind, rather than treated as
+fixed because the second run passed.
+
+## Step 2 - localize
+
+Narrow to the smallest region that still fails. Read the stack trace properly, including
+the parts pointing into dependencies. Check what changed recently in that area.
+
+State what you have ruled out, and how. A localization that cannot say what it excluded has
+not narrowed anything.
+
+## Step 3 - test hypotheses in parallel
+
+List the plausible causes. For each one, state what would be true if it were the cause and
+what would disprove it. A hypothesis that nothing could disprove is not a hypothesis.
+
+Run each as its own subagent, given the reproduction command, the localized region, and one
+hypothesis. Each returns evidence for or against; none of them edits anything. Then weigh
+what comes back.
+
+Parallel matters here because hypotheses are independent and reproduction is often slow.
+Four subagents that each run a two-minute reproduction cost two minutes, not eight.
+
+Do not stop at the first plausible story. A hypothesis that explains the symptom is not the
+cause until the evidence rules the others out, and the cheapest place to notice that is
+before a repair has been built on it.
+
+## Step 4 - report
+
+- **What fails**, and the exact command that shows it.
+- **The cause**, when the evidence supports one, at a specific file and line.
+- **The evidence**, per hypothesis: what was tested, what came back, what it ruled in or
+  out.
+- **What is still unknown**, when the evidence was not conclusive. Say that plainly rather
+  than presenting the best guess as the answer.
+- **The repair**, described but not made: what would need to change, and roughly how large
+  it is.
+- **Next action**: /fix for an unplanned repair, /implement when it belongs to
+  work already in progress.
+
+## Rules
+
+- Change nothing. No source, no state, no commits, no dependency installs.
+- Report the cause you can prove, not the one you like.
+- A reproduction that fails to reproduce is a result worth reporting.
+- Never present a hypothesis as a conclusion.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/discovery/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: discovery
+summary: a guided planning conversation that drafts the two plans
+description: "An optional multi-turn planning conversation that develops a project plan and build plan through adaptive questioning, then drafts both files and writes them only after explicit approval. Never required: the plans can always be written directly or developed in any conversation. Use only when the user runs /discovery, asks for a guided planning session, or wants help thinking a product through before writing the plans. Do not suggest it merely because the plans are empty."
+---
+
+# discovery - think the project through, then draft the plans
+
+Optional. The plans can be written directly, and often should be. This exists for when
+someone wants the questions asked.
+
+Never suggest this as the default next step after installation. An empty plan is not a
+reason to start an interview.
+
+## How this runs
+
+A conversation over as many turns as it takes, then a draft. Nothing is written until the
+user says the drafts are right.
+
+Ask a few questions at a time, not a form. Follow what the answers actually say: a project
+with no users to speak of does not need three questions about user tiers, and a project
+whose whole difficulty is the data model deserves more than one.
+
+## What to establish
+
+Enough to fill the required plan sections, and nothing more.
+
+**The problem.** What is broken or missing, and for whom. Push past the first answer, which
+is usually a solution wearing a problem's clothes: "people need a dashboard" is a solution.
+Ask what goes wrong today without it.
+
+**The users.** Who specifically, and what each needs. If the answer is "everyone", the
+project has no users yet and that is worth knowing now.
+
+**The features.** What the first version has to do. Then ask what it deliberately does not
+do, which is the more useful question and the one nobody volunteers.
+
+**The data.** What the project works with: stored entities, or the shapes it reads and
+emits, or the interface it exposes. Ask what shape later work will depend on, since that is
+what becomes expensive to change.
+
+**The stack.** What it is built with, and anything already decided or already ruled out.
+
+Then the optional sections, only where they apply: how it makes money, how it should look
+and feel, where it deploys.
+
+## Things worth pushing on
+
+- **Vagueness that will become a decision later.** "Some kind of auth" becomes a spec
+  someone has to write. Ask now.
+- **Scope that grew during the conversation.** Say so, and ask what the first version drops.
+- **Contradictions.** Note them as they appear rather than collecting them for the end,
+  where they will be an unpleasant list.
+- **The build order.** What has to exist before what. That is what the build plan encodes.
+
+## Drafting
+
+When the user says they are ready, show both drafts **in full, in the conversation**, before
+writing anything.
+
+- **Project plan** - as much depth as the answers support. Include the rationale,
+  constraints, and exclusions, since those are what later work needs and what a plan
+  usually loses.
+- **Build plan** - a numbered checkbox list of feature-sized items in rough build order. No
+  detail; the depth belongs in each spec.
+
+Mark anything you supplied rather than heard. A draft that quietly invents a monetization
+model reads as though the user decided it.
+
+Then ask for changes, and iterate. Write both files only after an explicit yes.
+
+## Rules
+
+- Nothing is written before approval, including a partial draft "to make it concrete".
+- The plans are the user's. Draft in their terms, not in yours.
+- Do not fill a section the conversation did not cover. Leave it, and say what is missing.
+- Stop when the plans are usable, not when they are exhaustive. /overview will flag
+  what is genuinely too thin.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/distill/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: distill
+summary: promote proven observations from the journal into loaded lessons
+description: "Read religion/learning/journal.md, promote observations that have proved stable into religion/learning/lessons.md, fold corrections about this project into its coding standards, and archive what was processed. Lessons are loaded every session, so promotion is deliberately strict: an observation earns a place only once it has recurred or been confirmed. Use when the user runs /distill, asks to consolidate what has been learned, or when the journal has grown enough to be worth a pass."
+---
+
+# distill - turn observations into lessons
+
+The journal is cheap and unfiltered: anything surprising goes in. Lessons are expensive,
+because they are loaded into every session forever. This skill is the gate between them.
+
+## What goes in the journal, and when
+
+Any skill appends to `religion/learning/journal.md` when something is worth remembering:
+
+- a correction from the user, especially a repeated one
+- an assumption that turned out to be wrong about this project
+- a failure whose cause was non-obvious
+- a convention discovered in the code that no document states
+
+One entry, dated, in a sentence or two. What happened and what it implies. Appending is
+cheap and unreviewed; nothing is loaded from here.
+
+Do not journal the ordinary. "The build passed" is not an observation.
+
+## Step 1 - read and group
+
+Read the journal. Group entries that are really the same observation seen more than once.
+Recurrence is the main evidence that something is a lesson rather than an incident.
+
+## Step 2 - decide what has earned promotion
+
+Promote an observation only when it is all of these:
+
+- **Confirmed**, not suspected. Either seen more than once, or explicitly corrected by the
+  user.
+- **General**, not incidental. It will apply again, to work not yet started.
+- **Actionable**. It changes what someone would do, not just what they would know.
+- **Not already written down.** If it belongs in the coding standards or the project plan,
+  it goes there instead, where it is already loaded and already owned.
+
+Everything else stays in the journal or is dropped. A single surprising incident is not a
+lesson; it is an incident.
+
+## Step 3 - route by kind
+
+Two destinations, and the distinction matters.
+
+**About this codebase** goes to `religion/context/coding-standards.md`. "Server actions in
+this project take the organization identifier from the session, never from arguments" is a
+convention, and conventions belong with the conventions. Propose the exact edit and wait:
+the standards are the user's file.
+
+**About how work goes here** goes to `religion/learning/lessons.md`. "Schema changes in
+this project need the migration and the type change in the same step, or the typecheck
+fails halfway through review" is a lesson about working, not a coding convention.
+
+## Step 4 - write, keeping it short
+
+Each lesson is two or three lines: what to do, and why, since a lesson without its reason
+gets discarded the first time it is inconvenient.
+
+**Keep the file short.** It is loaded every session, so every line is paid for constantly.
+Before adding, look for a lesson that is now wrong, superseded, or has become obvious
+because the code changed, and remove it. A lessons file that only grows becomes a file
+nobody reads, which is worse than no file.
+
+If the file is getting long, that is a finding: report it rather than adding to it.
+
+## Step 5 - archive what was processed
+
+Remove promoted and rejected entries from the journal, appending them to
+`religion/learning/journal-archive.md` with what was decided. Nothing is deleted outright:
+a rejected observation that recurs is exactly the evidence that promotes it next time.
+
+## Step 6 - report
+
+- entries read, grouped, promoted, and rejected, with the reason for each rejection
+- lessons added, and any removed
+- standards edits proposed, and whether they were approved
+- whether the lessons file is getting too long
+
+## Rules
+
+- Promote on evidence, never on a good story. One incident is an incident.
+- Codebase conventions belong in the standards. Do not duplicate them as lessons.
+- Standards edits are proposed and wait. That file belongs to the user.
+- Remove as readily as you add.
+- Never promote something that is really a bug. That is a finding, and it belongs in the
+  ledger.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/doctor/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: doctor
+summary: check the setup is healthy and explain anything that is not
+description: "Read-only health check of the installation: required files present, adapter trees in sync, the entry file's commands accurate, configuration valid, plans usable, overview fresh, ignore rules sane, and git state workable. Runs the religion command-line tool for the deterministic checks when it is installed, then explains what any failure means and offers the fix. Use when the user runs /doctor, asks whether the setup is correct, wants a health check, or says something feels wrong before starting or resuming work."
+---
+
+# doctor - is this set up correctly
+
+/status says where the work stands. This says whether the machinery around it is
+sound. Read-only.
+
+## Step 1 - run the checks
+
+If the `religion` command is available, run `religion doctor --json`. Every check it
+performs is deterministic, so a program should perform it.
+
+Otherwise check directly:
+
+- **Files** - `religion/config.json`, both plans, the four context files, and the history
+  and reference directories exist.
+- **Configuration** - `config.json` parses, and every key and value is one the schema
+  allows. An unknown key is usually a typo, and a typo silently means the default.
+- **Adapters** - for each installed tree, the skills present and, when more than one tree
+  exists, whether they hold the same skills.
+- **Entry file** - the Commands section is filled in rather than the shipped placeholder,
+  and the commands it names exist in the project.
+- **Plans** - required sections answered, build plan is a checkbox list.
+- **Overview** - present, and its source hash matches the current plans.
+- **Ignore rules** - the state directory is either committed or ignored deliberately, not
+  half of each, and nothing secret is about to be committed.
+- **Git** - a repository exists, and it is not in a detached or mid-operation state that
+  will surprise the loop.
+
+## Step 2 - explain, do not just list
+
+For each failure, say what it means and what it will cause. "Overview hash mismatch" is
+not useful on its own; "the plans changed after the overview was generated, so the next
+spec would be written against a data model that no longer matches" is.
+
+Order by what actually blocks work. A missing history directory blocks the first
+completion; an unfilled Commands section blocks verification; a cosmetic gap blocks nothing
+and should be reported last or not at all.
+
+Offer the fix, and where it is a single obvious action, offer to make it. Regenerating a
+stale overview or creating a missing directory needs no deliberation. Anything touching the
+plans, the configuration, or git is proposed and waits.
+
+## Step 3 - report
+
+- **Healthy** or **N problems**, stated first.
+- Each problem: what is wrong, what it will cause, how to fix it.
+- What was checked, briefly, so the absence of a warning means something.
+- Next action.
+
+## Rules
+
+- Read-only by default. Fixes are offered and only made with a yes.
+- Do not report a problem that is a deliberate choice. A project with no test runner has
+  not failed a check; testing is opt-in.
+- Never claim a check passed that could not run.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/extend/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: extend
+summary: author a new skill for this workflow, with its routing tests
+description: "Add a capability to Religion itself: interview for what the skill must do, write its source with the required frontmatter, add routing tests that prove the right skill is selected for a request, render it into every adapter tree, and verify. Refuses to add a skill whose job an existing one already does, since an overlapping roster routes badly and the cost lands on every later request. Use when the user runs /extend, asks to add a skill or command to the workflow, or asks to extend Religion."
+---
+
+# extend - add a capability to the workflow
+
+This edits the workflow itself, not a project built with it. Run it in a Religion source
+checkout, where `src/skills/` exists. In an installed project there is nothing here to edit.
+
+## Step 1 - argue against it first
+
+A new skill is a permanent addition to a roster that every request is routed against. The
+cost is paid by every later request, not just the ones that use it.
+
+Read the existing roster and ask:
+
+- **Does an existing skill already own this?** If so, extend that one. A mode or an
+  argument is nearly always better than a sibling: it keeps related behavior together and
+  adds no routing ambiguity.
+- **Would this be selected reliably?** If a request that should reach it would plausibly
+  reach another skill, both get worse. Overlapping descriptions are the main way a roster
+  degrades.
+- **Is it a skill at all?** A deterministic check belongs in the command-line tool. A rule
+  belongs in the constitution or the standards. A one-off belongs in the conversation.
+
+Say what you concluded. If an existing skill should absorb it, propose that instead and
+stop. Being talked out of a new skill is a successful outcome here.
+
+## Step 2 - establish what it does
+
+- **The job**, in one sentence. If that takes two, it is two skills or it is a mode.
+- **When it should be selected**, and just as importantly when it should not, named against
+  the skills it sits closest to.
+- **What it reads and what it writes.** Every state file has exactly one writer; a new
+  writer for an existing file needs a reason and a rule for the overlap.
+- **What it must never do**, beyond the authority tiers.
+- **Where it sits in the loop**, and which skills hand to it or receive from it.
+
+## Step 3 - write the source
+
+Create `src/skills/<name>/SKILL.md` with frontmatter carrying `name` matching the
+directory, `summary` as a short clause for the roster, and `description` as the long
+routing text.
+
+**The description is what routing runs on.** Write it as the situations that should select
+this skill, in the words a user would actually use, and name the neighbours it must not be
+confused with. A description written as a feature list routes badly.
+
+Reference other skills and paths through the token vocabulary rather than writing literal
+syntax: the command token takes a skill name and renders that tool's own invocation, and
+the state token renders the state directory. A literal slash is correct for one tree and
+wrong for the others, and a literal directory name breaks if the system is ever renamed.
+The vocabulary is defined in `src/lib/adapters.ts`.
+
+Then the body: where it sits, its steps, its rules, and the formatting pointer. Match the
+existing skills, which say **why** a rule exists rather than only stating it, because a rule
+whose reason is written survives contact with a case its author did not foresee.
+
+## Step 4 - register and render
+
+Add the name to the planned roster in `src/lib/skills.ts`, or the reference check will
+reject every mention of it.
+
+Run the build, which renders it into every adapter tree, then run the verification, which
+confirms the frontmatter is complete, no token is unrendered, every reference resolves, and
+nothing drifted.
+
+## Step 5 - prove it routes
+
+Add `evals/routing/<name>.json`: prompts that must select this skill, and prompts belonging
+to neighbouring skills that must not.
+
+The negative cases matter more. A skill that fires when it should is easy; a skill that
+stays quiet when a neighbour should have fired is what keeps a large roster usable. Write
+the confusable cases deliberately, not the obvious ones.
+
+Run the routing evaluation. A regression in a **neighbouring** skill's score is the expected
+failure mode: the new description pulled requests away from it. Fix it by narrowing the
+descriptions until each request has one clear owner.
+
+## Step 6 - wire it in
+
+A skill nobody reaches is not a capability. Update whatever should point at it: the entry
+files if it changes the loop, the interaction guide if it changes the sequence, the skills
+that should hand off to it.
+
+Report what was added, what it routes on, its eval results, and every file changed.
+
+## Rules
+
+- Argue against it first, honestly.
+- One job per skill. Two sentences means two skills, or a mode on one.
+- The description is routing, not marketing.
+- Never ship a skill without its routing tests.
+- Never edit a rendered tree. Edit the source and rebuild.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.