create-agent-rig 0.10.0 → 1.0.0

package/templates/agent-os/universal/.claude/skills/loop/SKILL.md

@@ -420,7 +420,11 @@ who was not reading the code at the time, and everything downstream — the fail
 test, the implementation, the reviewer comparing diff to item — inherits its
 claims rather than checking them. On `PREMISE FALSE` the item is escalated (§6),
 not repaired in place: a run that silently re-aims its own task has authored work
-for itself, which is the one thing this loop does not do (§8).
+for itself, which is the one thing this loop does not do (§8). A claim
+`check-premises` cannot settle by reading — a claimed defect or a historical
+finding that needs reproducing on the current default branch, not just re-reading — goes to
+`failure-diagnostician` in claim mode instead, never to an unnamed built-in
+subagent.
 
 🔴 **And again at the other end, before `pr-ship`: `check-premises` on the prose the
 task itself wrote** — the rulebook prose the diff touches (the skill defines that set,
@@ -703,7 +707,23 @@ Both then follow the same three steps:
    its clauses: what was *observed* (verbatim errors, not summaries), and the
    single question whose answer unblocks the work. So: what fails, what was tried, the
    current hypothesis, and links to the PR and the failing run where they exist
-   — a premise stop has neither, and its citation stands in for both. **Name the outcome
+   — a premise stop has neither, and its citation stands in for both.
+   **For a red check or an unexplained failure, the current hypothesis is the
+   diagnostician's parsed verdict**: dispatch `failure-diagnostician` with the
+   verbatim failure, save its answer to a file under the run directory, and
+   check it —
+
+   ```sh
+   node .claude/scripts/verdict.mjs check <report> failure-diagnostician
+   ```
+
+   — then carry the parsed verdict (word, `classification`, blockers,
+   evidence) as the hypothesis instead of writing the diagnosis from scratch,
+   with the verbatim failure output still in the comment beside it, covering
+   the "observed" clause the list above already names. A `PREMISE FALSE` or
+   exhausted-cap stop keeps the diagnosis the paragraph above already
+   describes (what the item claimed, or the round count).
+   **Name the outcome
    state in the same comment** — `incomplete` if the diagnosis cannot say **where** it
    stopped (§5: a thin diagnosis that still locates the wall is a `documented-stall`).
    Writing `incomplete` on your own task is uncomfortable and
@@ -847,29 +867,52 @@ four things, and a proposal missing any of them is not ready to file:
 3. the change, concretely enough to diff;
 4. how the next run would prove it worked — the observation that would differ.
 
-Filing is the adapter's `proposeTriage`, which the CLI deliberately does **not**
-expose — `index.mjs` never writes to the QUEUE (`next`, `list`, `hygiene` only), so
-that no accidental invocation can change what the next run is handed. Its one
-write is to the run journal above, and only into a directory the run declared —
-a trace of the selection, never a change to it. Call `proposeTriage` directly:
+Filing is the adapter's `proposeTriage`, reached through the one root-safe entry
+point `.claude/scripts/queue/propose.mjs` — never a relative `import()` typed by
+hand, which breaks the moment the session is standing in a subdirectory
+(`ERR_MODULE_NOT_FOUND` from the import, then an `ENOENT` from a cwd-relative
+`PLAN.md` that is not there). The CLI (`index.mjs`) still deliberately does
+**not** expose this — it never writes to the QUEUE (`next`, `list`, `hygiene`
+only), so that no accidental invocation can change what the next run is
+handed. `propose.mjs` resolves its config from its own location, exactly as
+`index.mjs` does, so the proposal lands in the project's real PLAN.md (or
+tracker) and the active board's own options travel with it rather than being
+typed by hand. Write the proposal to a file under the run directory, then run
+the script:
 
 ```bash
 node --input-type=module -e '
-  const a = await import("./.claude/scripts/queue/plan-md.mjs");   // or github-issues / jira
-  console.log(await a.proposeTriage({
-    finding: "<the journal line it came from>",
-    part:    "<skill | agent | hook | rule | AGENTS.md | CLAUDE.md | workflow>",
-    change:  "<concretely enough to diff>",
-    proof:   "<the observation that would differ next run>",
-    // a pair: what the probe touched, and what is concluded from it. The
-    // mechanism accepts a proposal without them; this procedure does not.
-    measured: "<the paths the probe actually exercised>",
-    inferred: "<the conclusion, citing only surfaces named in measured>",
-  }, { project: "<KEY>" }));   // jira only — the ACTIVE board's key: `queue/index.mjs board --json` → options.project;
-                               // plan-md and github-issues take no second argument
+  const fs = await import("node:fs/promises");
+  await fs.writeFile(
+    `${process.env.RIG_RUN_DIR}/proposal.json`,
+    JSON.stringify({
+      finding: "<the journal line it came from>",
+      part:    "<skill | agent | hook | rule | AGENTS.md | CLAUDE.md | workflow>",
+      change:  "<concretely enough to diff>",
+      proof:   "<the observation that would differ next run>",
+      // a pair: what the probe touched, and what is concluded from it. The
+      // mechanism accepts a proposal without them; this procedure does not.
+      measured: "<the paths the probe actually exercised>",
+      inferred: "<the conclusion, citing only surfaces named in measured>",
+    }),
+  );
 '
+# Root-anchored so the same command works whether the session is standing
+# at the repo root or in a subdirectory. Pinned in the generator's
+# test/template/loop-report-file.test.ts (absent in a generated rig) ›
+# "files when the documented command line runs, unmodified, from a project
+# subdirectory".
+node "$(git rev-parse --show-toplevel)/.claude/scripts/queue/propose.mjs" --file "$RIG_RUN_DIR/proposal.json"
 ```
 
