create-religion 0.1.0

package/template/.agents/skills/auto/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: auto
+summary: run the loop unattended, within explicit bounds
+description: "Run the reviewed loop without stopping between steps, within bounds you set. With no argument it takes one work item and stops before completing it; `all` runs the remaining build plan; a number runs that many items. Specs, implements, verifies, applies the configured gates, repairs confirmed high-severity findings, and completes each item. Its invocation grants committing, dependency installs, and remote reads for the run, and grants nothing else: it still stops to ask before any merge. Use only when the user runs $auto or explicitly asks for an unattended run."
+---
+
+# auto - the same loop, without the pauses
+
+Explicit opt-in only. Never suggest this as a next action, and never fall into it because
+several items are queued.
+
+Same skills, same gates, same evidence. The only difference is that it does not stop
+between steps.
+
+## Bounds
+
+- `$auto` - one work item, stopping **before** completing it, with a review packet.
+- `$auto all` - the remaining build plan, completing each item, until it runs out or hits
+  a bound.
+- `$auto 3` - the next three items, completing each.
+- `$auto resume` - continue an interrupted run from the file-backed state.
+
+`auto.maxItems` caps successful completions. `auto.maxRepairAttempts` caps repeated
+attempts at the same finding. `auto.finalAudit` adds one review across everything the run
+produced.
+
+## What the invocation grants
+
+Running this authorizes, for this run only: committing, installing dependencies, and
+network reads. That is the second authority tier, and the invocation is the approval.
+
+It grants **nothing** in the first tier. Merging, pushing, deploying, publishing, deleting
+data, and rewriting history each still stop and ask, every time, no matter how many items
+remain.
+
+Under `git.mode: trunk` there is no merge, so a run completes items and keeps going. Under
+`branch-per-item` it stops once per item to ask. That is not a flaw in the mode; landing
+work on a shared branch is a decision, and it stays one.
+
+## Step 1 - preflight once
+
+Before the first item:
+
+- Configuration is valid. Stop and point at $doctor if not.
+- The overview is fresh, or regenerate it.
+- No open question blocks the queued items. One that does stops the run **before** any work
+  starts, naming the question, since a run that stops halfway through item four is worse
+  than one that never began.
+- The working tree is clean, or the only dirt belongs to work being resumed.
+- The plan has unchecked items.
+
+State the bounds, the gates in force, and how many items are in range. Then start.
+
+## Step 2 - each item
+
+For every item, in plan order:
+
+1. **Spec it**, following $feature, including the sizing and the self-critique. Do
+   not skip the critique because nobody is reading: it is what catches an oversized step
+   before it becomes an unreviewable diff.
+2. **Implement it**, following $implement, with no prompt between steps. Verify each
+   step against what it touched.
+3. **Apply the gates** from `qualityGates`, then run the full `Verify`.
+4. **Repair confirmed findings** at P0 and P1, within this item's scope, then re-review them
+   in a subagent with fresh context. Give up after `auto.maxRepairAttempts` and stop with
+   the finding recorded rather than trying variations.
+5. **Complete it**, following $complete, which archives, ticks the plan, prunes the
+   ledger, and commits. Ask before any merge.
+6. **Report one line** and move on.
+
+## Step 3 - stop
+
+Stop immediately, keeping all state intact, when any of these happens:
+
+- a check fails and two repair attempts do not fix it
+- a product decision is needed that the plans do not answer
+- a finding cannot be repaired within the item's scope
+- work would touch anything in the first authority tier
+- an item turns out to need splitting in a way that changes the plan
+- a bound is reached
+- the same failure appears twice in a row across different items, which means something
+  systemic and further items will not fix it
+
+A stopped run leaves the branch, the spec, and the ticked steps exactly as they are.
+`$auto resume` picks up from there, because the state is in files rather than in the run.
+
+## Step 4 - report
+
+- items completed, by name, and what each delivered
+- what stopped the run, exactly, and the state it stopped in
+- findings raised, repaired, and still open
+- checks run, and any that could not run
+- the resume command, when one applies
+
+Never report an item as complete when its gate did not pass. An unattended run that
+overstates what it did is worse than one that stopped early, because nobody was watching
+the part it got wrong.
+
+## Rules
+
+- Explicit invocation only.
+- The gates are the same gates. Unattended is not a reason to lower one.
+- Never merge, push, deploy, publish, or delete without asking, however long the queue is.
+- Never widen an item's scope to make its gate pass.
+- Stop on ambiguity. There is nobody to ask mid-run, so a guess compounds silently.
+
+## 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/.agents/skills/browser-tests/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: browser-tests
+summary: set up a repeatable browser test harness and record its command
+description: "Add or normalize a repeatable browser test harness, reusing an existing runner where there is one and otherwise preferring Playwright for web and browser-extension projects. Adds one project-relevant smoke test, records the command in the entry file, and proves it runs. Distinct from live browser evidence during a check: this is regression coverage that runs unattended and for other people. Use when the user runs $browser-tests, asks to add browser or end-to-end tests, or asks to make browser behavior repeatable."
+---
+
+# browser-tests - repeatable browser coverage
+
+$check drives a real browser to prove one work item behaves. This sets up a harness
+that keeps proving it, unattended, for everyone.
+
+Different jobs. Live browser evidence answers "does this work now", with no setup and full
+fidelity. A harness answers "did we break it", forever, and runs where nobody is watching.
+A project can want either, both, or neither.
+
+## Step 1 - look first
+
+Reuse a compatible runner if one exists. If not, prefer Playwright for web and
+browser-extension projects: it installs its own browsers, runs headless, and is the
+ecosystem default.
+
+Say what you propose, including that it downloads browser binaries, before installing.
+
+## Step 2 - set it up minimally
+
+Install it, add the configuration, and write **one** smoke test that exercises something
+this project actually does. Not a test that loads a page and asserts the title: a test that
+would fail if the project's main path broke.
+
+Keep the configuration small. Base URL, one browser, a way to start the project. Sharding,
+matrices, and visual snapshots are later choices, and adding them now means maintaining
+them from a position of no evidence that they help.
+
+## Step 3 - record the command
+
+Add it to the Commands section of the entry file as `Browser tests`.
+
+Once declared, specs can include focused browser coverage for stable behavioral outcomes,
+and checks can run it as one evidence source. It does not prove visual fidelity, real
+signed-in behavior, or browser chrome, and must never be described as though it did.
+
+## Step 4 - prove it
+
+Run the command and show the output. Then break the assertion and show it failing, so the
+harness is known to be wired to the project rather than passing vacuously.
+
+## Step 5 - report
+
+What was installed, the exact command, what the smoke test covers, and what it does not.
+
+Say explicitly that this is **not** added to `Verify` or to continuous integration unless
+the user asks. Browser tests are slow and flakier than unit tests; putting them in the
+default gate is a real cost and should be a decision, not a side effect.
+
+## Rules
+
+- One harness per project. Reuse before installing.
+- One smoke test, not a suite. Coverage grows with the work that needs it.
+- Never claim the harness proves something it does not observe.
+- Not in `Verify` or continuous integration without an explicit 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/.agents/skills/check/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: check
+summary: prove the current work does what its spec says, against the running project
+description: "Prove the current work actually does what its spec says by running the real project and observing behavior against each stated outcome. Picks its evidence from what the project is: a live browser for web work, captured command output for a CLI, request and response for an API, plus any configured test harness. Reports pass or fail per outcome with the evidence that decided it. Never edits source, never commits; fixing belongs to $implement. Use when the user runs $check, asks to confirm the work behaves correctly, wants proof before completing, or wants a change checked in the running project rather than only in the build."
+---
+
+# check - prove the work against the running project
+
+Where this sits:
+
+    implement  ->  [check]  ->  complete
+    (built it)     (prove it)   (close it out)
+
+The build passing means the code compiles. This skill answers a different question: does it
+actually do what the spec said it would. Those are not the same question, and only one of
+them is what the user asked for.
+
+It observes. It never edits source, installs anything, commits, or fixes what it finds.
+
+## Step 1 - read what must be true
+
+Read `religion/context/current-work.md` and take the stated outcome from every build step,
+plus anything in the Goal and Testing sections that makes a claim about behavior. Those
+outcomes are the checklist. Nothing else is in scope.
+
+If the spec is still the stub, say so and stop.
+
+## Step 2 - pick the evidence
+
+Choose by what the project actually is. Never assume a harness exists, and never install one.
+
+| Project shape | Evidence |
+| --- | --- |
+| Web interface | Drive a real browser: navigate, interact, screenshot each outcome, and read the console and network for errors the page does not show |
+| Command line tool | Run the real command with real arguments and capture stdout, stderr, and exit status |
+| Service or API | Issue real requests and record status, headers, and body |
+| Library | Exercise the public interface the way a consumer would, not through internals |
+| Background work | Trigger it and observe its effect, not just that it was scheduled |
+
+When the entry file declares a browser test command, run it too, as one source among
+several. Do not treat it as proof of visual fidelity, real signed-in behavior, browser
+chrome, or anything else it does not actually observe.
+
+Start the project the way its own commands say to. If it cannot start, that is the finding:
+report it and stop rather than reasoning about what would have happened.
+
+## Step 3 - check each outcome
+
+For each one, state what you did, what you observed, and whether it matched.
+
+- **Pass** needs observed behavior. Not a passing build, not code that looks correct, not
+  a plausible argument.
+- **Fail** names what happened instead, with the evidence.
+- **Could not check** is its own result, with the reason. It is never a pass. A required
+  outcome that cannot be checked is a blocker.
+
+Check the unhappy paths the spec named: empty and malformed input, the error and empty
+states, the first-run case. A feature that works only on the happy path is not done, and
+this is where that gets caught rather than after it ships.
+
+## Step 4 - report
+
+Lead with the verdict, then the evidence.
+
+- each outcome, with pass, fail, or could not check, and what proved it
+- what was run, exactly
+- anything observed that the spec did not ask about but that looks wrong
+- next action: $implement when something failed, $complete when everything
+  passed
+
+Never say passed, verified, or working without naming the command, route, screenshot, or
+output behind it.
+
+## Rules
+
+- Observe, never repair. A failure is reported, not fixed.
+- Never install a runner, a browser, or a dependency to make a check possible. Report the
+  gap.
+- Do not widen scope beyond the spec's stated outcomes, except to report something clearly
+  broken that you happened to see.
+- A check that could not run is a blocker, never a pass.
+
+## 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/.agents/skills/ci/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: ci
+summary: define one Verify command and the GitHub workflow that runs it
+description: "Set up automatic checks around one documented Verify command. Detects the real stack, package manager, default branch, and existing workflows; combines only the checks the project actually has into one command; records it in the entry file; creates .github/workflows/verify.yml when that does not overwrite existing continuous integration; runs the command locally; and stops before pushing or changing any remote setting. Use when the user runs $ci, asks to add continuous integration, GitHub Actions, or pull-request checks."
+---
+
+# ci - one command, run automatically
+
+The mental model, in three parts:
+
+- **Verify is the recipe.** One local command running the checks this project already has,
+  in order: typecheck, then tests, then build.
+- **The workflow is the worker.** It runs that same command on pull requests and on the
+  default branch.
+- **A branch rule is the lock.** Requiring the check before merge is a remote setting, and
+  a separate decision this skill does not make.
+
+The recipe turns nothing on by magic. A project with typechecking and a build but no test
+runner gets a Verify command with two parts, and gains the third when $tests adds a
+runner.
+
+## Step 1 - detect
+
+The stack and runtime version, the package manager and its install command, the checks that
+actually exist, the default branch, and any workflows already present.
+
+Never assume. A `test` script that runs `echo "no tests"` is not a test command, and
+treating it as one produces a green check that means nothing.
+
+## Step 2 - define Verify
+
+Combine only checks that exist, in order: typecheck, tests, build. Never invent one to fill
+the recipe.
+
+For a JavaScript or TypeScript project, prefer a package script named `verify` using the
+detected package manager. For other stacks, use the native task runner or the exact
+combined command.
+
+Record it in the Commands section of the entry file as `Verify`. That is what
+implementation and completion will run, so it has to be exactly right.
+
+## Step 3 - the workflow
+
+Write `.github/workflows/verify.yml` running that same command on pull requests and on
+pushes to the default branch.
+
+- Use the project's real runtime version and install command.
+- Grant `contents: read` and nothing more.
+- Cache the package manager's store if that is straightforward.
+
+**Never overwrite existing continuous integration.** If a workflow already runs these
+checks, say so, show where they overlap, and stop. Two workflows running the same suite
+doubles the cost and halves the trust in both.
+
+## Step 4 - run it locally
+
+Run the Verify command exactly as written. If it fails, the recipe is wrong or the project
+is broken, and either way it must not be committed in that state.
+
+## Step 5 - report and stop
+
+The command, where it is recorded, the workflow created or the overlap found, the local
+result, and what remains a separate decision.
+
+Stop before pushing. Requiring the check in the repository's settings is a remote change
+and needs its own yes, on top of the push.
+
+## Rules
+
+- Only real checks go in Verify.
+- Never overwrite an existing workflow.
+- No git hooks, coverage thresholds, browser tests, security scanners, or version matrices.
+  Those are later choices, made deliberately.
+- Do not push, and do not change any remote setting.
+
+## 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/.agents/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/.agents/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.