create-religion 0.1.0

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

@@ -0,0 +1,169 @@
+---
+name: audit
+summary: review the code itself across four lenses, recording findings in the ledger
+description: "Read-only code review across four lenses (quality, security, performance, tests) and four scopes (current work, changed files, a path, or the whole project), fanning the lenses out to subagents that read and return findings while this skill performs the single write. Records each finding in religion/context/findings.md with a durable identifier, a severity from P0 to P3, and a status, where an open or fixed P0 or P1 blocks completion. Use when the user runs /audit, asks for a code, quality, security, performance, or test review, wants dead code or duplication found, or wants a repair re-reviewed before it closes."
+---
+
+# audit - review the code, and record what you find
+
+/check proves the work behaves as promised. This skill reviews the code itself.
+
+It changes nothing except the findings ledger. It never edits source, installs anything,
+commits, merges, or starts repair work.
+
+## Input
+
+Scope and lens are separate, and may appear in either order: `/audit security current`,
+`/audit src/auth tests`.
+
+**Scope**, defaulting to `current` when work is active, else `changed` when the tree is
+dirty, else `full`:
+
+- `current` - the active spec, everything the work item has changed so far, and the code
+  around it that the change affects
+- `changed` - staged, unstaged, and untracked source, plus nearby code
+- `full` - all project-owned source, tests, and configuration, excluding dependencies,
+  generated files, build output, caches, vendored code, and minified assets
+- a path - that area, plus the tests and callers needed to understand it
+
+**Lens**, defaulting to all four:
+
+- `quality` - duplication, dead code, unreachable paths, oversized modules, abstractions
+  that do not pay for themselves, inconsistency, drift from the project's standards
+- `security` - missing authorization, client-controlled ownership, injection, unsafe
+  parsing, data exposure, secret handling, insecure defaults, trust-boundary mistakes
+- `performance` - repeated queries and network calls, unnecessary rendering, blocking work
+  on hot paths, unbounded loops and collections, memory growth, oversized payloads,
+  missing pagination, unsafe concurrency
+- `tests` - important logic with no coverage, weak assertions, tests that only mirror the
+  implementation, excessive mocking, shared state, order or time dependence, skipped or
+  focused tests, swallowed failures
+
+State the scope and lens you chose before reviewing.
+
+## Step 1 - gather context
+
+Read the project overview, the coding standards, the active spec, the existing findings
+ledger (for identifiers and statuses), the configuration, and the relevant source.
+
+For `current`, resolve the comparison base without touching the network: a base named by
+the spec or project instructions, else the recorded default branch, else a local `main`
+then `master`. Find the merge base and inspect the committed range through `HEAD`, then add
+staged, unstaged, and untracked work. If no reliable base exists, say so and review the
+spec plus local changes, without claiming committed work was covered.
+
+For `full`, state the excluded paths before reviewing, so generated or third-party code
+does not consume the review.
+
+## Step 2 - run the signals that exist
+
+Use only commands the project already has. Do not install tools, and do not fetch.
+
+Lint and typecheck when relevant; the test command for the tests lens or to validate a
+suspected risk; the build when the lens needs compilation evidence. A useful command that
+does not exist is a gap worth reporting, not a reason to add one.
+
+## Step 3 - review, one subagent per lens
+
+Run each selected lens as its own subagent over the resolved scope. They read code and
+**return** findings; they never write. This skill merges what comes back, assigns
+identifiers, and performs the single write in Step 4. Parallel reviewers cannot race a
+file that only one of them writes.
+
+Give each subagent the scope, the file list, the standards, and its own lens only. A lens
+that wanders into another lens produces duplicates that then have to be reconciled.
+
+**The ledger never scopes the review.** Review the code fresh, then record what was found.
+Working from the open findings as a checklist and verifying only those is the exact failure
+the ledger exists to prevent: a repair can introduce a defect no existing entry points at.
+
+Ground every finding in reachable code. Prefer a short list of real findings to a long list
+of guesses, and do not report style differences that are merely different.
+
+Do not broaden a focused pass because another lens looks interesting. If an obvious P0
+appears outside the selected lens, record it as an out-of-lens critical risk, but do not
+start searching that lens.
+
+If a possible secret appears, never quote its value, paste the matching line, or include
+raw output containing it. Report the redacted category, file, line, risk, and remediation.
+
+## Step 4 - write the ledger
+
+`religion/context/findings.md` is the durable record. Chat does not survive a cleared
+context; this does. Create it with a `# Findings` heading if it is missing.
+
+One block per finding. The header line is the machine-readable part and keeps this exact
+shape; the prose below it is for people.
+
+    ### F-03 [P0] open - Retained auth volumes carry the run label
+
+    **File:** ops/compose.yaml:86
+    **Found:** 2026-09-04 by audit (scope: current; lens: security)
+    **Why it matters:** ...
+    **Suggested fix:** ...
+    **Resolution:**
+
+Identifiers are sequential within the ledger, one past the highest present, never reused
+and never renumbered while their entries live there. Completion archives resolved entries
+under a work-item prefix, and that prefixed form is the permanent reference.
+
+| Status | Meaning | Blocks completion at P0/P1 |
+| --- | --- | --- |
+| `unverified` | Suspected, no confirming evidence yet | No |
+| `open` | Confirmed, not yet repaired | Yes |
+| `fixed` | Repaired, not yet re-reviewed | Yes |
+| `closed` | Repaired and re-reviewed against the new code | No |
+| `accepted` | Not fixing, by the user's explicit decision, reason recorded | No |
+| `invalid` | Re-examination proved it wrong, evidence recorded | No |
+
+After reviewing:
+
+- Append each new confirmed finding as `open`.
+- Record a lead worth tracking as `unverified`. It never gates anything.
+- Update entries this pass re-examined, noting the evidence in **Resolution**.
+- Move `fixed` to `closed` only when all three hold: this pass covered the finding's file,
+  re-examining the repaired code confirmed the defect is gone and nothing worse replaced
+  it, and the report names it as closed. An unrelated new problem in the same file gets its
+  own entry. Never close implicitly.
+- Set `accepted` only on the user's explicit decision, with their reason. Never on their
+  behalf.
+- Set `invalid` only when re-examination shows the finding was wrong, with that evidence.
+  It is a review verdict, never a shortcut past a gate.
+
+`fixed` blocking completion is deliberate: a repair is done when a review has looked at the
+result, not when the code changed.
+
+## Step 5 - report
+
+Findings first, ordered by severity, using the identifiers just assigned.
+
+Severity: **P0** data loss, a security break, or code that cannot ship. **P1** a likely bug,
+a broken contract, a missing guard. **P2** a maintainability problem worth fixing before
+the work closes. **P3** a small cleanup or follow-up.
+
+P0 and P1 require a concrete code path, a violated contract or boundary, a failing command,
+or reproducible behavior. Incomplete evidence goes under **Unverified risks** with what is
+missing, never presented as a confirmed high-severity finding.
+
+Then report: ledger changes by identifier; commands run and their results; the scope and
+lens chosen; the commit range for `current`; the paths reviewed and excluded; checks that
+could not run; and a suggested repair order.
+
+A focused lens is not a broad review. Say what was not reviewed, and never imply the
+omitted lenses passed. For `full`, say whether coverage was complete or partial.
+
+## Rules
+
+- The ledger is the only file this skill writes.
+- The ledger reports status; it never defines what the review looks at.
+- Never reproduce a secret or sensitive value.
+- Ground every finding in a file and line where possible.
+- Recommend the smallest fix that removes the risk, not a rewrite.
+- Respect the project's existing patterns over generic advice.
+- The goal is code that is understandable, consistent, tested where it matters, and safe to
+  keep building on. Not perfection.
+
+## 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/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/.claude/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/.claude/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/.claude/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.