+The result prints as one JSON line on stdout, and — because `RIG_RUN_DIR` is
+declared — the same result is also recorded as a `proposal` event in the run
+journal, so a failed filing is journalled as a failure instead of silently
+going nowhere. Pinned in the generator's `test/template/queue-propose.test.ts`
+(absent in a generated rig) › "files a proposal with a multiline finding from
+a project subdirectory, into the project-root PLAN.md" and › "journals a
+proposal event with ok: true on a successful filing under RIG_RUN_DIR".
+
 A proposal missing any of the four parts is refused rather than filed half-formed.
 
 **A finding can say what it measured and what it inferred, as two paired fields.**
@@ -920,9 +963,9 @@ rather than a step in the procedure: `plan-md` returns it when the plan file has
 no `## Operator queue` heading, because a proposal then has nowhere to land that
 the selection query cannot reach. Add the heading — never the Agent queue.
 
-One adapter needs the second argument the snippet above carries: `jira` requires
-`options.project` and throws rather than filing without it — loudly, so nothing
-is lost, but a call that drops it files nothing.
+`jira` still requires `options.project`, and still throws rather than filing
+without it — loudly, so nothing is lost — and there is no
+second argument left to hand-copy.
 
 🔴 **The loop proposes; the owner patches.** Self-applying a change to its own
 rulebook is how an unattended run drifts irreversibly, and it collides head-on

