create-religion 0.1.0

package/template/.claude/skills/overview/reference/project-overview-template.md

@@ -0,0 +1,101 @@
+# <Project Name> - Project Overview
+
+<!-- religion:source-hash <computed> -->
+
+> <one line on what this project is>
+
+## Problem
+
+What is broken today and why it matters, distilled from section 1 of the project plan.
+Two or three sentences.
+
+## Users
+
+Who this is for, from section 2. A short list of user kinds and what each needs. Note any
+access tiers, such as anonymous versus signed in.
+
+## What it does
+
+What this product already does, from section 3 of the plan. One line each. This is the
+product's identity, not a work queue, and on an established project most of it is already
+built. Mark the headline capability.
+
+- **<capability>** - what it gives someone.
+
+## Roadmap
+
+What is queued, in build-plan order, with its number. This is the work list, and it is a
+different thing from the section above: on an established project the two barely overlap.
+
+1. **<item>** - what it delivers.
+2. **<item>** - what it delivers.
+
+## Domain model
+
+The concrete shapes this project works with, derived from section 4 and the features that
+use them. Real types with fields and relationships, not a restatement of the vague list in
+the plan. This is usually the section a spec cannot be written without, and the one the
+plan does not directly contain.
+
+What belongs here depends on what the project is:
+
+- **Stores data** - the persisted models: entities, fields, types, relationships.
+- **Transforms input** (a compiler, a framework, a CLI, a parser) - the shapes it reads,
+  the shapes it emits, and the stages between them.
+- **Provides an interface** (a library, a design system) - the public types and the
+  contracts they promise.
+
+A project with no database is not a project with no domain model. Write the shapes it
+actually works with, and say what kind they are.
+
+### <Shape>
+
+- `field` (type) - what it holds
+- relates to <other shape> by <field>
+
+Mark anything later work depends on as load-bearing, so a change to it is understood as a
+breaking change rather than an edit.
+
+## Code map
+
+Where things live, so that work can name the files it will touch without re-deriving the
+layout every time.
+
+- `<path>` - what lives here, and when work belongs in it
+
+For a repository with several packages, list them with the boundary each one owns, so it is
+clear which one a given change belongs in.
+
+## Tech stack
+
+From section 5, one line each on what it is for.
+
+- **<technology>** - its role here
+
+## Monetization
+
+From section 6. Omit this heading entirely when the plan has no such section.
+
+## UI and UX
+
+From section 7: the look and feel, and the main routes or screens. Omit this heading
+entirely when the plan has no such section.
+
+- `/<route>` - what is there
+
+## Deployment
+
+From section 8: host, app type, build and start commands, output directory, environment
+variables by name, storage needs, background jobs, health path, domain notes. Omit this
+heading entirely when the plan has no such section.
+
+## Open questions
+
+Contradictions and gaps found between the two plans. Each one names what it affects, so
+that work touching that area can be blocked while work elsewhere continues.
+
+- **<short title>** (affects: <areas, features, or models>) - what the two plans say that
+  cannot both be true, or what is missing that later work will need. Resolve it in the
+  plans, then regenerate.
+
+Delete this heading when there are none.

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

