create-religion 1.2.0 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (48) hide show
  1. package/CHANGELOG.md +466 -0
  2. package/README.md +2 -1
  3. package/dist/bin/religion.js +87 -7
  4. package/dist/lib/args.js +15 -5
  5. package/dist/lib/changelog.js +29 -0
  6. package/dist/lib/dashboard.js +102 -22
  7. package/dist/lib/doctor.js +134 -26
  8. package/dist/lib/install.js +43 -6
  9. package/dist/lib/paths.js +18 -0
  10. package/dist/lib/settings.js +156 -0
  11. package/dist/lib/state.js +261 -8
  12. package/dist/lib/status.js +38 -3
  13. package/dist/lib/uninstall.js +216 -0
  14. package/package.json +2 -2
  15. package/template/.agents/skills/auto/SKILL.md +9 -3
  16. package/template/.agents/skills/check/SKILL.md +69 -2
  17. package/template/.agents/skills/ci/SKILL.md +28 -0
  18. package/template/.agents/skills/complete/SKILL.md +76 -5
  19. package/template/.agents/skills/distill/SKILL.md +42 -19
  20. package/template/.agents/skills/feature/SKILL.md +19 -4
  21. package/template/.agents/skills/feature/reference/spec-template.md +1 -0
  22. package/template/.agents/skills/fix/SKILL.md +7 -0
  23. package/template/.agents/skills/implement/SKILL.md +37 -9
  24. package/template/.agents/skills/implement/reference/worktrees.md +175 -0
  25. package/template/.agents/skills/scout/SKILL.md +2 -2
  26. package/template/.agents/skills/spike/SKILL.md +8 -0
  27. package/template/.agents/skills/status/SKILL.md +17 -4
  28. package/template/.agents/skills/tests/SKILL.md +45 -3
  29. package/template/.claude/hooks/warn-on-drift.mjs +74 -0
  30. package/template/.claude/hooks/write-handoff.mjs +54 -2
  31. package/template/.claude/skills/auto/SKILL.md +9 -3
  32. package/template/.claude/skills/check/SKILL.md +69 -2
  33. package/template/.claude/skills/ci/SKILL.md +28 -0
  34. package/template/.claude/skills/complete/SKILL.md +76 -5
  35. package/template/.claude/skills/distill/SKILL.md +42 -19
  36. package/template/.claude/skills/feature/SKILL.md +19 -4
  37. package/template/.claude/skills/feature/reference/spec-template.md +1 -0
  38. package/template/.claude/skills/fix/SKILL.md +7 -0
  39. package/template/.claude/skills/implement/SKILL.md +37 -9
  40. package/template/.claude/skills/implement/reference/worktrees.md +175 -0
  41. package/template/.claude/skills/scout/SKILL.md +2 -2
  42. package/template/.claude/skills/spike/SKILL.md +8 -0
  43. package/template/.claude/skills/status/SKILL.md +17 -4
  44. package/template/.claude/skills/tests/SKILL.md +45 -3
  45. package/template/AGENTS.md +7 -2
  46. package/template/CLAUDE.md +7 -2
  47. package/template/religion/.state/settings-template.json +9 -0
  48. package/template/religion/learning/journal.md +4 -3