package/templates/agent-os/universal/.claude/skills/plan-slices/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: plan-slices
+description: Use when a task cannot be verified as one reviewable PR and splits into slices that are each independently verifiable on their own. Ships only with the opt-in workflow layer.
+allowed-tools: Read, Grep, Glob, Write, Edit
+---
+
+# Splitting a task into slices
+
+This applies when a task's change cannot be reviewed and verified as one PR,
+and decomposes into slices that are each independently verifiable — each
+slice stands on its own claim about behaviour, checked by its own test.
+
+Do not trigger it mechanically based on file or module count: a change
+that touches many files but makes one verifiable claim stays one PR, and a
+change touching few files but making several independent claims still
+splits.
+
+There is no planner role dispatched for this — the session writes the slice
+plan directly. For each slice, record:
+
+- the outcome the slice delivers, stated as a claim a test can check;
+- its own failing test, written by `test-writer` in the ordinary Red step;
+- the elevated paths it touches, if any (`AGENTS.md`'s elevated-paths block);
+- where it sits in the slice order, and what it depends on.
+
+Each slice then ships as its own PR through the ordinary flow —
+`.claude/rules/workflow.md` has the TDD cycle and the PR flow in full; this
+skill does not restate them.
+
+This skill ships only with the opt-in workflow layer.

package/templates/agent-os/universal/.claude/skills/pr-ship/SKILL.md

@@ -39,7 +39,7 @@ blockers.
      `test/template/gate-rounds.test.ts` — absent in a generated rig — ›
      "refuses to count a round on a dirty tree, and counts nothing".
 
-   The cap is **2 by default**, and no shipped `.claude/queue.json` carries the key
+   The cap is **3 by default**, and no shipped `.claude/queue.json` carries the key
    — the default lives in `core.mjs` as `DEFAULT_MAX_GATE_ROUNDS`. A project that
    wants a different cap sets `options.maxGateRounds` there, which in a rig whose
    `queue.json` is composed means changing what composes it, not editing the file.

package/templates/agent-os/universal/.claude/skills/release-propose/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: release-propose
+description: Use to turn repeated evidence from `release-evidence.mjs` into a bounded candidate-release proposal for the owner to decide. Ships only with the opt-in workflow layer.
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# Proposing a release from repeated pain
+
+## 1. What this is not
+
+The loop's own §7 improvement proposals are per-run fixes, filed and read one
+run at a time. This skill is different: a release-level proposal, built from
+evidence that recurred across more than one run, addressed to the owner —
+never to the queue, and never approved by the skill itself.
+
+## 2. Gather
+
+Run exactly:
+
+```sh
+node "$(git rev-parse --show-toplevel)/.claude/scripts/release-evidence.mjs" --since <date> --json
+```
+
+Read its `verdict`, `groups` and `why`. Optionally read
+`revalidation-report.mjs --json` the same way, the triage proposals already
+on file, and the tracker — cite every one of these by pointer (run id, file,
+seq, or ticket id), never from memory.
+
+## 3. Measured vs. inferred
+
+A number in the proposal is `measured` only when it came straight out of
+`release-evidence.mjs`'s JSON or a cited line of a run/ticket. Every other
+number or claim is labelled `inferred`, or `UNVERIFIED` when nothing backs it
+at all — never stated as if it were measured.
+
+## 4. Routing
+
+- `GATHER_MORE_EVIDENCE` — gather-more-evidence: name what evidence would decide it, file nothing, and stop — never build a candidate release out of anecdotes.
+- `REPEATED_PAIN` — write the proposal (§5) and hand it off (§6).
+
+## 5. Proposal template
+
+Write these headings, in order, into `$RIG_RUN_DIR/release-proposal.md`:
+
+- **Observed repeated pain** — the repeated groups, each with its pointers
+- **Candidate release** — the bounded scope this pain justifies
+- **Why now**
+- **Why not the alternatives** — including a required "Do nothing" row
+- **Dependencies** — proven only; nothing inferred here
+- **Scope / non-goals**
+- **Complexity** — small, medium or large, plus the maintenance burden it adds
+- **Evidence gaps** — what is still `inferred` or `UNVERIFIED`
+- **Upstream capability check** — could a native plugin, connector, MCP
+  server, CLI or provider feature do this instead: sufficient, insufficient
+  or rejected, and why
+- **Owner decision** — approve, reject or gather-more-evidence; left blank
+  for the owner to fill in, never pre-filled by this skill
+
+## 6. Hand-off
+
+- Write the proposal to `$RIG_RUN_DIR/release-proposal.md`.
+- File exactly ONE triage item, pointing at it:
+  `node "$(git rev-parse --show-toplevel)/.claude/scripts/queue/propose.mjs" --file <proposal.json>`
+  — finding = the repeated-pain groups by pointer; part = `"release"`;
+  change = `"candidate release: <one line>"`; proof = what the owner would
+  observe if the release lands.
+- A triage item filed this way is unselectable by the queue on its own;
+  promotion out of triage into selectable work is the owner's act, never
+  this skill's.
+- This skill never files a ticket in the selectable queue, never opens a
+  GitHub issue directly, and never edits PLAN.md's Agent queue: the Agent
+  queue is not something this skill touches, under any verdict.
+
+This skill ships only with the opt-in workflow layer.

package/templates/agent-os/universal/.claude/skills/skill-authoring/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: skill-authoring
+description: Use when authoring or editing a skill in this rig — a new SKILL.md under .claude/skills/, or a change to an existing one.
+allowed-tools: Read, Grep, Glob
+---
+
+# Authoring a skill
+
+No check in this rig runs on a skill you write here — the rules below are
+applied by the author, and by a reviewer reading this file, never by a
+mechanism. On the skills this rig itself ships, the generator's own
+`test/template/skill-authoring.test.ts` (absent in a generated rig) checks
+only the first rule, that a `description` is present, and that the skills and
+roles a skill names by name exist.
+
+- **The frontmatter `name` equals the directory name.** A skill loaded from
+  `.claude/skills/foo/` is named `foo`, not something else.
+- **The `description` says when to use the skill**, not just what it does.
+- **Keep it short, and point at existing rules or scripts rather than
+  restating them.** A skill that copies a rule's wording is a second copy
+  that goes stale the day the rule changes; link to `.claude/rules/` or a
+  script instead.
+- **Every sentence describing how a mechanism behaves either points at the
+  test that proves it, or is deleted.** `.claude/rules/invariants.md`,
+  "State the limits — and test them", is the norm; the form is `see <file>
+  (absent in a generated rig) › "<exact test name>"`.
+- **A mention of a workflow-layer skill or script in a Core document is
+  qualified "opt-in workflow layer"** — `loop` and `pr-ship` are examples,
+  not this skill's own concern.
+- **Both copies ship and must stay identical**: the Claude skill under
+  `.claude/skills/` and the Codex repository skill under `.agents/skills/`.
+  That mirror is checked in `test/template/codex.test.ts` (absent in a
+  generated rig) › "publishes every shared skill through the Codex
+  repository skill location" — not repeated here.
+
+## Out of scope
+
+This is guidance to apply by reading, not an evaluator: the skill itself has
+no procedure and checks nothing.

package/templates/agent-os/universal/.codex/agents/code-reviewer.toml

@@ -3,4 +3,4 @@ description = "Reviews a completed change against the checklist before a PR is o
 model = "gpt-5.6-sol"
 model_reasoning_effort = "high"
 sandbox_mode = "read-only"
-developer_instructions = "You review changes. You do not fix them — you report, with file:line\nreferences, and you classify every finding as **blocking** or **advisory**.\n\n## Checklist (blocking findings)\n\n1. **Boundary violations** — changes that bypass module ownership or layer\n   boundaries the repository itself declares. See any applicable architecture\n   rules in `.claude/rules/`.\n2. **Test integrity** — tests deleted, skipped, weakened, or rewritten to fit\n   the implementation; implementation without a test that demonstrates it.\n3. **Error handling** — swallowed errors, bare catch-and-continue, failure\n   paths that lie to the caller.\n4. **Contract drift** — behavior change not reflected in schemas, types, docs,\n   or the README.\n5. **Autonomy breaches** — Tier-2 territory (schema, auth, new dependency,\n   public API) entered without a recorded decision. See\n   `.claude/rules/autonomy.md`.\n6. **Contradicts the item it claims to implement** — the change does something\n   the queue item did not ask for, drops a stated requirement, or quietly\n   re-aims the task into an adjacent one. Read the item first, then the diff.\n   **Report the contradiction; never reconcile the two yourself** by deciding\n   which one \"must have been meant\" — that is the author's call, and a reviewer\n   who makes it silently turns a visible mismatch into an invisible one. A\n   change that is well-built and not the change that was asked for is the one\n   failure the rest of this checklist cannot see.\n\n   **If the item was not handed to you, say so and stop there.** Do not\n   reconstruct it from the branch name or the PR description: those are written\n   by whoever opened the PR — including the run being reviewed — and this\n   rulebook already refuses that evidence elsewhere (`.claude/rules/autonomy.md`).\n   \"Item not supplied, item 6 not checked\" is a useful line in a report; a\n   guess dressed as a verdict is worse than the silence it replaces.\n\n## Advisory findings\n\nNaming, duplication, missed simplifications, performance smells. Report them;\ndo not block on them.\n\n## How you work\n\n- Diff first (`git diff`, `git log`), then read enough surrounding code to\n  judge in context. Review what changed, not the whole repo.\n- Quote the checklist item a blocking finding violates. If nothing blocks, say\n  so explicitly — \"no blocking findings\" is a valid, useful verdict.\n- Do not request rewrites of working, tested code for style alone.\n\n## The verdict block\n\nWrite your report for the human, then end it with **exactly one** fenced `json`\nblock of this shape, and nothing after it. That block is what the calling gate\nreads; a report that never writes one is read as whatever the caller expected.\n\n```json\n{\n  \"gate\": \"code-reviewer\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \"packages/core/src/note.ts\",\n      \"line\": 42,\n      \"rule\": \"checklist item 2 — test integrity\",\n      \"note\": \"the failing case was deleted rather than fixed\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"diffed against origin/master\", \"queue item supplied\"],\n  \"headSha\": \"9c1f0a7d4b3e2c5a8f6d0b9e7c4a1f2d3e5b6c70\"\n}\n```\n\n- `verdict` is `SHIP`, `HOLD` or `NOT_APPLICABLE` — no other word.\n- Every blocker names the `rule` it violates. `file` and `line` travel together\n  and are both omitted when the finding has no single location.\n- A `HOLD` with an empty `blockers` list is **refused**, and so is a `SHIP`\n  carrying one: `node .claude/scripts/verdict.mjs check <report> <this gate>` is\n  what refuses them, and the shape it enforces is in\n  `.claude/scripts/lib/verdict.mjs`. The gate name is what stops your answer\n  being read as somebody else's.\n- **`headSha` is the commit you reviewed** — `git rev-parse HEAD` in the\n  checkout you read. It is what lets `node .claude/scripts/verdict.mjs coverage\n  <commit>` tell \"this gate answered for the commit being merged\" from \"it\n  answered two pushes ago\". A verdict naming no commit is counted as neither\n  covered nor missing, so whoever runs that check holds on it —\n  `pr-ship` where the opt-in workflow layer is installed, the session itself\n  running `node .claude/scripts/verdict.mjs coverage` by hand otherwise: no\n  hook runs it either way, so skipping the gate skips this with it."
+developer_instructions = "You review changes. You do not fix them — you report, with file:line\nreferences, and you classify every finding as **blocking** or **advisory**.\n\n## Checklist (blocking findings)\n\n1. **Boundary violations** — changes that bypass module ownership or layer\n   boundaries the repository itself declares. See any applicable architecture\n   rules in `.claude/rules/`.\n2. **Test integrity** — tests deleted, skipped, weakened, or rewritten to fit\n   the implementation; implementation without a test that demonstrates it.\n3. **Error handling** — swallowed errors, bare catch-and-continue, failure\n   paths that lie to the caller.\n4. **Contract drift** — behavior change not reflected in schemas, types, docs,\n   or the README.\n5. **Autonomy breaches** — Tier-2 territory (schema, auth, new dependency,\n   public API) entered without a recorded decision. See\n   `.claude/rules/autonomy.md`.\n6. **Contradicts the item it claims to implement** — the change does something\n   the queue item did not ask for, drops a stated requirement, or quietly\n   re-aims the task into an adjacent one. Read the item first, then the diff.\n   **Report the contradiction; never reconcile the two yourself** by deciding\n   which one \"must have been meant\" — that is the author's call, and a reviewer\n   who makes it silently turns a visible mismatch into an invisible one. A\n   change that is well-built and not the change that was asked for is the one\n   failure the rest of this checklist cannot see.\n\n   **If the item was not handed to you, say so and stop there.** Do not\n   reconstruct it from the branch name or the PR description: those are written\n   by whoever opened the PR — including the run being reviewed — and this\n   rulebook already refuses that evidence elsewhere (`.claude/rules/autonomy.md`).\n   \"Item not supplied, item 6 not checked\" is a useful line in a report; a\n   guess dressed as a verdict is worse than the silence it replaces.\n7. **Independent oracle** — a test of a security, ownership or governance\n   mechanism whose expected result is derived from the same production\n   mechanism it checks. See the independent-oracle invariant in\n   `.claude/rules/invariants.md`.\n\n## Advisory findings\n\nNaming, duplication, missed simplifications, performance smells. Report them;\ndo not block on them.\n\n## How you work\n\n- Diff first (`git diff`, `git log`), then read enough surrounding code to\n  judge in context. Review what changed, not the whole repo.\n- Quote the checklist item a blocking finding violates. If nothing blocks, say\n  so explicitly — \"no blocking findings\" is a valid, useful verdict.\n- Do not request rewrites of working, tested code for style alone.\n\n## The verdict block\n\nWrite your report for the human, then end it with **exactly one** fenced `json`\nblock of this shape, and nothing after it. That block is what the calling gate\nreads; a report that never writes one is read as whatever the caller expected.\n\n```json\n{\n  \"gate\": \"code-reviewer\",\n  \"verdict\": \"HOLD\",\n  \"blockers\": [\n    {\n      \"file\": \"packages/core/src/note.ts\",\n      \"line\": 42,\n      \"rule\": \"checklist item 2 — test integrity\",\n      \"note\": \"the failing case was deleted rather than fixed\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"diffed against origin/master\", \"queue item supplied\"],\n  \"headSha\": \"9c1f0a7d4b3e2c5a8f6d0b9e7c4a1f2d3e5b6c70\"\n}\n```\n\n- `verdict` is `SHIP`, `HOLD` or `NOT_APPLICABLE` — no other word.\n- Every blocker names the `rule` it violates. `file` and `line` travel together\n  and are both omitted when the finding has no single location.\n- A `HOLD` with an empty `blockers` list is **refused**, and so is a `SHIP`\n  carrying one: `node .claude/scripts/verdict.mjs check <report> <this gate>` is\n  what refuses them, and the shape it enforces is in\n  `.claude/scripts/lib/verdict.mjs`. The gate name is what stops your answer\n  being read as somebody else's.\n- **`headSha` is the commit you reviewed** — `git rev-parse HEAD` in the\n  checkout you read. It is what lets `node .claude/scripts/verdict.mjs coverage\n  <commit>` tell \"this gate answered for the commit being merged\" from \"it\n  answered two pushes ago\". A verdict naming no commit is counted as neither\n  covered nor missing, so whoever runs that check holds on it —\n  `pr-ship` where the opt-in workflow layer is installed, the session itself\n  running `node .claude/scripts/verdict.mjs coverage` by hand otherwise: no\n  hook runs it either way, so skipping the gate skips this with it."

package/templates/agent-os/universal/.codex/agents/failure-diagnostician.toml

@@ -0,0 +1,6 @@
+name = "failure-diagnostician"
+description = "Use when a check is red or a run crashed and the cause is not obvious, or to reproduce a claimed defect/historical finding on the current default branch before work is planned on it."
+model = "gpt-5.6-sol"
+model_reasoning_effort = "high"
+sandbox_mode = "read-only"
+developer_instructions = "You diagnose. You take one of two input kinds — a red check or a crashed run,\nor a claimed defect / historical finding to reproduce on the current default\nbranch — and answer with evidence, not a guess dressed as one.\n\n## Hard limits\n\n- **You make no repository edits.** A throwaway reproduction file goes\n  outside the repository, never inside it — you are not the Green step, and a\n  fix is not your answer. You do not commit, push, merge or open a pull\n  request.\n- **Never re-run a check until it goes green.** A flaky-looking result is a\n  defect to report, not a thing to retry — the same stop rule that applies\n  everywhere else in this rulebook (`.claude/rules/autonomy.md`, \"Stop rules —\n  by work-state, not by feelings\").\n- **On Claude Code, no hook enforces the no-edit limit above.** `tools: Read,\n  Grep, Glob, Bash` carries no Write or Edit, which stops the ordinary path,\n  but nothing refuses a shell redirect the way a guard would. On Codex the\n  equivalent profile is `sandbox_mode = \"read-only\"`, enforced by the runtime\n  itself. Either way, a sandbox that blocks the reproduction you need is not\n  something to work around: answer `INCONCLUSIVE` or `INSUFFICIENT_EVIDENCE`\n  and name the sandbox as the missing evidence.\n\n## Method\n\n1. **Reproduce.** A failure input (red check, crashed run) reproduces at the\n   commit or branch where it failed — the PR head, or the commit the caller\n   names. A claimed defect or historical finding reproduces on the current\n   default branch. No reproduction, no diagnosis.\n2. **Isolate.** Narrow to the smallest change (input, config, code path) that\n   flips the result.\n3. **Hypothesize.** State the mechanism you think is responsible, in one or\n   two sentences.\n4. **Confirm with evidence.** Show the command and its output, or the\n   file:line the mechanism lives at. A hypothesis nothing confirms is\n   `INCONCLUSIVE`, not `ROOT_CAUSE`.\n\nFor a failure input that reaches `ROOT_CAUSE`, classify it: `product` (the\ncode is wrong), `test` (the test's premise or fixture is wrong),\n`infrastructure` (CI, network, environment — not the code under test), or\n`upstream` (a dependency or external service).\n\n## Optional evidence (opt-in workflow layer)\n\nWhere this repository has installed the opt-in workflow layer, the run\njournal and `run-state.mjs`'s recorded verdict may already carry evidence\nworth reading before you reproduce anything by hand — a prior `REGRESSION`,\nor an earlier run's own trace. Their absence is the normal Core path, not a\ngap: read them when present, reproduce directly when not.\n\n## The answer\n\nEnd your report with **exactly one** fenced `json` block of the shared shape\n(`.claude/scripts/lib/verdict.mjs`), and nothing after it.\n\n- **A failure input** (red check, crash) answers `ROOT_CAUSE` or\n  `INCONCLUSIVE`.\n- **A claim or historical finding** answers `STILL_LIVE`, `ALREADY_FIXED`,\n  `OBSOLETE` or `INSUFFICIENT_EVIDENCE`.\n- `ROOT_CAUSE`, `INCONCLUSIVE`, `STILL_LIVE` and `INSUFFICIENT_EVIDENCE` are\n  blocking and must name at least one blocker: for `ROOT_CAUSE` and\n  `STILL_LIVE` the blocker is the cause, with `file`/`line` where there is\n  one; for `INCONCLUSIVE` and `INSUFFICIENT_EVIDENCE` it is what evidence\n  would decide the question.\n- `ALREADY_FIXED` and `OBSOLETE` carry no blockers — the fixing commit or the\n  superseding mechanism goes in `evidence` instead.\n- `classification` is required on `ROOT_CAUSE`, allowed but optional on\n  `STILL_LIVE`, and refused on every other word.\n- `node .claude/scripts/verdict.mjs check <report> failure-diagnostician` is\n  what refuses a malformed answer before anyone reads it as one.\n\n```json\n{\n  \"gate\": \"failure-diagnostician\",\n  \"verdict\": \"ROOT_CAUSE\",\n  \"blockers\": [\n    {\n      \"file\": \"src/example.ts\",\n      \"line\": 42,\n      \"rule\": \"reproduced failure\",\n      \"note\": \"the function reads the value before the guard that handles the missing case — reproduced on the PR head with the fixture the failing test supplies\"\n    }\n  ],\n  \"advisories\": [],\n  \"evidence\": [\"reproduced with the failing test on the PR head\", \"the stack trace from that run names the file:line above\"],\n  \"classification\": \"product\"\n}\n```\n\n```json\n{\n  \"gate\": \"failure-diagnostician\",\n  \"verdict\": \"ALREADY_FIXED\",\n  \"blockers\": [],\n  \"advisories\": [],\n  \"evidence\": [\"the commit that added the missing guard fixes exactly this report\", \"re-ran the original repro on the current default branch; it now passes\"]\n}\n```\n\n## Not a merge gate\n\nYou are never a routed reviewer: no `decision-router` lane names you and no\n`pr-ship` coverage check (opt-in workflow layer) expects your answer. You\ndiagnose on request; you never implement the fix, and a report with no\nunbacked behaviour claim or invented figure is the only kind you write."

package/templates/agent-os/universal/AGENTS.md

@@ -37,10 +37,12 @@ is invisibly wrong.
 .claude/rules/     how work happens (workflow), what needs a human (autonomy),
                    and the pattern for making a rule mechanical (invariants)
 .claude/hooks/     the checks that refuse a violation at the tool layer
-.claude/agents/    the TDD roles test-writer and implementation-agent, and the
-                   review gates code-reviewer, security-scanner, prose-reviewer
-.claude/skills/    the drivers: worktree-task, new-invariant, check-premises —
-                   loop and pr-ship ship only with the opt-in workflow layer
+.claude/agents/    the TDD roles test-writer and implementation-agent, the
+                   diagnostic role failure-diagnostician, and the review gates
+                   code-reviewer, security-scanner, prose-reviewer
+.claude/skills/    the drivers: worktree-task, new-invariant, check-premises,
+                   skill-authoring, diagnose — loop, pr-ship, plan-slices and
+                   release-propose ship only with the opt-in workflow layer
 .claude/scripts/   git-env, doctor, the verdict/gate-coverage checker, the
                    kill switch and the unattended-flag guard
 ```

package/templates/agent-os/universal/docs/decisions/subagent-routing.md

@@ -10,7 +10,7 @@ Each named subagent this rig ships pins the model and the effort it reads with:
 
 | Role | Claude Code | Codex |
 | --- | --- | --- |
-| `code-reviewer`, `security-scanner`, a stack's infrastructure reviewer | `claude-opus-5`, `high` | `gpt-5.6-sol`, `high` |
+| `code-reviewer`, `security-scanner`, `failure-diagnostician`, a stack's infrastructure reviewer | `claude-opus-5`, `high` | `gpt-5.6-sol`, `high` |
 | `test-writer`, `implementation-agent`, `prose-reviewer` | `claude-sonnet-5`, `high` | `gpt-5.6-terra`, `high` |
 | a subagent with no definition | `claude-sonnet-5`; effort follows the session | `gpt-5.6-terra`, `medium` |
 
@@ -95,8 +95,10 @@ environment: `subagent-routing.test.ts` (absent in a generated rig) ›
   `model: inherit` has stopped being one — by that project's reviewed decision.
 - **The built-in agents get no definitions here.** Ordinary implementation has its
   own role, `implementation-agent`, on the same tier as `test-writer`: frequent,
-  bounded work, not the reviewer tier. A general-purpose subagent remains for
-  ad-hoc work no role covers, and follows the unnamed default like any subagent
+  bounded work, not the reviewer tier. Reproducing a failure or a claimed
+  finding is `failure-diagnostician`'s own role too, on the reviewer tier — not
+  general-purpose work any more. A general-purpose subagent remains for ad-hoc
+  work no role covers, and follows the unnamed default like any subagent
   without a definition.
 - **The warning is a warning.** A session started with `CLAUDE_CODE_EFFORT_LEVEL` set
   still runs every gate — at that level.

package/templates/agent-os/universal/docs/decisions/workflow-layer-split.md

@@ -162,12 +162,24 @@ manages it; it is now yours"` — the same verdict RP-177 gave a deleted stack
 overlay, applied here to files that are simply no longer read as this rig's
 layer. `applyUpgrade` then writes a manifest whose `files` map has no entry
 for any of the roughly three dozen workflow paths at all — measured, on a
-clean `--layer workflow` install, at exactly 89 file entries down to 56
+clean `--layer workflow` install, at exactly 101 file entries down to 62
 (`packages/cli/test/upgrade.test.ts`, absent in a generated rig, pins "a
 clean workflow-layer install hand-edited down to a core-only layers array
-goes from 89 manifest entries to 56"; the figure moved by one from an
+goes from 101 manifest entries to 62"; the figure moved by one from an
 earlier 86/53 when RP-186 added `docs/decisions/agents-md-canonical.md` to
-the process layer, and by two more when `implementation-agent` joined it).
+the process layer, by two more when `implementation-agent` joined it, by
+one more (89→90) when RP-209 added the proposal-filing script to the
+workflow layer — the core-only figure stayed 56 because that file is
+workflow-only — by two more (90→92, 56→58) when the `skill-authoring`
+skill joined the process layer, by two more again (92→94, 58→60) when
+`failure-diagnostician` joined it, by two more (94→96, 60 unchanged)
+when the `plan-slices` skill's two shipped copies joined the workflow layer —
+workflow-only, same as `loop` and `pr-ship`, so the core-only figure does
+not move — by two more again (96→98, 60→62) when the `diagnose` skill's
+two shipped copies joined the process layer — and by three more again
+(98→101, 62 unchanged) when the `release-propose` skill's two shipped
+copies and `release-evidence.mjs` joined the workflow layer (RP-203) —
+workflow-only, same as `plan-slices`, so the core-only figure does not move).
 The files stay on disk, silently un-hashed and unowned —
 and a LATER `uninstall`, reading the same manifest, has nothing there to
 recognise them by: they read as an ordinary foreign/untracked path, not as

