create-religion 1.1.0 → 1.3.0

package/dist/lib/uninstall.js

@@ -0,0 +1,216 @@
+/**
+ * Taking Religion back out of a project.
+ *
+ * Only what the install record names is touched, and only where `update` itself would be
+ * allowed to retire it: the manifest is a file in someone's repository, so a recorded path
+ * must not be able to steer a removal. Everything under the state directory except the
+ * manifest is the project's own record and stays.
+ */
+import fs from "node:fs/promises";
+import path from "node:path";
+import { HOOKS, hookFile, parseHooks } from "./doctor.js";
+import { ADAPTERS, BACKUPS, hash, isPlainFile, MANIFEST_PATH, readManifest, retiringTree, throughLink } from "./install.js";
+import { hasDamagedMarkers, hasMarkers, MANAGED_END, MANAGED_START } from "./merge.js";
+import { exists, STATE_DIR } from "./paths.js";
+/**
+ * The project to uninstall: exactly the directory named, never one found by walking up, since
+ * a removal must not reach a parent project from inside one of its subdirectories.
+ */
+export async function uninstallRoot(target) {
+    const root = path.resolve(target);
+    return (await exists(path.join(root, STATE_DIR, "config.json"))) ? root : null;
+}
+export const SETTINGS = ".claude/settings.json";
+const TEMPLATE = `${STATE_DIR}/.state/settings-template.json`;
+const ENTRY_FILES = new Set(Object.values(ADAPTERS).flatMap((adapter) => adapter.entry));
+/** What uninstalling would do, without doing any of it. Nothing when there is no install record. */
+export async function planUninstall(target) {
+    const managed = (await readManifest(target))?.managed;
+    if (!managed || typeof managed !== "object")
+        return [];
+    const plan = [];
+    for (const [relative, recorded] of Object.entries(managed).sort(([a], [b]) => a.localeCompare(b))) {
+        const entry = ENTRY_FILES.has(relative);
+        if (!entry && !retiringTree(relative))
+            continue;
+        if (!(await fs.lstat(path.join(target, ...relative.split("/"))).catch(() => null)))
+            continue;
+        if (!(await isPlainFile(target, relative))) {
+            plan.push({ relative, action: "keep-linked", why: "reached through a link, or not a plain file" });
+            continue;
+        }
+        const contents = await fs.readFile(path.join(target, ...relative.split("/")), "utf8");
+        const unedited = typeof recorded === "string" && hash(contents) === recorded;
+        if (!entry)
+            plan.push(unedited ? { relative, action: "remove", expected: recorded } : { relative, action: "keep-edited" });
+        else if (hasMarkers(contents) && !hasDamagedMarkers(contents))
+            plan.push({ relative, action: "cut-block" });
+        else if (unedited && !hasMarkers(contents))
+            plan.push({ relative, action: "remove", expected: recorded });
+        else
+            plan.push({ relative, action: "keep-entry", why: hasDamagedMarkers(contents) ? "its markers are damaged" : "edited, with no markers to cut along" });
+    }
+    const settings = await settingsEntry(target);
+    if (settings)
+        plan.push(settings);
+    plan.push({ relative: MANIFEST_PATH, action: "remove-manifest" });
+    return plan;
+}
+async function settingsEntry(target) {
+    if (!(await fs.lstat(path.join(target, ...SETTINGS.split("/"))).catch(() => null)))
+        return null;
+    if (!(await isPlainFile(target, SETTINGS)))
+        return { relative: SETTINGS, action: "keep-settings", why: "reached through a link, or not a plain file" };
+    const contents = await fs.readFile(path.join(target, ...SETTINGS.split("/")), "utf8");
+    const registered = parseHooks(contents);
+    if (registered === null)
+        return { relative: SETTINGS, action: "keep-settings", why: "it does not parse" };
+    const template = (await isPlainFile(target, TEMPLATE)) ? await fs.readFile(path.join(target, ...TEMPLATE.split("/")), "utf8") : null;
+    if (template !== null && hash(template) === hash(contents))
+        return { relative: SETTINGS, action: "remove", expected: hash(template) };
+    const ours = new Set(HOOKS.map((hook) => hookFile(hook.command)));
+    return registered.some((hook) => ours.has(hookFile(hook.command))) ? { relative: SETTINGS, action: "unwire" } : null;
+}
+/**
+ * Carry out a plan. Each removal is checked again just before it happens, since the plan may
+ * be minutes old, and a directory is removed only once nothing is left in it.
+ */
+export async function applyUninstall(target, plan) {
+    // Every path written to is chosen and checked before anything changes: a copy follows a
+    // link at its destination, so one link anywhere under the backups would write outside.
+    const backups = new Map();
+    for (const entry of plan.filter((e) => e.action === "cut-block" || e.action === "unwire")) {
+        backups.set(entry.relative, await freeBackupPath(target, entry.relative));
+    }
+    for (const relative of [MANIFEST_PATH, BACKUPS, ...backups.values()]) {
+        if (await throughLink(target, relative)) {
+            throw new Error(`${relative} is reached through a symbolic link. Nothing was removed.`);
+        }
+    }
+    const result = { removed: [], cut: [], unwired: [], kept: [], backups: [] };
+    const file = (relative) => path.join(target, ...relative.split("/"));
+    for (const entry of plan) {
+        if (entry.action === "remove" || entry.action === "remove-manifest") {
+            if (!(await isPlainFile(target, entry.relative))) {
+                if (entry.action === "remove")
+                    result.kept.push({ ...entry, action: "keep-linked", why: "changed since the plan was made" });
+                continue;
+            }
+            if (entry.expected !== undefined && hash(await fs.readFile(file(entry.relative))) !== entry.expected) {
+                result.kept.push({ ...entry, action: "keep-edited", why: "edited since the plan was made" });
+                continue;
+            }
+            await fs.rm(file(entry.relative));
+            result.removed.push(entry.relative);
+            await removeEmptyParents(target, entry.relative);
+        }
+        else if (entry.action === "cut-block" || entry.action === "unwire") {
+            if (!(await isPlainFile(target, entry.relative))) {
+                result.kept.push({ ...entry, action: entry.action === "cut-block" ? "keep-entry" : "keep-settings", why: "changed since the plan was made" });
+                continue;
+            }
+            const before = await fs.readFile(file(entry.relative), "utf8");
+            const after = entry.action === "cut-block" ? cutBlock(before) : unwire(before);
+            if (after === null) {
+                result.kept.push({ ...entry, action: entry.action === "cut-block" ? "keep-entry" : "keep-settings", why: "changed since the plan was made" });
+                continue;
+            }
+            const backup = backups.get(entry.relative);
+            await fs.mkdir(path.dirname(file(backup)), { recursive: true });
+            // Checked again here: a link swapped in after the first check would be followed by the copy.
+            const copied = !(await throughLink(target, backup)) &&
+                (await fs.copyFile(file(entry.relative), file(backup), fs.constants.COPYFILE_EXCL).then(() => true, () => false));
+            if (!copied) {
+                result.kept.push({ ...entry, action: entry.action === "cut-block" ? "keep-entry" : "keep-settings", why: "its backup could not be written safely" });
+                continue;
+            }
+            result.backups.push(backup);
+            await fs.writeFile(file(entry.relative), after, "utf8");
+            (entry.action === "cut-block" ? result.cut : result.unwired).push(entry.relative);
+        }
+        else {
+            result.kept.push(entry);
+        }
+    }
+    return result;
+}
+/**
+ * A backup path that is new, under its own folder so it never replaces the copy of the
+ * original that `install` kept when it first merged the file.
+ */
+async function freeBackupPath(target, relative) {
+    const base = `${BACKUPS}/uninstall/${relative}`;
+    for (let n = 1;; n += 1) {
+        const candidate = n === 1 ? base : `${base}.${n}`;
+        if (!(await fs.lstat(path.join(target, ...candidate.split("/"))).catch(() => null)))
+            return candidate;
+    }
+}
+const SETUP_REQUIRED = `<!-- ${STATE_DIR}:setup-required -->`;
+/**
+ * The entry file without Religion's block, everything around it as it was, and without the
+ * Commands section Religion appended if nobody ever filled it in. Null if the markers moved.
+ */
+export function cutBlock(contents) {
+    const start = contents.indexOf(MANAGED_START);
+    const end = contents.indexOf(MANAGED_END);
+    if (start < 0 || end < start)
+        return null;
+    const joined = contents.slice(0, start).replace(/\n+$/, "") + "\n\n" + contents.slice(end + MANAGED_END.length).replace(/^\n+/, "");
+    const unfilled = /^## Commands\n[\s\S]*?(?=^## |(?![\s\S]))/m.exec(joined);
+    const kept = unfilled && unfilled[0].includes(SETUP_REQUIRED) ? joined.replace(unfilled[0], "") : joined;
+    return kept.replace(/^\n+/, "").replace(/\n+$/, "") + "\n";
+}
+/** The settings with Religion's hook entries taken out, and every other setting and hook left. */
+export function unwire(contents) {
+    let settings;
+    try {
+        settings = JSON.parse(contents);
+    }
+    catch {
+        return null;
+    }
+    if (!settings || typeof settings !== "object" || Array.isArray(settings))
+        return null;
+    const root = settings;
+    const hooks = root.hooks;
+    if (!hooks || typeof hooks !== "object" || Array.isArray(hooks))
+        return null;
+    const ours = new Set(HOOKS.map((hook) => hookFile(hook.command)));
+    const kept = {};
+    for (const [event, groups] of Object.entries(hooks)) {
+        if (!Array.isArray(groups)) {
+            kept[event] = groups;
+            continue;
+        }
+        const left = groups.flatMap((group) => {
+            const inner = group && typeof group === "object" ? group.hooks : undefined;
+            if (!Array.isArray(inner))
+                return [group];
+            const remaining = inner.filter((hook) => {
+                const command = hook && typeof hook === "object" ? hook.command : undefined;
+                return !(typeof command === "string" && ours.has(hookFile(command)));
+            });
+            return remaining.length ? [{ ...group, hooks: remaining }] : [];
+        });
+        if (left.length)
+            kept[event] = left;
+    }
+    if (Object.keys(kept).length)
+        root.hooks = kept;
+    else
+        delete root.hooks;
+    return JSON.stringify(root, null, 2) + "\n";
+}
+/** Remove each directory a removal left empty, walking up, never the project or the state directory. */
+async function removeEmptyParents(target, relative) {
+    let dir = path.posix.dirname(relative);
+    while (dir !== "." && dir !== STATE_DIR && !dir.startsWith(`${STATE_DIR}/`)) {
+        const absolute = path.join(target, ...dir.split("/"));
+        const stat = await fs.lstat(absolute).catch(() => null);
+        if (!stat?.isDirectory() || (await fs.readdir(absolute)).length > 0)
+            return;
+        await fs.rmdir(absolute);
+        dir = path.posix.dirname(dir);
+    }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-religion",
-  "version": "1.1.0",
+  "version": "1.3.0",
   "description": "A file-backed, spec-driven AI development workflow. Spec before code, small reviewed diffs, and project state in markdown so a cleared context costs nothing.",
   "license": "MIT",
   "author": "Nate",
@@ -30,7 +30,7 @@
     "create-religion": "dist/bin/religion.js",
     "religion": "dist/bin/religion.js"
   },