@@ -0,0 +1,216 @@
1
+ /**
2
+ * Taking Religion back out of a project.
3
+ *
4
+ * Only what the install record names is touched, and only where `update` itself would be
5
+ * allowed to retire it: the manifest is a file in someone's repository, so a recorded path
6
+ * must not be able to steer a removal. Everything under the state directory except the
7
+ * manifest is the project's own record and stays.
8
+ */
9
+ import fs from "node:fs/promises";
10
+ import path from "node:path";
11
+ import { HOOKS, hookFile, parseHooks } from "./doctor.js";
12
+ import { ADAPTERS, BACKUPS, hash, isPlainFile, MANIFEST_PATH, readManifest, retiringTree, throughLink } from "./install.js";
13
+ import { hasDamagedMarkers, hasMarkers, MANAGED_END, MANAGED_START } from "./merge.js";
14
+ import { exists, STATE_DIR } from "./paths.js";
15
+ /**
16
+ * The project to uninstall: exactly the directory named, never one found by walking up, since
17
+ * a removal must not reach a parent project from inside one of its subdirectories.
18
+ */
19
+ export async function uninstallRoot(target) {
20
+ const root = path.resolve(target);
21
+ return (await exists(path.join(root, STATE_DIR, "config.json"))) ? root : null;
22
+ }
23
+ export const SETTINGS = ".claude/settings.json";
24
+ const TEMPLATE = `${STATE_DIR}/.state/settings-template.json`;
25
+ const ENTRY_FILES = new Set(Object.values(ADAPTERS).flatMap((adapter) => adapter.entry));
26
+ /** What uninstalling would do, without doing any of it. Nothing when there is no install record. */
27
+ export async function planUninstall(target) {
28
+ const managed = (await readManifest(target))?.managed;
29
+ if (!managed || typeof managed !== "object")
30
+ return [];
31
+ const plan = [];
32
+ for (const [relative, recorded] of Object.entries(managed).sort(([a], [b]) => a.localeCompare(b))) {
33
+ const entry = ENTRY_FILES.has(relative);
34
+ if (!entry && !retiringTree(relative))
35
+ continue;
36
+ if (!(await fs.lstat(path.join(target, ...relative.split("/"))).catch(() => null)))
37
+ continue;
38
+ if (!(await isPlainFile(target, relative))) {
39
+ plan.push({ relative, action: "keep-linked", why: "reached through a link, or not a plain file" });
40
+ continue;
41
+ }
42
+ const contents = await fs.readFile(path.join(target, ...relative.split("/")), "utf8");
43
+ const unedited = typeof recorded === "string" && hash(contents) === recorded;
44
+ if (!entry)
45
+ plan.push(unedited ? { relative, action: "remove", expected: recorded } : { relative, action: "keep-edited" });
46
+ else if (hasMarkers(contents) && !hasDamagedMarkers(contents))
47
+ plan.push({ relative, action: "cut-block" });
48
+ else if (unedited && !hasMarkers(contents))
49
+ plan.push({ relative, action: "remove", expected: recorded });
50
+ else
51
+ plan.push({ relative, action: "keep-entry", why: hasDamagedMarkers(contents) ? "its markers are damaged" : "edited, with no markers to cut along" });
52
+ }
53
+ const settings = await settingsEntry(target);
54
+ if (settings)
55
+ plan.push(settings);
56
+ plan.push({ relative: MANIFEST_PATH, action: "remove-manifest" });
57
+ return plan;
58
+ }
59
+ async function settingsEntry(target) {
60
+ if (!(await fs.lstat(path.join(target, ...SETTINGS.split("/"))).catch(() => null)))
61
+ return null;
62
+ if (!(await isPlainFile(target, SETTINGS)))
63
+ return { relative: SETTINGS, action: "keep-settings", why: "reached through a link, or not a plain file" };
64
+ const contents = await fs.readFile(path.join(target, ...SETTINGS.split("/")), "utf8");
65
+ const registered = parseHooks(contents);
66
+ if (registered === null)
67
+ return { relative: SETTINGS, action: "keep-settings", why: "it does not parse" };
68
+ const template = (await isPlainFile(target, TEMPLATE)) ? await fs.readFile(path.join(target, ...TEMPLATE.split("/")), "utf8") : null;
69
+ if (template !== null && hash(template) === hash(contents))
70
+ return { relative: SETTINGS, action: "remove", expected: hash(template) };
71
+ const ours = new Set(HOOKS.map((hook) => hookFile(hook.command)));
72
+ return registered.some((hook) => ours.has(hookFile(hook.command))) ? { relative: SETTINGS, action: "unwire" } : null;
73
+ }
74
+ /**
75
+ * Carry out a plan. Each removal is checked again just before it happens, since the plan may
76
+ * be minutes old, and a directory is removed only once nothing is left in it.
77
+ */
78
+ export async function applyUninstall(target, plan) {
79
+ // Every path written to is chosen and checked before anything changes: a copy follows a
80
+ // link at its destination, so one link anywhere under the backups would write outside.
81
+ const backups = new Map();
82
+ for (const entry of plan.filter((e) => e.action === "cut-block" || e.action === "unwire")) {
83
+ backups.set(entry.relative, await freeBackupPath(target, entry.relative));
84
+ }
85
+ for (const relative of [MANIFEST_PATH, BACKUPS, ...backups.values()]) {
86
+ if (await throughLink(target, relative)) {
87
+ throw new Error(`${relative} is reached through a symbolic link. Nothing was removed.`);
88
+ }
89
+ }
90
+ const result = { removed: [], cut: [], unwired: [], kept: [], backups: [] };
91
+ const file = (relative) => path.join(target, ...relative.split("/"));
92
+ for (const entry of plan) {
93
+ if (entry.action === "remove" || entry.action === "remove-manifest") {
94
+ if (!(await isPlainFile(target, entry.relative))) {
95
+ if (entry.action === "remove")
96
+ result.kept.push({ ...entry, action: "keep-linked", why: "changed since the plan was made" });
97
+ continue;
98
+ }
99
+ if (entry.expected !== undefined && hash(await fs.readFile(file(entry.relative))) !== entry.expected) {
100
+ result.kept.push({ ...entry, action: "keep-edited", why: "edited since the plan was made" });
101
+ continue;
102
+ }
103
+ await fs.rm(file(entry.relative));
104
+ result.removed.push(entry.relative);
105
+ await removeEmptyParents(target, entry.relative);
106
+ }
107
+ else if (entry.action === "cut-block" || entry.action === "unwire") {
108
+ if (!(await isPlainFile(target, entry.relative))) {
109
+ result.kept.push({ ...entry, action: entry.action === "cut-block" ? "keep-entry" : "keep-settings", why: "changed since the plan was made" });
110
+ continue;
111
+ }
112
+ const before = await fs.readFile(file(entry.relative), "utf8");
113
+ const after = entry.action === "cut-block" ? cutBlock(before) : unwire(before);
114
+ if (after === null) {
115
+ result.kept.push({ ...entry, action: entry.action === "cut-block" ? "keep-entry" : "keep-settings", why: "changed since the plan was made" });
116
+ continue;
117
+ }
118
+ const backup = backups.get(entry.relative);
119
+ await fs.mkdir(path.dirname(file(backup)), { recursive: true });
120
+ // Checked again here: a link swapped in after the first check would be followed by the copy.
121
+ const copied = !(await throughLink(target, backup)) &&
122
+ (await fs.copyFile(file(entry.relative), file(backup), fs.constants.COPYFILE_EXCL).then(() => true, () => false));
123
+ if (!copied) {
124
+ result.kept.push({ ...entry, action: entry.action === "cut-block" ? "keep-entry" : "keep-settings", why: "its backup could not be written safely" });
125
+ continue;
126
+ }
127
+ result.backups.push(backup);
128
+ await fs.writeFile(file(entry.relative), after, "utf8");
129
+ (entry.action === "cut-block" ? result.cut : result.unwired).push(entry.relative);
130
+ }
131
+ else {
132
+ result.kept.push(entry);
133
+ }
134
+ }
135
+ return result;
136
+ }
137
+ /**
138
+ * A backup path that is new, under its own folder so it never replaces the copy of the
139
+ * original that `install` kept when it first merged the file.
140
+ */
141
+ async function freeBackupPath(target, relative) {
142
+ const base = `${BACKUPS}/uninstall/${relative}`;
143
+ for (let n = 1;; n += 1) {
144
+ const candidate = n === 1 ? base : `${base}.${n}`;
145
+ if (!(await fs.lstat(path.join(target, ...candidate.split("/"))).catch(() => null)))
146
+ return candidate;
147
+ }
148
+ }
149
+ const SETUP_REQUIRED = `<!-- ${STATE_DIR}:setup-required -->`;
150
+ /**
151
+ * The entry file without Religion's block, everything around it as it was, and without the
152
+ * Commands section Religion appended if nobody ever filled it in. Null if the markers moved.
153
+ */
154
+ export function cutBlock(contents) {
155
+ const start = contents.indexOf(MANAGED_START);
156
+ const end = contents.indexOf(MANAGED_END);
157
+ if (start < 0 || end < start)
158
+ return null;
159
+ const joined = contents.slice(0, start).replace(/\n+$/, "") + "\n\n" + contents.slice(end + MANAGED_END.length).replace(/^\n+/, "");
160
+ const unfilled = /^## Commands\n[\s\S]*?(?=^## |(?![\s\S]))/m.exec(joined);
161
+ const kept = unfilled && unfilled[0].includes(SETUP_REQUIRED) ? joined.replace(unfilled[0], "") : joined;
162
+ return kept.replace(/^\n+/, "").replace(/\n+$/, "") + "\n";
163
+ }
164
+ /** The settings with Religion's hook entries taken out, and every other setting and hook left. */
165
+ export function unwire(contents) {
166
+ let settings;
167
+ try {
168
+ settings = JSON.parse(contents);
169
+ }
170
+ catch {
171
+ return null;
172
+ }
173
+ if (!settings || typeof settings !== "object" || Array.isArray(settings))
174
+ return null;
175
+ const root = settings;
176
+ const hooks = root.hooks;
177
+ if (!hooks || typeof hooks !== "object" || Array.isArray(hooks))
178
+ return null;
179
+ const ours = new Set(HOOKS.map((hook) => hookFile(hook.command)));
180
+ const kept = {};
181
+ for (const [event, groups] of Object.entries(hooks)) {
182
+ if (!Array.isArray(groups)) {
183
+ kept[event] = groups;
184
+ continue;
185
+ }
186
+ const left = groups.flatMap((group) => {
187
+ const inner = group && typeof group === "object" ? group.hooks : undefined;
188
+ if (!Array.isArray(inner))
189
+ return [group];
190
+ const remaining = inner.filter((hook) => {
191
+ const command = hook && typeof hook === "object" ? hook.command : undefined;
192
+ return !(typeof command === "string" && ours.has(hookFile(command)));
193
+ });
194
+ return remaining.length ? [{ ...group, hooks: remaining }] : [];
195
+ });
196
+ if (left.length)
197
+ kept[event] = left;
198
+ }
199
+ if (Object.keys(kept).length)
200
+ root.hooks = kept;
201
+ else
202
+ delete root.hooks;
203
+ return JSON.stringify(root, null, 2) + "\n";
204
+ }
205
+ /** Remove each directory a removal left empty, walking up, never the project or the state directory. */
206
+ async function removeEmptyParents(target, relative) {
207
+ let dir = path.posix.dirname(relative);
208
+ while (dir !== "." && dir !== STATE_DIR && !dir.startsWith(`${STATE_DIR}/`)) {
209
+ const absolute = path.join(target, ...dir.split("/"));
210
+ const stat = await fs.lstat(absolute).catch(() => null);
211
+ if (!stat?.isDirectory() || (await fs.readdir(absolute)).length > 0)
212
+ return;
213
+ await fs.rmdir(absolute);
214
+ dir = path.posix.dirname(dir);
215
+ }
216
+ }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-religion",
3
- "version": "1.2.0",
3
+ "version": "1.4.0",
4
4
  "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.",