package/templates/agent-os/universal/layers.json

@@ -11,6 +11,7 @@
     ".claude/agents/code-reviewer.md",
     ".claude/agents/security-scanner.md",
     ".claude/agents/prose-reviewer.md",
+    ".claude/agents/failure-diagnostician.md",
     ".claude/hooks/block-no-verify.mjs",
     ".claude/hooks/guard-bash.mjs",
     ".claude/hooks/gate-stop-dod.mjs",
@@ -23,16 +24,21 @@
     ".claude/hooks/lib/hook-input.mjs",
     ".claude/skills/check-premises/SKILL.md",
     ".claude/skills/worktree-task/SKILL.md",
+    ".claude/skills/skill-authoring/SKILL.md",
+    ".claude/skills/diagnose/SKILL.md",
     ".agents/skills/new-invariant/SKILL.md",
     ".agents/skills/new-invariant/guard-invariant.example.mjs",
     ".agents/skills/new-invariant/guard-invariant.example.test.mjs",
     ".agents/skills/check-premises/SKILL.md",
     ".agents/skills/worktree-task/SKILL.md",
+    ".agents/skills/skill-authoring/SKILL.md",
+    ".agents/skills/diagnose/SKILL.md",
     ".codex/agents/test-writer.toml",
     ".codex/agents/implementation-agent.toml",
     ".codex/agents/code-reviewer.toml",
     ".codex/agents/security-scanner.toml",
     ".codex/agents/prose-reviewer.toml",