@@ -0,0 +1,90 @@
+---
+name: prototype
+summary: explore the look before building, as throwaway mockups or real components
+description: "Explore how a project should look before the build loop starts. Asks what feel is wanted and which screens to draft, proposes a plan, then writes static mockups sharing one theme file to prototypes/. When the project already uses a component system, offers to prototype in that system instead, so the result is real components rather than something to port. Sits outside the reviewed loop, like scaffolding. Use when the user runs /prototype, names screens to mock up, or asks to explore the layout, theme, or look and feel."
+---
+
+# prototype - lock the look before building it
+
+Exploratory work, deliberately outside the spec loop. Deciding how something should look is
+not a reviewable build step, and forcing it through one wastes both.
+
+## Step 1 - decide which kind
+
+Look at the project. If it already has a component system with tokens and primitives, offer
+to prototype **in that system**. Otherwise write **static mockups**.
+
+| | Static mockups | In the component system |
+| --- | --- | --- |
+| Output | HTML and CSS in `prototypes/` | Real components in the project |
+| Fidelity | Approximate | Exactly what ships |
+| Afterwards | Tokens ported, folder deleted | Nothing to port, nothing to delete |
+| Good for | Deciding a look from nothing | A project whose look is already decided |
+
+Static mockups are the default because they are faster to throw away, and throwing away is
+what usually happens to the first three attempts. Prototyping in the real system is better
+once the direction is settled, because the port step is where the approximation creeps back
+in.
+
+Say which you propose and why. The user decides.
+
+## Step 2 - ask what is wanted
+
+Do not start drawing. Ask:
+
+- **The feel**, in adjectives, plus anything to look at: a site, a screenshot, a product
+  whose look is close.
+- **Which screens**, and which one matters most. Draft that one first and get it right
+  before the others copy its decisions.
+- **Constraints**: dark, light, or both; density; an existing brand.
+
+Propose a short plan and get agreement before writing files.
+
+## Step 3 - static mockups
+
+Write to `prototypes/`, one file per screen, all sharing `prototypes/theme.css`.
+
+**Every colour, size, and spacing value lives in `theme.css` as a variable.** No exceptions.
+That file is the actual output of this work: the mockups are disposable, the token set is
+the decision, and a value hardcoded in one screen is a decision that will not survive.
+
+Use realistic content. Placeholder text hides every layout problem worth finding: real
+labels are longer than expected, real lists are emptier, real names break alignment.
+
+Draft the primary screen, show it, iterate until it is right, then do the others.
+
+## Step 4 - prototyping in the component system
+
+Build the screens with the project's own primitives and tokens, in the project.
+
+Add tokens where the design needs values that do not exist yet, in the token layer, never
+inline in a component. If the design fights the system repeatedly, that is a finding worth
+reporting: either the design or the system is wrong, and knowing which is worth more than
+the mockup.
+
+These are not throwaway. Say what should be kept, what was a sketch, and what a later work
+item should build on.
+
+## Step 5 - hand off
+
+Say which mockups exist and where the tokens live.
+
+For static mockups, note that the first build step of the first visual work item ports
+`theme.css` into the project's real stylesheet, and that the folder is deleted once that
+lands. For component prototypes, note there is nothing to port.
+
+Then point at /feature. Prototypes inform the plan; they are not a work item.
+
+## Rules
+
+- Ask before drawing. A mockup built from a guess wastes the round trip that would have
+  prevented it.
+- Every value is a token.
+- Real content, never placeholder text.
+- Static mockups are throwaway and are deleted once consumed. Component prototypes are not.
+- No product logic, no data layer, no routing. This is the look.
+
+## 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/release/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: release
+summary: prepare deployment readiness for Railway, Render, or Vercel
+description: "Prepare a project to deploy to Railway, Render, or Vercel. Reads the plans, commands, package files, and existing provider configuration; creates or updates local configuration and an environment example; runs build and start checks; and reports the environment variables, the smoke-test path, and the blockers. Stops before deploying, creating a remote service, changing a remote environment, pushing, or publishing. Use when the user runs /release, asks about deployment readiness or provider configuration, or names a provider."
+---
+
+# release - get ready to deploy, without deploying
+
+Prepares. Does not deploy. Deploying, creating a remote service, changing remote
+environment values, pushing, and publishing all need their own explicit yes, and this skill
+stops before every one of them.
+
+Run it after a completed item or a milestone, not as part of the build loop.
+
+## Step 1 - target and shape
+
+Take the provider from the argument: `/release railway`, `/release render`, `/release vercel`.
+Without one, read the deployment section of the project plan, and ask if it is not there.
+
+Then establish what is actually being deployed, because the answer changes everything: a
+static site, a server-rendered application, a service, a worker, a scheduled job, or several
+of these together.
+
+| Provider | Fits |
+| --- | --- |
+| **Railway** | Long-running services, workers, scheduled jobs, and anything wanting a managed database beside it |
+| **Render** | Similar shapes, with static sites and cron as first-class kinds |
+| **Vercel** | Front-end and edge-first applications, static output, serverless functions |
+
+If the project's shape fits the chosen provider badly, say so once, plainly, with the
+specific mismatch. Then proceed with what was asked.
+
+## Step 2 - survey
+
+- Build and start commands, and the output directory for static output.
+- The runtime version, and whether it is pinned.
+- Every environment variable the code reads, **by name**, found by searching the source
+  rather than by trusting a checked-in example file which is usually stale.
+- Data stores, caches, queues, and anything else it expects to exist.
+- Background work: workers, scheduled jobs, migrations that must run before start.
+- A health endpoint, if there is one.
+- Existing provider configuration already in the repository.
+
+## Step 3 - write local configuration
+
+Create or update only local files: the provider's configuration file, and an environment
+example listing every variable by name.
+
+**Never put a real secret in a file.** The example lists names and describes what each is
+for. A value that looks like a credential is never copied into it, and never printed.
+
+Preserve configuration that already exists. Show a diff for anything you change, and say
+why.
+
+Migrations that must run before start belong in the release or pre-deploy step the provider
+offers, not in the build. Getting that wrong deploys code against a schema that has not
+moved yet, which is the failure that takes a site down rather than failing a build.
+
+## Step 4 - check locally what can be checked
+
+Run the build. Run the start command far enough to see it come up. Hit the health path if
+there is one.
+
+A failure here is a blocker, and finding it locally is the entire point of doing this
+before deploying.
+
+## Step 5 - report
+
+- **Blockers** first: what would fail, and why.
+- **Environment variables**, by name, marking which have no local value yet.
+- **The exact next step** for that provider, as a command or a console action, so the user
+  can take it themselves.
+- **The smoke test**: what to hit after deploying and what should come back.
+- **What was not verified** and cannot be locally: the real database, real credentials,
+  cold starts, the domain.
+
+## Rules
+
+- Never deploy, create a remote service, change a remote environment, push, or publish.
+  Preparing is the whole job.
+- Never write, print, or copy a secret value.
+- Never claim a deployment will work. Report what was checked and what was not.
+- Provider tooling may be used to read state. Using it to change anything is a separate yes.
+
+## 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/rollback/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: rollback
+summary: plan a guarded reversal of completed work, preserving its history
+description: "Plan the safe reversal of a completed item using its archive and the commits it recorded when it landed. Verifies the recorded commits still resolve and are ancestors of HEAD, reviews later commits for work that depends on them, then writes a Type: Rollback spec to religion/context/current-work.md and stops before any code changes. The reversal applies only the product diff in reverse, never a whole-commit revert, so the archive and plan bookkeeping that landed in the same commits survive. Use when the user runs /rollback, asks to remove or undo completed work, or wants the project returned to its behavior before an item without erasing the record that it existed."
+---
+
+# rollback - plan a guarded reversal
+
+Where this sits:
+
+    history/  ->  [rollback]  ->  implement  ->  complete
+    (archive)     (plan it)       (apply it)     (record it)
+
+Removing completed work is not `git revert`. The commits that landed an item also carry its
+archive, its build-plan tick, and its ledger pruning. Reverting them whole would delete the
+record that the work ever existed, and would fight with whatever the plan says now.
+
+This skill plans. It writes a spec and stops. No product file changes here.
+
+## Step 1 - identify the target
+
+Take a build-plan number or name. Match it to a **checked** item and its archive under
+`religion/history/features/`. If the item is not checked, it was never completed, and there
+is nothing to roll back: say so.
+
+Read the archive's `## Landed` section for the base commit, the item's commits, and the
+product paths it touched.
+
+**If there is no `## Landed` section**, the item was completed before that record existed.
+Do not guess the commit range from messages or dates: reversing the wrong commits damages
+unrelated work. Report what is missing, show the archive and the commits around it, and ask
+the user to confirm the exact range before continuing.
+
+## Step 2 - verify the record still holds
+
+Stop on any failure. Do not repair a mismatch by choosing a nearby commit.
+
+1. Every recorded identifier matches `^[0-9a-f]{40}$`. Reject abbreviated or uppercase
+   values.
+2. Every recorded commit resolves in this repository and is an ancestor of `HEAD`.
+3. The recorded base is the parent of the earliest recorded commit.
+4. The working tree is clean apart from the rollback spec being written.
+
+## Step 3 - preview the product diff
+
+Compute the reversal exactly as it will be applied, excluding everything the workflow owns:
+
+    git diff --binary <base> <last-recorded-commit> -- . \
+      ':(exclude).agents/**' ':(exclude).claude/**' \
+      ':(exclude)religion/**' \
+      ':(exclude)AGENTS.md' ':(exclude)CLAUDE.md' \
+      ':(exclude)prototypes/**'
+
+Confirm the result is non-empty and its paths match the product paths in the archive. A
+mismatch means the record and the repository disagree, which is a stop.
+
+Never drop those exclusions for convenience. They are what keeps the archive, the plan, and
+the ledger intact while the product change goes away.
+
+Under `git.mode: trunk` the item's commits sit among other commits on the same branch. The
+recorded range is what separates them; the diff is still computed only across that range,
+never from the branch tip.
+
+## Step 4 - review what came after
+
+Inspect commits after the target for work that depends on it: imports of things it added,
+callers of its functions, columns or fields it introduced, configuration it established.
+
+Report each dependency with its commit and file. A reversal that cascades into later work
+is not a rollback, it is a second reversal that has not been planned. Say so plainly and
+let the user decide before writing the spec.
+
+## Step 5 - write the spec
+
+Write `religion/context/current-work.md` marked `Type: Rollback`, recording:
+
+- **Target** - the item, its number, and its archive path
+- **Reason** - why it is being removed, in the user's words
+- **Base** and **Commits** - the verified full identifiers
+- **Product paths** - what the reverse patch will touch
+- **Later dependencies** - what Step 4 found, and how each is handled
+- **Build steps** - normally one: apply the reverse patch and confirm the tree
+- **Done when** - the removed behavior is gone, and one named unaffected path still works
+
+Include the exact command from Step 3 in the spec, so implementation applies the reviewed
+diff rather than reconstructing it.
+
+Then stop for review.
+
+## What implementation will do
+
+Recorded here so the spec and the build agree:
+
+1. Recompute the diff from Step 3 and confirm it still matches.
+2. Apply it in reverse with three-way conflict detection, and stage it:
+   `... | git apply --reverse --3way --index`
+3. Show the staged diff and the status, and confirm no workflow-owned path is touched.
+
+On a conflict: stop, report the exact paths and the later commit involved, and ask. Never
+auto-resolve, discard, stash, reset, or check out broadly. A cascade into other completed
+work needs its own plan.
+
+## Rules
+
+- The archive is never deleted or rewritten. Completion adds a rollback record beside it.
+- Reverse only the recorded product diff. Never a whole-commit revert.
+- The build-plan item is unticked and annotated, and keeps its number.
+- Stop on any mismatch between the record and the repository. Guessing is what makes a
+  rollback dangerous.
+
+## 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/setup/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: setup
+summary: tune the installation to this project, greenfield or existing
+description: "Set up Religion after installing it into a project. Detects whether the project is newly scaffolded or already has shipped work, and branches: a new project gets its entry file, standards, and configuration tuned before you write the plans, while an existing one is surveyed so the plans and standards are generated from what is actually there. Documents the real commands, reports existing checks, decides whether workflow files are committed, and says what to do next. Use when the user runs /setup, has just installed Religion, or asks what to do first."
+---
+
+# setup - make the installation match this project
+
+Run once, after installing. It replaces the shipped assumptions with what is true here.
+
+## Step 0 - which project is this
+
+Look before asking. Count source files, read the git history, check whether the project has
+shipped anything.
+
+- **New** - a scaffold, little or no history, no meaningful features yet. The plans are
+  written from intent, by the user, after this runs.
+- **Existing** - real features, real history, real users possibly. The plans are generated
+  from what already exists, in this run.
+
+State which you concluded and why, and let the user correct you. Guessing wrong is
+recoverable but wasteful: the existing path does substantially more work.
+
+## Step 1 - survey the project
+
+Both paths need this.
+
+- **Stack** - languages, framework, package manager, module system, versions.
+- **Commands** - the real ones, from the package manifest or task runner: dev, build, test,
+  lint, typecheck. Never invent one. A command that does not exist is worse than a missing
+  one, because it will be run.
+- **Checks that already exist** - test runner, typecheck, lint, continuous integration.
+  Report them; do not add any.
+- **Conventions** - file organization, naming, how components and modules are actually
+  structured, how data is accessed, how errors are handled. What the code does, not what a
+  style guide would say.
+- **Layout** - the directories that matter and what each owns.
+
+## Step 2 - write what you learned
+
+**The entry file's Commands section.** Replace the placeholder with the real commands. If
+the project has a single command that runs its checks in order, record it as `Verify`. If
+it does not, leave that out; /ci defines one deliberately later.
+
+**The coding standards' Stack conventions section.** Fill it from the survey: language
+conventions, file organization, naming, framework patterns, data access, as this project
+actually does them. Do not import opinions the project does not hold. If the project is
+inconsistent, say so and pick the dominant pattern, noting that it was a choice.
+
+**The project title** in the entry files, and the one-line description.
+
+## Step 3 - the plans
+
+**New project.** Leave both plans as templates and tell the user to fill them in, or to run
+/discovery for a guided session. Do not write plans from a scaffold; there is
+nothing there to derive intent from.
+
+**Existing project.** Generate both, then have them reviewed:
+
+- **Project plan** - problem, users, and features derived from the code, the README, and
+  the history. Tech and data from what is actually there. Mark anything you inferred rather
+  than found, because inferring intent from an implementation is exactly where this goes
+  wrong: the code says what was built, never why.
+- **Build plan** - shipped features listed as **checked** items, so the history is honest
+  and numbering starts from reality. Unshipped work goes in unchecked, if the user names
+  any.
+
+Ask for the intent the code cannot reveal: who this is for, what problem it solves, what
+was deliberately excluded. That conversation is the whole value of this path. Then stop for
+review before anything downstream runs.
+
+## Step 4 - visibility
+
+Ask whether the workflow files should be committed or kept local. Do not pick a default.
+
+- **Committed** - plans, specs, and history are part of the repository: portable across
+  machines, visible to collaborators, reviewable.
+- **Local** - added to `.gitignore`, so nothing about the workflow enters a shared
+  repository. Not portable: another machine needs it installed again.
+
+If those paths are already tracked and the user chooses local, say that `.gitignore` alone
+will not untrack them, and ask before running anything that would.
+
+## Step 5 - report
+
+- what was detected: stack, commands, existing checks
+- what was changed, file by file
+- what the user must do next, exactly: fill in the plans, or review generated ones
+- optional things worth knowing about, without pushing: /tests if there is logic and
+  no runner, /ci if there are checks and no automation
+
+Then stop. The next step is /overview, once the plans are real.
+
+## Rules
+
+- Detect before asking, then let the user correct the detection.
+- Never invent a command, a convention, or a feature.
+- Mark inferred intent as inferred.
+- Do not install anything, add a test runner, or create continuous integration here.
+- Generated plans are a draft for review, never a finished artifact.
+
+## 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/status/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: status
+summary: say where the work stands and what to do next
+description: "Report where the project stands: build-plan progress, the active spec and which of its steps are done, open findings, git state, and the one action that makes sense next. Uses the religion command-line tool when it is installed, since the parsing is deterministic, and reads the state files directly when it is not. Read-only. Use when the user runs /status, asks where things stand, what is next, what is in progress, or is picking work back up after a break or a cleared context."
+---
+
+# status - where things stand
+
+Read-only. It reports; it never advances anything.
+
+## Step 1 - get the state
+
+If the `religion` command is available, run `religion status --json` and use it. The
+parsing is deterministic and a program does it more reliably than a reading of the files.
+
+Otherwise read them directly: `religion/build-plan.md` for progress,
+`religion/context/current-work.md` for the active spec and its ticked steps,
+`religion/context/findings.md` for the ledger, `religion/context/project-overview.md` for
+its source hash, and the git branch and working-tree state.
+
+## Step 2 - report
+
+Lead with the next action, because that is the question actually being asked.
+
+- **Next** - the single command that makes sense now, and why in one clause.
+- **Active work** - the item, and which step it is on out of how many. "Nothing in
+  progress" when the spec is the stub.
+- **Plan** - items complete out of total, and the next unchecked one.
+- **Findings** - counts by status, naming any P0 or P1 that is `open` or `fixed`, since
+  those block completion.
+- **Git** - branch, whether the tree is dirty, and unpushed commits.
+- **Warnings** - only real ones: a stale overview, an open question blocking queued work,
+  a spec whose steps are all ticked but which was never completed, a dirty tree with no
+  active spec.
+
+Say "up to date" rather than inventing a warning when there is nothing wrong.
+
+## Choosing the next action
+
+| State | Next |
+| --- | --- |
+| Plans not filled in | Write them, or run /discovery |
+| Overview missing or stale | /overview |
+| No active spec, plan has unchecked items | /feature |
+| Active spec, steps unticked | /implement |
+| All steps ticked, not verified | /check |
+| Verified, findings blocking | /audit, or repair via /implement |
+| Verified, nothing blocking | /complete |
+| Plan complete | Add to the plan, or /release |
+
+When two apply, take the one further along: finishing beats starting.
+
+## Rules
+
+- Read-only. Never write a state file, tick a step, or advance anything.
+- One next action. A list of options is not an answer to "what now".
+- Do not guess at what is happening. If the state is contradictory, say what is
+  contradictory.
+
+## 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/tests/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: tests
+summary: set up unit testing, or backfill coverage for logic that already exists
+description: "Set up unit testing for this project: detect the stack, reuse an existing runner or install the stack-native one, add a small example test, record the command in the entry file, and run it. Declaring that command is what turns testing into a gate for logic-bearing work. Given `backfill`, instead writes tests for logic that already exists, worst-covered first. Use when the user runs /tests, asks to add or set up unit tests, or asks to cover existing code with tests."
+---
+
+# tests - turn the testing gate on, or backfill coverage
+
+Two modes. `/tests` sets the runner up. `/tests backfill` covers logic that already
+exists. Setup comes first; backfilling into no runner is not a thing.
+
+## Setup mode
+
+### Step 1 - look before installing
+
+If a runner is already configured, use it. Adding a second is how a project ends up with
+two test commands and no idea which one is authoritative.
+
+If there is none, choose the stack-native one: vitest for a TypeScript or JavaScript
+project, pytest for Python, the built-in tooling for Go or Rust. Do not import a preference
+the ecosystem does not share.
+
+Say what you found and what you propose before installing anything. Installing a dependency
+needs a yes.
+
+### Step 2 - wire it up
+
+Install the runner, add the script or task, and add **one** small test that genuinely
+exercises something real in this project. Not a test that asserts true is true: a test that
+would fail if the thing it covers broke.
+
+### Step 3 - record the command
+
+Add the exact command to the Commands section of the entry file as `Test`.
+
+**This is the switch.** Once that command is declared, a build step that adds logic ships a
+passing test in the same diff, and completion will not finish while the suite is red. Say
+that plainly, because it changes how every later work item behaves.
+
+If a `Verify` command exists, add the test command to it in the right order: typecheck,
+then tests, then build.
+
+### Step 4 - prove it
+
+Run the test command and show the output. Then run it again with the example test
+deliberately broken, to show it actually fails. A suite that cannot fail is not a gate, and
+an empty suite reporting success is the specific failure worth ruling out here.
+
+Restore it, and report what changed.
+
+## Backfill mode
+
+For logic that shipped without tests. Deliberate, bounded, and never automatic.
+
+### Step 1 - find what is worth covering
+
+Only in-scope logic: parsers, formatters, validators, identifier builders, server actions,
+anything with assertable inputs and outputs and real edge cases. Not components, not
+integration surfaces, not anything whose test would just mirror the implementation.
+
+Rank by risk, not by convenience: how badly a wrong answer would hurt, how likely a wrong
+answer is, how often the code changes. Present the ranked list and how many to do now. Do
+not attempt the whole project in one pass.
+
+### Step 2 - write them, in reviewed batches
+
+One module at a time, each as its own reviewable diff. For each, cover the normal case, the
+edges the code actually handles, and the edges it does not.
+
+**When a test fails, stop.** A backfilled test that fails has found a bug, and that is the
+valuable outcome. Do not adjust the test to match the behavior: report it, and let it
+become a fix. Writing the test around the bug destroys the only reason to have written it.
+
+### Step 3 - report
+
+What was covered, what was skipped and why, and every discrepancy found. Discrepancies are
+the point; coverage is the side effect.
+
+## Rules
+
+- Never install a runner during unrelated work. This is a deliberate setup step.
+- One runner per project.
+- Never write a test that cannot fail.
+- Never change behavior to make a backfilled test pass.
+- Setup adds one example test, not a suite.
+
+## Formatting
+
+Match the conventions in `religion/context/ai-interaction.md`: concise, scannable
+markdown, lists for enumerations and tables for matrices rather than dense paragraphs.