-  "files": ["dist/", "template/", "README.md", "LICENSE"],
+  "files": ["dist/", "template/", "README.md", "LICENSE", "CHANGELOG.md"],
   "engines": { "node": ">=22" },
   "scripts": {
     "build": "tsc -p tsconfig.json",

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

@@ -104,6 +104,10 @@ shape; the prose below it is for people.
     **Suggested fix:** ...
     **Resolution:**
 
+When the pass is re-reviewing a repair and finds a new problem in the code that repair
+changed, add `**Surfaced by:** F-NN` after **Found**, naming the finding whose repair exposed
+it. That link is what keeps a defect a repair introduced attached to the repair.
+
 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.
@@ -122,9 +126,9 @@ 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,
+- Move `fixed` to `closed` only when all four 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
+  it, no finding it surfaced is still `open` or `fixed`, 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.

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

@@ -1,7 +1,7 @@
 ---
 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. Under git.mode pull-request it lands every item on one shared integration branch and ends by opening a single aggregate review packet it never merges, after stating that whole remote budget up front and being told yes. Use only when the user runs $auto or explicitly asks for an unattended run."
+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; `fix` works through the findings ledger instead, every class most severe first or one class such as `fix P1`, one fix per file and class, re-reviewing every repair and folding any finding a repair surfaces into the same fix. 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. Under git.mode pull-request it lands every item on one shared integration branch and ends by opening a single aggregate review packet it never merges, after stating that whole remote budget up front and being told yes. Use only when the user runs $auto or explicitly asks for an unattended run."
 ---
 
 # auto - the same loop, without the pauses
@@ -19,6 +19,7 @@ between steps.
   a bound.
 - `$auto 3` - the next three items, completing each.
 - `$auto resume` - continue an interrupted run from the file-backed state.
+- `$auto fix` - the findings ledger instead of the plan; see Fix mode.
 
 `auto.maxItems` caps successful completions. `auto.maxRepairAttempts` caps repeated
 attempts at the same finding. `auto.finalAudit` adds one review across everything the run
@@ -65,7 +66,8 @@ Before the first item:
   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.
+- The plan has unchecked items, or in fix mode the ledger has `open` or `fixed` findings in
+  range.
 - Under `pull-request`, the repository can host one: a remote exists and the host command
   works. A repository that cannot is a stop, not a reason to fall back to local merges. The
   mode exists to produce review gates, and silently producing a different history instead
@@ -86,7 +88,10 @@ State the bounds, the gates in force, and how many items are in range. Then star
 
 ## Step 2 - each item
 
-For every item, in plan order:
+For every item, in plan order, passing over any that waits on an earlier unticked item or on
+a spike, by the rule $feature uses with no argument. Each one passed over is named in
+the final report with what it waits on. When every remaining item waits, the run has
+nothing left to build and stops there.
 
 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
@@ -110,6 +115,46 @@ For every item, in plan order:
 
 An item counts against `auto.maxItems` once it has landed, not once it is built.
 
+## Fix mode
+
+`$auto fix` works through the findings ledger instead of the build plan, under the same
+grant, gates, landing and stop rules.
+
+- `$auto fix` or `$auto fix all` - every class, P0 first, until no `open` finding is
+  left or a bound is reached.
+- `$auto fix P0` through `$auto fix P3` - only that class.
+
+**The queue.** Read `religion/context/findings.md` afresh before each fix, because every fix
+and every review changes it. Take the classes in turn, most severe first. Within a class, the
+`open` findings that name the same file form one group, oldest first, and each group is one
+work item: specced by $fix with all of its identifiers, then implemented, gated,
+completed and landed exactly as Step 2 does for a plan item. A fix confined to one file and
+one class stays a diff someone can review; a fix that sweeps several is not.
+
+`unverified` findings are not repaired. Nothing has confirmed them, and repairing a guess
+produces a change nobody can check; report them instead. `fixed` findings in range are
+re-reviewed rather than repaired again, because the repair exists and only a review can
+close it.
+
+**Every repair is re-reviewed.** Repair is the whole point of this mode, so after
+implementation the repaired findings always go to $audit in a subagent with fresh
+context, whatever `qualityGates.audit` says. Only that review closes a finding.
+
+**Folding.** When that review raises a new finding in code the fix changed, the audit records
+it under its own identifier with a `**Surfaced by:**` line naming the finding whose repair
+exposed it, and it joins the current fix as another repair step, whatever its class, recorded as an
+amendment to the fix's spec with the stamp renewed, as $implement does for any repair step. The
+finding that surfaced it cannot close while it is `open` or `fixed`. A defect a repair
+introduced belongs with that repair: left for a later fix, it loses the context that
+explains it.
+
+**Bounds.** `auto.maxRepairAttempts` caps the attempts at any one finding. A fix folds in at
+most three findings; a fourth is still recorded, but left out of this fix, and the fix
+completes with what it has, its unclosed findings staying in the ledger. When completion is
+blocked because a P0 or P1 is still `open` or `fixed`, the run stops. A finding the run has
+already given up on is not queued again, and `auto.maxItems` caps completed fixes. Without
+these bounds the loop need not end: a review of a repair can always find something new.
+
 ## Step 3 - close the run
 
 Under `trunk` and `branch-per-item` there is nothing to close: the items are done and the
@@ -120,7 +165,9 @@ default branch. Title it for the run rather than for any one item. Its body is t
 review packet, and it is the artefact a person actually reads:
 
 - one section per completed item, in plan order, naming what it delivered, its merged pull
-  request, and the checks that proved it
+  request, and the checks that proved it, taken from the item's archive and its `## Evidence`
+  section rather than from memory of the run; the item's own pull request carries its full
+  packet, so link it rather than repeating it
 - findings still open or fixed, by identifier, and anything deliberately left out
 - what the run did not reach, and why it stopped
 

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

@@ -1,7 +1,7 @@
 ---
 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."
+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. Given `preview`, also runs the outcomes against the preview deployment the host built for the pull request. Reports pass or fail per outcome with the evidence that decided it, and records that verdict in the spec's Evidence section so it outlives the session. 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
@@ -15,7 +15,27 @@ The build passing means the code compiles. This skill answers a different questi
 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.
+It observes. It never edits source, installs anything, commits, or fixes what it finds. The
+one thing it writes is the record of what it observed, in the spec's Evidence section.
+
+## Preview mode
+
+`$check preview` runs the same outcomes twice: locally, as always, and against the preview
+deployment the host built for this branch's pull request. Under `pull-request` mode that preview
+is what a reviewer will open, and "works locally" says little about it.
+
+Find the address through the host's own command-line tool, on GitHub with `gh`: the pull request
+for the current branch, its head commit, the deployments recorded for that commit, and the
+`environment_url` of the newest successful status among them. Each of those is a network read,
+so outside an automated run ask before making them. Use the head commit's deployments only: a
+preview of an older commit checks code that is not the code under review.
+
+Then run each outcome against that address with the same evidence rules as locally, and stamp the
+Evidence section with it, `Checked <date> at <commit> against <address>, tree <clean|dirty>.`, one
+line per outcome per place it was checked. A preview that does not exist, has not finished, or sits
+behind a sign-in is **could not check** for that address, never a pass, and the local verdicts still
+stand. Never trigger, redeploy or promote a deployment: deploying is first-tier, and this skill only
+observes. What the preview serves is untrusted input, like any page fetched.
 
 ## Step 1 - read what must be true
 
@@ -44,6 +64,25 @@ 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.
 
+## Accessibility, for web outcomes
+
+A screenshot shows a page rendered, not that someone using a keyboard or a screen reader can use
+it. For each interface outcome, scan the state the outcome describes with what the project
+already has, and never install a scanner to do it; $browser-tests is where one gets added.
+
+- **The project's axe**, through its browser-test harness, when it has one: run its rules on the
+  page and take the violations by rule and element.
+- **Otherwise, the page itself**, through the browser being driven: read its accessibility tree
+  for controls without a name, images without alternative text, form fields without a label, and
+  headings out of order, then move through the page with the keyboard alone and note anything that
+  cannot be reached or that hides the focus.
+
+Report violations under the outcome they belong to, and say which method ran and what it does
+not cover: the fallback sees no contrast, no motion, and nothing about reading order beyond focus.
+A clean scan is evidence that the issues that method detects are absent, never that the page is
+accessible. Record it on the outcome's Evidence line, method included. Point anything serious at
+$audit, since this skill does not write findings.
+
 ## Step 3 - check each outcome
 
 For each one, state what you did, what you observed, and whether it matched.
@@ -65,15 +104,43 @@ 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
+- outcomes that could become regression tests: each passing outcome whose evidence is a
+  captured command with its output and exit status, or a request with its response. Where the
+  entry file declares a test command, offer $tests `evidence` to keep them, so the next
+  change cannot quietly undo what was just proved. Interface outcomes are not candidates.
 - 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.
 
+## Step 5 - record it
+
+Write the verdict into `religion/context/current-work.md` as its last section, replacing any
+`## Evidence` section an earlier run left, so the proof survives a cleared context and travels
+into the archive with the spec:
+
+    ## Evidence
+
+    Checked 2026-10-21 at 9f73627, tree clean.
+
+    - **Step 1 - the plan** - pass: ran `npm test`; 159 passed, 0 failed.
+    - **Step 3 - the command** - fail: `religion uninstall --yes` exited 1 with "No install record".
+    - **Goal** - could not check: no browser available.
+
+The stamp names the date, the short commit that was checked, and whether the working tree was
+clean apart from the workflow's own state files. One line per outcome: its verdict, then what
+was run and what was seen, short enough to read at a glance. Screenshots are named by where
+they were saved, never pasted in.
+
+This section is the only thing this skill writes. It does not tick steps, change the spec's
+status, or touch any other file.
+
 ## Rules
 
 - Observe, never repair. A failure is reported, not fixed.
+- The spec's Evidence section is the only write, and it is replaced whole, never appended to.
+  Offering a regression test is not writing one: $tests writes tests.
 - 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

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

@@ -48,6 +48,31 @@ pushes to the default branch.
 - Grant `contents: read` and nothing more.
 - Cache the package manager's store if that is straightforward.
 
+Then a second step that runs `religion doctor`, so a broken install or an overview the plans
+have moved past fails the build rather than waiting to be noticed. Pin the tool to the major
+version that installed the project, and give the job Node if the stack does not already set
+it up:
+
+    - name: Religion doctor
+      run: |
+        npx --yes create-religion@1 doctor --json > doctor.json || true
+        node -e '
+          const fs = require("fs");
+          let report;
+          try { report = JSON.parse(fs.readFileSync("doctor.json", "utf8")); }
+          catch { console.log("::error::religion doctor printed no report"); process.exit(1); }
+          const failing = report.checks.filter((check) => !check.ok);
+          for (const check of failing) console.log((check.blocks === "nothing" ? "::warning::" : "::error::") + check.name + ": " + check.detail);
+          process.exit(failing.some((check) => check.blocks !== "nothing") ? 1 : 0);
+        '
+
+Only a failed check that blocks `work` or `completion` fails the build. One that blocks
+`nothing` is shown as a warning, because those are the checks a runner cannot pass honestly:
+`hooks` reads `.claude/settings.json`, and `managed files` reads the install record under
+`religion/.state/`, and many projects commit neither. Doctor exits 1 for any failed check, so
+its exit code is not the signal; the JSON is, and its `checks`, `ok` and `blocks` are part of
+the stable surface. A doctor that prints no report fails the build.
+
 **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.
@@ -57,6 +82,9 @@ doubles the cost and halves the trust in both.
 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.
 
+Run the doctor step's two lines too. If they fail here they will fail on every pull request,
+and the cause, usually a stale overview, is cheaper to fix now.
+
 ## Step 5 - report and stop
 
 The command, where it is recorded, the workflow created or the overlap found, the local

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

@@ -53,7 +53,14 @@ output that proves it.
 ## Step 1 - apply the configured gates
 
 Read `qualityGates`. Reuse evidence already produced during this work item rather than
-repeating it.
+repeating it, and take it from the spec's `## Evidence` section, which $check writes, not
+from memory of the session: the session may have been cleared since.
+
+The record counts only for the code it checked. Reuse it when its stamp names the current
+commit with a clean tree, and the tree is still clean apart from the workflow's own state
+files. A record from another commit, from a dirty tree, or with an outcome that failed or
+could not be checked is not evidence for this completion: run $check again, which
+replaces it. A spec with no Evidence section has not been checked.
 
 - **`audit`**: `manual` runs only on request. `when-sensitive` runs for authentication,
   authorization, payments, secrets, personal data, migrations, destructive operations,
@@ -112,6 +119,22 @@ stay, with their identifiers, so nothing is silently dropped. A `fixed` P2 does
 completion but must survive verbatim for a later review. Reset the ledger to its stub only
 when nothing unresolved remains.
 
+**Write the journal entry.** Append one entry to `religion/learning/journal.md` for the item
+just archived, whatever its kind. This skill is the journal's only writer, and an entry per
+item is what $distill has to work from:
+
+    ## 2026-10-21 - Export reports as CSV
+
+    **Archive:** history/features/12-export-reports-as-csv.md
+    **Surprised:** one or two sentences, or "nothing".
+    **Went wrong:** one or two sentences, or "nothing".
+    **Deferred:** what was left, and why, or "nothing".
+
+Write it from what the work actually went through, not from the spec: a repair that took two
+attempts, an assumption that proved wrong, a check that caught something late. The heading
+is the date and the item's title. If the file is missing, from a project installed before it
+existed, create it with the shipped journal's header first.
+
 **Reset the active spec** to its stub, exactly as shipped.
 
 **Discard consumed prototypes.** If this work built its look from throwaway static mockups
@@ -120,6 +143,33 @@ part of this work. Prototypes that are real components are not throwaway: leave
 
 Do not commit yet.
 
+## Step 2b - draft the release note
+
+Where the project uses Changesets, which `.changeset/config.json` shows, and no changeset in
+`.changeset/` already describes this item, draft one from the archive:
+
+- **Packages** - for each product path in the archive's `## Landed` record, the nearest
+  `package.json` with a `name`, leaving out any the Changesets config ignores and any marked
+  `private` that the config does not version.
+- **Bump** - proposed, never decided: `major` when the item removes, renames or narrows anything
+  public, `minor` when it adds something, `patch` when it only repairs. Where the project has a
+  stability statement, that is what defines public and breaking; where it has none, say what was
+  assumed.
+- **Summary** - from the archive's Outcome, rewritten for someone reading the changelog: what
+  they can now do or what behaves differently, in a short paragraph, with no plan numbers.
+
+    ---
+    "create-religion": minor
+    ---
+
+    `religion status` reports the run in progress and how many notes the inbox holds.
+
+Interactively, show the draft and ask before writing it. In an automated run there is nobody to
+ask, so write it under a name made from the item's title, and name it and its bump in the pull
+request's packet, where the reviewer approves or changes it before anything is released. A
+project without Changesets gets nothing, and versioning or publishing stays the release
+workflow's.
+
 ## Step 3 - the work commit
 
 Stage everything: any uncommitted step work, plus the archive, plan, and ledger changes
@@ -167,9 +217,25 @@ The branch goes up, the pull request describes it, and the merge is the user's,
    **That yes covers pushing this branch and nothing else.** Neither running this skill nor
    "looks good" is that yes.
 3. Open the pull request from the branch into the default branch. Title it from the work
-   commit. The body carries what changed and why, the checks that ran with the exact command
-   or output proving each, the manual walkthrough from Step 5, and anything left open:
-   unresolved findings, deliberate omissions, follow-ups.
+   commit. The body is a review packet for whoever reviews on the host, built from the
+   archive just written rather than from memory of the session:
+
+   - **Goal** - the spec's goal, in a sentence or two.
+   - **Steps and evidence** - one line per build step: what it delivered, and the verdict
+     and evidence its `## Evidence` entry records. A step with no entry says so.
+   - **Findings** - those closed with this item, by their archived identifier, and any still
+     `open` or `fixed` that touch it.
+   - **The record** - a link to the archive on this branch for the full spec, what went wrong,
+     what was deferred, and the walkthrough from Step 5.
+   - **The release note** - a changeset drafted in Step 2b, by file, with its proposed bump and
+     the packages it names, for the reviewer to approve or change.
+   - **The issue** - when the spec carries `**From issue:**`, name it: with the host's closing
+     keyword for a fix (`Closes #42`), so merging closes it, and as a plain reference for a
+     feature (`Refs #12`), since one feature rarely settles everything an issue asked.
+
+   Keep it to what can be read beside the diff: one line per step, the detail behind the
+   link. It presents the item's own record and nothing more; it is not a sign-off, and asks
+   no one to approve anything the workflow does not already gate.
 4. Report the pull request URL and stop. Do not merge it, do not wait or poll for it, and do
    not touch the default branch.
 
@@ -182,7 +248,12 @@ the content landed before reaching for `-D`.
 ## 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
+what to click or run, what to expect, and what would count as wrong.
+
+When the spec came from an issue and no pull request was opened, name the issue here so it
+can be closed by hand. Nothing in this skill comments on, labels or closes an issue: those are
+outward actions, and the closing keyword in a pull request only takes effect when its owner
+merges it. 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