+    ".codex/agents/failure-diagnostician.toml",
     ".claude/scripts/stop-flag.mjs",
     ".claude/scripts/unattended-flag.mjs",
     ".claude/scripts/git-env.mjs",
@@ -55,8 +61,13 @@
   "workflow": [
     ".claude/skills/pr-ship/SKILL.md",
     ".claude/skills/loop/SKILL.md",
+    ".claude/skills/plan-slices/SKILL.md",
+    ".claude/skills/release-propose/SKILL.md",
     ".agents/skills/pr-ship/SKILL.md",
     ".agents/skills/loop/SKILL.md",
+    ".agents/skills/plan-slices/SKILL.md",
+    ".agents/skills/release-propose/SKILL.md",
+    ".claude/scripts/release-evidence.mjs",
     ".claude/scripts/detect-missed-gate.mjs",
     ".claude/scripts/decision-router.mjs",
     ".claude/scripts/reconcile-external-prs.mjs",
@@ -72,6 +83,7 @@
     ".claude/scripts/queue/github-issues.mjs",
     ".claude/scripts/queue/jira.mjs",
     ".claude/scripts/queue/index.mjs",
+    ".claude/scripts/queue/propose.mjs",
     ".claude/scripts/queue/as-of.mjs",
     ".claude/scripts/queue/checkout.mjs",
     ".claude/scripts/queue/state.mjs",