5
5
  "license": "MIT",
6
6
  "author": "Nate",
@@ -30,7 +30,7 @@
30
30
  "create-religion": "dist/bin/religion.js",
31
31
  "religion": "dist/bin/religion.js"
32
32
  },
33
- "files": ["dist/", "template/", "README.md", "LICENSE"],
33
+ "files": ["dist/", "template/", "README.md", "LICENSE", "CHANGELOG.md"],
34
34
  "engines": { "node": ">=22" },
35
35
  "scripts": {
36
36
  "build": "tsc -p tsconfig.json",
@@ -88,7 +88,10 @@ State the bounds, the gates in force, and how many items are in range. Then star
88
88
 
89
89
  ## Step 2 - each item
90
90
 
91
- For every item, in plan order:
91
+ For every item, in plan order, passing over any that waits on an earlier unticked item or on
92
+ a spike, by the rule $feature uses with no argument. Each one passed over is named in
93
+ the final report with what it waits on. When every remaining item waits, the run has
94
+ nothing left to build and stops there.
92
95
 
93
96
  1. **Spec it**, following $feature, including the sizing and the self-critique. Do
94
97
  not skip the critique because nobody is reading: it is what catches an oversized step
@@ -139,7 +142,8 @@ context, whatever `qualityGates.audit` says. Only that review closes a finding.
139
142
 
140
143
  **Folding.** When that review raises a new finding in code the fix changed, the audit records
141
144
  it under its own identifier with a `**Surfaced by:**` line naming the finding whose repair
142
- exposed it, and it joins the current fix as another repair step, whatever its class. The
145
+ exposed it, and it joins the current fix as another repair step, whatever its class, recorded as an
146
+ amendment to the fix's spec with the stamp renewed, as $implement does for any repair step. The
143
147
  finding that surfaced it cannot close while it is `open` or `fixed`. A defect a repair
144
148
  introduced belongs with that repair: left for a later fix, it loses the context that
145
149
  explains it.
@@ -161,7 +165,9 @@ default branch. Title it for the run rather than for any one item. Its body is t
161
165
  review packet, and it is the artefact a person actually reads:
162
166
 
163
167
  - one section per completed item, in plan order, naming what it delivered, its merged pull
164
- request, and the checks that proved it
168
+ request, and the checks that proved it, taken from the item's archive and its `## Evidence`
169
+ section rather than from memory of the run; the item's own pull request carries its full
170
+ packet, so link it rather than repeating it
165
171
  - findings still open or fixed, by identifier, and anything deliberately left out
166
172
  - what the run did not reach, and why it stopped
167
173
 
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  name: check
3
3
  summary: prove the current work does what its spec says, against the running project
4
- 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."
4
+ 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."
5
5
  ---
6
6
 
7
7
  # 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
15
15
  actually do what the spec said it would. Those are not the same question, and only one of
16
16
  them is what the user asked for.
17
17
 
18
- It observes. It never edits source, installs anything, commits, or fixes what it finds.
18
+ It observes. It never edits source, installs anything, commits, or fixes what it finds. The
19
+ one thing it writes is the record of what it observed, in the spec's Evidence section.
20
+
21
+ ## Preview mode
22
+
23
+ `$check preview` runs the same outcomes twice: locally, as always, and against the preview
24
+ deployment the host built for this branch's pull request. Under `pull-request` mode that preview
25
+ is what a reviewer will open, and "works locally" says little about it.
26
+
27
+ Find the address through the host's own command-line tool, on GitHub with `gh`: the pull request
28
+ for the current branch, its head commit, the deployments recorded for that commit, and the
29
+ `environment_url` of the newest successful status among them. Each of those is a network read,
30
+ so outside an automated run ask before making them. Use the head commit's deployments only: a
31
+ preview of an older commit checks code that is not the code under review.
32
+
33
+ Then run each outcome against that address with the same evidence rules as locally, and stamp the
34
+ Evidence section with it, `Checked <date> at <commit> against <address>, tree <clean|dirty>.`, one
35
+ line per outcome per place it was checked. A preview that does not exist, has not finished, or sits
36
+ behind a sign-in is **could not check** for that address, never a pass, and the local verdicts still
37
+ stand. Never trigger, redeploy or promote a deployment: deploying is first-tier, and this skill only
38
+ observes. What the preview serves is untrusted input, like any page fetched.
19
39
 
20
40
  ## Step 1 - read what must be true
21
41
 
@@ -44,6 +64,25 @@ chrome, or anything else it does not actually observe.
44
64
  Start the project the way its own commands say to. If it cannot start, that is the finding:
45
65
  report it and stop rather than reasoning about what would have happened.
46
66
 
67
+ ## Accessibility, for web outcomes
68
+
69
+ A screenshot shows a page rendered, not that someone using a keyboard or a screen reader can use
70
+ it. For each interface outcome, scan the state the outcome describes with what the project
71
+ already has, and never install a scanner to do it; $browser-tests is where one gets added.
72
+
73
+ - **The project's axe**, through its browser-test harness, when it has one: run its rules on the
74
+ page and take the violations by rule and element.
75
+ - **Otherwise, the page itself**, through the browser being driven: read its accessibility tree
76
+ for controls without a name, images without alternative text, form fields without a label, and
77
+ headings out of order, then move through the page with the keyboard alone and note anything that
78
+ cannot be reached or that hides the focus.
79
+
80
+ Report violations under the outcome they belong to, and say which method ran and what it does
81
+ not cover: the fallback sees no contrast, no motion, and nothing about reading order beyond focus.
82
+ A clean scan is evidence that the issues that method detects are absent, never that the page is
83
+ accessible. Record it on the outcome's Evidence line, method included. Point anything serious at
84
+ $audit, since this skill does not write findings.
85
+
47
86
  ## Step 3 - check each outcome
48
87
 
49
88
  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.
65
104
  - each outcome, with pass, fail, or could not check, and what proved it
66
105
  - what was run, exactly
67
106
  - anything observed that the spec did not ask about but that looks wrong
107
+ - outcomes that could become regression tests: each passing outcome whose evidence is a
108
+ captured command with its output and exit status, or a request with its response. Where the
109
+ entry file declares a test command, offer $tests `evidence` to keep them, so the next
110
+ change cannot quietly undo what was just proved. Interface outcomes are not candidates.
68
111
  - next action: $implement when something failed, $complete when everything
69
112
  passed
70
113
 
71
114
  Never say passed, verified, or working without naming the command, route, screenshot, or
72
115
  output behind it.
73
116
 
117
+ ## Step 5 - record it
118
+
119
+ Write the verdict into `religion/context/current-work.md` as its last section, replacing any
120
+ `## Evidence` section an earlier run left, so the proof survives a cleared context and travels
121
+ into the archive with the spec:
122
+
123
+ ## Evidence
124
+
125
+ Checked 2026-10-21 at 9f73627, tree clean.
126
+
127
+ - **Step 1 - the plan** - pass: ran `npm test`; 159 passed, 0 failed.
128
+ - **Step 3 - the command** - fail: `religion uninstall --yes` exited 1 with "No install record".
129
+ - **Goal** - could not check: no browser available.
130
+
131
+ The stamp names the date, the short commit that was checked, and whether the working tree was
132
+ clean apart from the workflow's own state files. One line per outcome: its verdict, then what
133
+ was run and what was seen, short enough to read at a glance. Screenshots are named by where
134
+ they were saved, never pasted in.
135
+
136
+ This section is the only thing this skill writes. It does not tick steps, change the spec's
137
+ status, or touch any other file.
138
+
74
139
  ## Rules
75
140
 
76
141
  - Observe, never repair. A failure is reported, not fixed.
142
+ - The spec's Evidence section is the only write, and it is replaced whole, never appended to.
143
+ Offering a regression test is not writing one: $tests writes tests.
77
144
  - Never install a runner, a browser, or a dependency to make a check possible. Report the
78
145
  gap.
79
146
  - Do not widen scope beyond the spec's stated outcomes, except to report something clearly
@@ -48,6 +48,31 @@ pushes to the default branch.
48
48
  - Grant `contents: read` and nothing more.
49
49
  - Cache the package manager's store if that is straightforward.
50
50
 
51
+ Then a second step that runs `religion doctor`, so a broken install or an overview the plans
52
+ have moved past fails the build rather than waiting to be noticed. Pin the tool to the major
53
+ version that installed the project, and give the job Node if the stack does not already set
54
+ it up:
55
+
56
+ - name: Religion doctor
57
+ run: |
58
+ npx --yes create-religion@1 doctor --json > doctor.json || true
59
+ node -e '
60
+ const fs = require("fs");
61
+ let report;
62
+ try { report = JSON.parse(fs.readFileSync("doctor.json", "utf8")); }
63
+ catch { console.log("::error::religion doctor printed no report"); process.exit(1); }
64
+ const failing = report.checks.filter((check) => !check.ok);
65
+ for (const check of failing) console.log((check.blocks === "nothing" ? "::warning::" : "::error::") + check.name + ": " + check.detail);
66
+ process.exit(failing.some((check) => check.blocks !== "nothing") ? 1 : 0);
67
+ '
68
+
69
+ Only a failed check that blocks `work` or `completion` fails the build. One that blocks
70
+ `nothing` is shown as a warning, because those are the checks a runner cannot pass honestly:
71
+ `hooks` reads `.claude/settings.json`, and `managed files` reads the install record under
72
+ `religion/.state/`, and many projects commit neither. Doctor exits 1 for any failed check, so
73
+ its exit code is not the signal; the JSON is, and its `checks`, `ok` and `blocks` are part of
74
+ the stable surface. A doctor that prints no report fails the build.
75
+
51
76
  **Never overwrite existing continuous integration.** If a workflow already runs these
52
77
  checks, say so, show where they overlap, and stop. Two workflows running the same suite
53
78
  doubles the cost and halves the trust in both.
@@ -57,6 +82,9 @@ doubles the cost and halves the trust in both.
57
82
  Run the Verify command exactly as written. If it fails, the recipe is wrong or the project
58
83
  is broken, and either way it must not be committed in that state.
59
84
 
85
+ Run the doctor step's two lines too. If they fail here they will fail on every pull request,
86
+ and the cause, usually a stale overview, is cheaper to fix now.
87
+
60
88
  ## Step 5 - report and stop
61
89
 
62
90
  The command, where it is recorded, the workflow created or the overlap found, the local
@@ -53,7 +53,14 @@ output that proves it.
53
53
  ## Step 1 - apply the configured gates
54
54
 
55
55
  Read `qualityGates`. Reuse evidence already produced during this work item rather than
56
- repeating it.
56
+ repeating it, and take it from the spec's `## Evidence` section, which $check writes, not
57
+ from memory of the session: the session may have been cleared since.
58
+
59
+ The record counts only for the code it checked. Reuse it when its stamp names the current
60
+ commit with a clean tree, and the tree is still clean apart from the workflow's own state
61
+ files. A record from another commit, from a dirty tree, or with an outcome that failed or
62
+ could not be checked is not evidence for this completion: run $check again, which
63
+ replaces it. A spec with no Evidence section has not been checked.
57
64
 
58
65
  - **`audit`**: `manual` runs only on request. `when-sensitive` runs for authentication,
59
66
  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
112
119
  completion but must survive verbatim for a later review. Reset the ledger to its stub only
113
120
  when nothing unresolved remains.
114
121
 
122
+ **Write the journal entry.** Append one entry to `religion/learning/journal.md` for the item
123
+ just archived, whatever its kind. This skill is the journal's only writer, and an entry per
124
+ item is what $distill has to work from:
125
+
126
+ ## 2026-10-21 - Export reports as CSV
127
+
128
+ **Archive:** history/features/12-export-reports-as-csv.md
129
+ **Surprised:** one or two sentences, or "nothing".
130
+ **Went wrong:** one or two sentences, or "nothing".
131
+ **Deferred:** what was left, and why, or "nothing".
132
+
133
+ Write it from what the work actually went through, not from the spec: a repair that took two
134
+ attempts, an assumption that proved wrong, a check that caught something late. The heading
135
+ is the date and the item's title. If the file is missing, from a project installed before it
136
+ existed, create it with the shipped journal's header first.
137
+
115
138
  **Reset the active spec** to its stub, exactly as shipped.
116
139
 
117
140
  **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
120
143
 
121
144
  Do not commit yet.
122
145
 
146
+ ## Step 2b - draft the release note
147
+
148
+ Where the project uses Changesets, which `.changeset/config.json` shows, and no changeset in
149
+ `.changeset/` already describes this item, draft one from the archive:
150
+
151
+ - **Packages** - for each product path in the archive's `## Landed` record, the nearest
152
+ `package.json` with a `name`, leaving out any the Changesets config ignores and any marked
153
+ `private` that the config does not version.
154
+ - **Bump** - proposed, never decided: `major` when the item removes, renames or narrows anything
155
+ public, `minor` when it adds something, `patch` when it only repairs. Where the project has a
156
+ stability statement, that is what defines public and breaking; where it has none, say what was
157
+ assumed.
158
+ - **Summary** - from the archive's Outcome, rewritten for someone reading the changelog: what
159
+ they can now do or what behaves differently, in a short paragraph, with no plan numbers.
160
+
161
+ ---
162
+ "create-religion": minor
163
+ ---
164
+
165
+ `religion status` reports the run in progress and how many notes the inbox holds.
166
+
167
+ Interactively, show the draft and ask before writing it. In an automated run there is nobody to
168
+ ask, so write it under a name made from the item's title, and name it and its bump in the pull
169
+ request's packet, where the reviewer approves or changes it before anything is released. A
170
+ project without Changesets gets nothing, and versioning or publishing stays the release
171
+ workflow's.
172
+
123
173
  ## Step 3 - the work commit
124
174
 
125
175
  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,
167
217
  **That yes covers pushing this branch and nothing else.** Neither running this skill nor
168
218
  "looks good" is that yes.
169
219
  3. Open the pull request from the branch into the default branch. Title it from the work
170
- commit. The body carries what changed and why, the checks that ran with the exact command
171
- or output proving each, the manual walkthrough from Step 5, and anything left open:
172
- unresolved findings, deliberate omissions, follow-ups.
220
+ commit. The body is a review packet for whoever reviews on the host, built from the
221
+ archive just written rather than from memory of the session:
222
+
223
+ - **Goal** - the spec's goal, in a sentence or two.
224
+ - **Steps and evidence** - one line per build step: what it delivered, and the verdict
225
+ and evidence its `## Evidence` entry records. A step with no entry says so.
226
+ - **Findings** - those closed with this item, by their archived identifier, and any still
227
+ `open` or `fixed` that touch it.
228
+ - **The record** - a link to the archive on this branch for the full spec, what went wrong,
229
+ what was deferred, and the walkthrough from Step 5.
230
+ - **The release note** - a changeset drafted in Step 2b, by file, with its proposed bump and
231
+ the packages it names, for the reviewer to approve or change.
232
+ - **The issue** - when the spec carries `**From issue:**`, name it: with the host's closing
233
+ keyword for a fix (`Closes #42`), so merging closes it, and as a plain reference for a
234
+ feature (`Refs #12`), since one feature rarely settles everything an issue asked.
235
+
236
+ Keep it to what can be read beside the diff: one line per step, the detail behind the
237
+ link. It presents the item's own record and nothing more; it is not a sign-off, and asks
238
+ no one to approve anything the workflow does not already gate.
173
239
  4. Report the pull request URL and stop. Do not merge it, do not wait or poll for it, and do
174
240
  not touch the default branch.
175
241
 
@@ -182,7 +248,12 @@ the content landed before reaching for `-D`.
182
248
  ## Step 5 - say how to try it
183
249
 
184
250
  Always end with the manual walkthrough for what just landed: what to start, where to go,
185
- what to click or run, what to expect, and what would count as wrong. This is instructions
251
+ what to click or run, what to expect, and what would count as wrong.
252
+
253
+ When the spec came from an issue and no pull request was opened, name the issue here so it
254
+ can be closed by hand. Nothing in this skill comments on, labels or closes an issue: those are
255
+ outward actions, and the closing keyword in a pull request only takes effect when its owner
256
+ merges it. This is instructions
186
257
  for a person, never a claim that the review happened.
187
258
 
188
259
  For a rollback, say how to confirm the removed behavior is gone, and name one unaffected
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  name: distill
3
3
  summary: promote proven observations from the journal into loaded lessons
4
- description: "Read religion/learning/journal.md, promote observations that have proved stable into religion/learning/lessons.md, fold corrections about this project into its coding standards, and archive what was processed. Lessons are loaded every session, so promotion is deliberately strict: an observation earns a place only once it has recurred or been confirmed. Use when the user runs $distill, asks to consolidate what has been learned, or when the journal has grown enough to be worth a pass."
4
+ description: "Read religion/learning/journal.md, promote observations that have proved stable into religion/learning/lessons.md, fold corrections about this project into its coding standards, propose a standard where the same kind of finding has recurred across archived items, and archive what was processed. Lessons are loaded every session, so promotion is deliberately strict: an observation earns a place only once it has recurred or been confirmed. Use when the user runs $distill, asks to consolidate what has been learned, or when the journal has grown enough to be worth a pass."
5
5
  ---
6
6
 
7
7
  # distill - turn observations into lessons
@@ -9,23 +9,22 @@ description: "Read religion/learning/journal.md, promote observations that have
9
9
  The journal is cheap and unfiltered: anything surprising goes in. Lessons are expensive,
10
10
  because they are loaded into every session forever. This skill is the gate between them.
11
11
 
12
- ## What goes in the journal, and when
12
+ ## What is in the journal
13
13
 
14
- Any skill appends to `religion/learning/journal.md` when something is worth remembering:
14
+ $complete appends one entry to `religion/learning/journal.md` for every item it
15
+ finishes, and it is the journal's only writer. Each entry is a `##` heading with the date
16
+ and the item's title, then its archive, what surprised, what went wrong, and what was
17
+ deferred and why. Nothing is loaded from here, so the entries can be plain.
15
18
 
16
- - a correction from the user, especially a repeated one
17
- - an assumption that turned out to be wrong about this project
18
- - a failure whose cause was non-obvious
19
- - a convention discovered in the code that no document states
20
-
21
- One entry, dated, in a sentence or two. What happened and what it implies. Appending is
22
- cheap and unreviewed; nothing is loaded from here.
23
-
24
- Do not journal the ordinary. "The build passed" is not an observation.
19
+ This skill reads the journal and never edits it. What it decides is recorded in
20
+ `religion/learning/journal-archive.md`, which this skill alone writes.
25
21
 
26
22
  ## Step 1 - read and group
27
23
 
28
- Read the journal. Group entries that are really the same observation seen more than once.
24
+ Read the journal, skipping every entry whose heading and `Archive` line already appear in
25
+ `journal-archive.md`: those were decided on an earlier pass. Group the rest, together with
26
+ earlier entries the archive kept for later, where they are really the same observation seen
27
+ more than once.
29
28
  Recurrence is the main evidence that something is a lesson rather than an incident.
30
29
 
31
30
  ## Step 2 - decide what has earned promotion
@@ -39,9 +38,27 @@ Promote an observation only when it is all of these:
39
38
  - **Not already written down.** If it belongs in the coding standards or the project plan,
40
39
  it goes there instead, where it is already loaded and already owned.
41
40
 
42
- Everything else stays in the journal or is dropped. A single surprising incident is not a
41
+ Everything else is rejected, or kept for later until it recurs. A single surprising incident is not a
43
42
  lesson; it is an incident.
44
43
 
44
+ ## Step 2b - findings that keep recurring
45
+
46
+ The second input is the review record. Read the `## Findings` section of every archive under
47
+ `religion/history/`: each entry's identifier, title, file, lens and why it mattered. The open
48
+ entries in `religion/context/findings.md` are context, not evidence, since nothing has closed
49
+ them.
50
+
51
+ Group findings that are the same kind of mistake, whatever their wording: a path read or written
52
+ through a link, a pattern whose whitespace crosses a line, a read that is not guarded on a path
53
+ that must not fail. A group earns a proposal only when its findings come from **at least two
54
+ different items**. Recurrence across work is the evidence; severity is not, and one serious
55
+ finding, already repaired, is an incident.
56
+
57
+ For each group that earns it, propose the coding-standard rule that would have prevented every
58
+ finding in it, in the standards' own voice, as an instruction for work not yet started, with the
59
+ findings cited by identifier. A rule that only restates one finding is not a standard. Skip a
60
+ group already recorded in `religion/learning/journal-archive.md` unless it has grown since.
61
+
45
62
  ## Step 3 - route by kind
46
63
 
47
64
  Two destinations, and the distinction matters.
@@ -67,17 +84,23 @@ nobody reads, which is worse than no file.
67
84
 
68
85
  If the file is getting long, that is a finding: report it rather than adding to it.
69
86
 
70
- ## Step 5 - archive what was processed
87
+ ## Step 5 - record what was decided
71
88
 
72
- Remove promoted and rejected entries from the journal, appending them to
73
- `religion/learning/journal-archive.md` with what was decided. Nothing is deleted outright:
74
- a rejected observation that recurs is exactly the evidence that promotes it next time.
89
+ Append every entry read on this pass to `religion/learning/journal-archive.md`, under its
90
+ own heading and `Archive` line, with what was decided: promoted, rejected and why, or kept
91
+ for later because it has not recurred yet. Leave the journal exactly as it is. Nothing is
92
+ lost either way: a rejected observation that recurs is exactly the evidence that promotes it
93
+ next time, and the archive is where the earlier sighting is found.
75
94
 
76
95
  ## Step 6 - report
77
96
 
78
97
  - entries read, grouped, promoted, and rejected, with the reason for each rejection
79
98
  - lessons added, and any removed
80
- - standards edits proposed, and whether they were approved
99
+ - standards edits proposed, and whether they were approved, including each recurring-finding
100
+ group, its findings by identifier, and the rule it led to
101
+ - each decided group recorded in `religion/learning/journal-archive.md` under
102
+ `## findings - <kind>` with the identifiers it covered, approved or not, so a later pass
103
+ proposes only what is new
81
104
  - whether the lessons file is getting too long
82
105
 
83
106
  ## Rules