@erclx/canon 4.0.0

package/claude/skills/claude-address-review/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: claude-address-review
+description: Pulls review findings and CI status on the current branch's open PR, fixes each in the working tree, refreshes any stale `.claude/` docs, replies with a summary comment, and pushes a follow-up commit. The worker's return leg after `claude-pr-review`. Use when asked to "address the review", "fix the PR comments", "respond to review", or after an orchestrator posts findings. Do NOT use to write a review. That is `claude-pr-review`.
+---
+
+# Claude address review
+
+The worker's half of the review channel. `claude-pr-review` posts findings to
+the PR from an independent session. This skill consumes them: fix, reply, push.
+
+## Guards
+
+- If no open PR resolves for the current branch via `gh pr view`, stop: `❌ No open PR. Nothing to address.`
+- If the PR has no review comments or threads, run step 5's staleness test before deciding. A branch that still merges stops here: `✅ No review findings to address.` One that does not skips steps 1 through 4 and runs step 5 onward, since a branch goes stale from `main` moving and a closed review says nothing about whether it still merges.
+- Fix findings. Do not merge.
+
+## Step 1: pull the review findings and CI status
+
+Read the review comments and threads on the PR:
+
+```bash
+gh pr view --json number,reviews,comments
+```
+
+For inline review comments, read them via `gh api` on the PR's review comments. Collect each finding with its file, location, and body.
+
+Also read the CI check status so the fixes cover failing checks, not only review comments:
+
+```bash
+gh pr checks <number>
+```
+
+Treat a failing check as a finding to resolve alongside the review comments. When no checks are configured, `gh pr checks` reports none and the flow continues on the review findings alone.
+
+## Step 2: address each finding
+
+For each finding, implement the fix in the working tree. When a finding is a
+question or a conscious-accept rather than a defect, note the reply text instead
+of editing. Handle each finding independently. Do not let one unresolved finding
+block the others.
+
+## Step 3: verify
+
+Run the project check (`bun run check` or the project's documented equivalent).
+Do not push a red follow-up.
+
+## Step 4: refresh stale docs
+
+The fixes may have changed or added behavior that `.claude/` context entries, docs, or wireframes describe. Refresh them with the `claude-docs` skill, which maps the changed files to the entries that reference them and rewrites the stale sections. Do not reimplement that mapping here. When a fix adds a new capability with no existing entry, `claude-docs` flags it rather than creating one.
+
+## Step 5: rebase a stale branch
+
+A branch goes stale from `main` moving rather than from anything the branch did,
+so the test runs on every invocation, including the one the second guard sends
+straight here with no findings to fix. Fetch first. A stale local `origin/main`
+reports no conflict on a branch that has one.
+
+```bash
+git fetch origin main
+git merge-tree --write-tree origin/main HEAD
+```
+
+A zero exit means the branch still merges. Skip to step 6, which is the ordinary
+run. A non-zero exit means it does not, so read
+`${CLAUDE_SKILL_DIR}/references/rebase-conflicts.md` for the stash-and-rebase
+sequence, the conflict resolution rules, and the check to re-run afterward.
+
+`git merge-tree` reads committed history, so this test says nothing about the
+fixes still sitting in the working tree. A branch that merges clean as committed,
+whose fixes touch lines `main` moved, passes here and reaches the remote
+unmergeable. Step 6 re-runs the test once those fixes are commits.
+
+## Step 6: push, then reply
+
+Push the fixes before posting the reply so the comment never runs ahead of the
+code it describes. Ship the fixes as a follow-up commit on the same branch with
+the `git-followup` skill, invoked with `reply-owned` so it stages, commits,
+pushes, and refreshes the open PR body without posting its own comment. This
+skill owns the reply. Do not reimplement that flow here.
+
+`git-followup` syncs the body and title against the fix commit on every
+invocation, including `reply-owned`, so the merge record reflects what this pass
+changed rather than only what opened the PR. The reply comment still carries the
+fix log mapped to each finding, since the two serve different readers: the body
+is the merge record and the reply is the review's own thread. A rebase in step 5
+rewrote the branch, so that push is a force-push and `git-followup` resolves it
+from the tracking branch. Worker branches are single-owner here, which is what
+makes overwriting the remote safe.
+
+`git-followup` stops on an unchanged tree. A run that answered every finding as a
+conscious-accept and whose rebase left the generated files alone has nothing for
+it to commit, so the rebase would never reach the remote. Push that case directly
+with `git push --force-with-lease`, then post the reply below.
+
+Once the fixes are commits, re-run step 5's staleness test against the new head.
+A conflict that appears only now is one the fixes introduced against lines `main`
+moved, which the earlier test could not see. Rebase again under
+`${CLAUDE_SKILL_DIR}/references/rebase-conflicts.md` and force-push, then
+continue. The second push costs one extra force-push in a
+case that needs the fix and the sibling to touch the same lines.
+
+Then write a summary reply to `.claude/.tmp/address-review/reply-<number>.md`
+mapping each finding to what changed, or to a one-line reason when it is a
+conscious-accept rather than a defect. Key the filename on the PR number so two
+sessions addressing different pull requests never overwrite each other between
+the write and the post. Note any `.claude/` docs refreshed as a result of the
+fixes.
+
+The reply is a rendered-for-human GitHub surface, so load the `write-human`
+skill for voice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for
+the banned words, and keep each mapping to a line or two.
+
+Open the body with the `## Review response` heading so it anchors as a section
+distinct from human threads and stays subordinate to the `## Review` heading the
+review itself carries. Follow it with a one-line summary sentence, then one
+bullet per finding, each opening with the bolded finding identifier.
+Close the body with `🤖 Addressed by Claude Code` on its own line so the reply
+reads as an independent machine pass, not a human sign-off.
+
+A finding this run declined carries the fact that settled it, inside its own
+bullet rather than in a section of its own. Name the plan question that already
+answered it, the constraint the diff does not show, or the measurement the
+reviewer did not have. Answering the dispatch in the channel and leaving that
+fact there loses it when both sessions end, and the reviewer is left with a
+finding that stopped being mentioned. The rule fires on a bullet the body already
+writes, so nothing depends on judging mid-reply whether a reply was important.
+
+The rule reaches a finding and nothing else. A correction to what the reviewing
+session believes about the world, such as which session holds which branch or
+what an edit passes through before it lands, changes no finding on this pull
+request and belongs in that session's own record rather than on a thread that
+closes. Keep it off the comment, and answer it wherever the dispatch reached this
+session when one did. Nothing tests the reply for either rule, since the scan
+below reads it for banned characters and phase labels alone, so both halves hold
+while a run applies them.
+
+The `pull_request` check the git-pr surface carries reads a pull request's own
+title and body, not a reply comment, so the scan below stays the only gate here.
+
+When step 5 rebased the branch, say so in the summary sentence and name which
+files were resolved by hand and which the regen rebuilt. The next review is a
+full pass rather than a delta, and the reader is owed the reason.
+
+A run the second guard sent straight to step 5 has no findings to map, so it
+takes a different body rather than an empty list. Open it with `## Rebase`, not
+`## Review response`, since nothing on the pull request is being responded to and
+that heading claims a review this run never read. State that the branch stopped
+merging, name what landed on `main`, name the files resolved by hand and those
+the regen rebuilt, and close the same way. The heading stays outside the
+`## Review` family so the close-out's equality test on the first line never
+matches it.
+
+Before posting, run the scan in
+`${CLAUDE_SKILL_DIR}/../../standards/publish.md`
+against the reply. The hook skips `.claude/.tmp/`, so this scan is the
+only gate on the published reply. Post it to the PR:
+
+```bash
+gh pr comment <number> --body-file .claude/.tmp/address-review/reply-<number>.md
+```
+
+## Step 7: confirm resolution
+
+After the follow-up push, watch CI on the PR. Poll `gh pr checks <number>`
+until no check is pending, then read the final status. When every finding is
+addressed and all checks pass, post one closing comment so the thread has a
+clear terminal state:
+
+```bash
+gh pr comment <number> --body "✅ All review findings addressed, CI green."
+```
+
+A rebase-only run addressed no finding, so it takes its own terminal comment
+rather than that one. Claiming findings were addressed on a pull request that
+carries none is false on a surface nothing else checks:
+
+```bash
+gh pr comment <number> --body "✅ Rebased onto origin/main, CI green. No review findings were open."
+```
+
+If any check fails, do not post the closing comment. Report the failing check
+so it can be fixed first. This is a resolution signal, not a formal approval,
+since the PR author cannot approve their own PR.
+
+## Step 8: output
+
+```plaintext
+Addressed <N> findings on PR #<number>. Follow-up pushed.
+<Rebased onto origin/main. <N> files resolved by hand, <N> rebuilt by the check.>
+```
+
+Omit the second line when the branch still merged. Name any finding left as a
+reply rather than a code change, with its one-line reason.
+
+A rebase-only run drops the first line rather than reporting zero findings
+addressed, and leads with the rebase instead:
+
+```plaintext
+Rebased PR #<number> onto origin/main. <N> files resolved by hand, <N> rebuilt by the check.
+```
+
+Do not merge. Hand back to the orchestrator for re-review.
+
+## Post-review findings
+
+Not everything worth reaching the reviewing session surfaces inside the numbered flow above. A worker that settled a risk, filed a follow-up, or found something else worth reporting after Step 7 already closed the review posts it directly rather than waiting on a review pass that has nothing left to trigger it. Write the body the way Step 6 writes a reply: load `write-human` for voice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for the banned words, and run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan before posting.
+
+Open with `## Post-review findings` rather than `## Review response`, since nothing on the thread is being answered. `claude-pr-review` states the full heading set this belongs to and routes it the same as a response: `claude-orchestrate`'s poll picks it up and sends the reviewing session back for a pass. Close the body with `🤖 Addressed by Claude Code` on its own line, matching the reply's footer.
+
+```bash
+gh pr comment <number> --body-file .claude/.tmp/address-review/reply-<number>.md
+```

package/claude/skills/claude-address-review/references/rebase-conflicts.md

@@ -0,0 +1,39 @@
+---
+title: Rebase a stale branch
+description: The stash-and-rebase sequence, the conflict resolution rules, and the two recovery messages a hunk needing a decision takes
+---
+
+# Rebase a stale branch
+
+Mechanics for Step 5 of `claude-address-review` once `git merge-tree` exits non-zero. A branch that still merges skips this file entirely, which is the ordinary run.
+
+## The sequence
+
+Stash the fixes first when `git status --porcelain` reports anything, since a rebase refuses to run over a dirty tree, then rebase onto `origin/main` and restore them:
+
+```bash
+git stash push -u
+git rebase origin/main
+git stash pop
+```
+
+Pop only when the stash ran. On a clean tree, which is what a run whose findings were all conscious-accepts leaves behind, `git stash push` saves nothing and exits zero, so the pop restores an unrelated entry from an earlier session.
+
+Never merge `main` into the branch. The repository squash-merges, so a merge commit here reads as noise on the pull request.
+
+## Resolving a conflict
+
+These rules apply to a hunk from the rebase and a hunk from the stash pop alike:
+
+- Never take one side wholesale with `--ours` or `--theirs`. Both sides are valid content, so the drop is silent and passes every check.
+- Never resolve a generated file by hand. A file the project check rebuilds, such as an `index.md` carrying no `auto: false`, takes either side to clear the conflict and gets its real content from the regen below.
+- Where two branches wrote prose into one file, keep both sides and rewrite what the merge broke. A section that opens by counting what follows needs the count updated rather than the two versions concatenated.
+- When a hunk needs a decision the tree does not carry, stop rather than guessing, and name where the branch was left. The two sources recover differently. A guess that compiles is the failure this stage would otherwise introduce, and either case reaches the operator as an ordinary finding on the next review pass.
+  - A hunk raised by the rebase takes `git rebase --abort`, which restores the old base: `❌ Conflict needs a decision at <file>. Branch left on its old base.`
+  - A hunk raised by the stash pop arrives after the rebase already landed, so no abort applies and the conflict stays in the tree: `❌ Conflict needs a decision at <file>. Branch rebased, fixes left conflicted in the tree.`
+
+Both sides of every hunk sit in the conflict and `git log origin/main` names what landed, so the tree carries the context. Do not wait on the orchestrator for it.
+
+## After the rebase
+
+Re-run the project check. It rebuilds the generated files and covers what the replayed commits broke, and step 6 commits the result alongside the fixes.

package/claude/skills/claude-autoship/REQUIREMENT.md

@@ -0,0 +1,50 @@
+---
+name: claude-autoship
+description: What the post-plan pipeline is for, the gaps it closes, and why every stop leaves the work recoverable
+---
+
+# Claude autoship requirement
+
+## Gap
+
+Without this skill, the run from an approved plan to an open pull request is a conversation. A session implements, then asks what comes next, and the answer varies by session. A run that halts leaves no stated resume point, so the user reconstructs how far it got from the working tree.
+
+Review is the step that varies most. It gets skipped on a diff that needed one, or spent on prose already gated by a hook. A file-extension test cannot separate the two, since a skill body and a documentation page are both markdown, so a branch changing what an agent does takes the skip a documentation branch earned.
+
+## Must
+
+- Take the approved plan for the branch as the scope, and implement only what it describes
+- Give every step a stop condition, and leave the code on the branch and the receipts on disk at each one
+- Classify the changed-file list by path as well as by extension, so informational prose skips a code review with no signal on it and executable prose still reaches one
+- Split findings by origin, stopping on a critical or should-fix one the branch inherited and repairing one this run caused
+- Own the review receipt's lifetime, since this chain writes it, cites it in its own closing block, and is the only body that can read whether the step keeping it is still using it
+- Delegate the ship sequence to `git-ship` rather than restating it, and name only what this chain adds to it
+- Open the pull request as a draft before the continuous integration watch begins, since a pull request marked after it is mergeable for the length of the run
+- Name the recovery for the stop it took, since the value of stopping is that the user knows where to resume
+
+## Must not
+
+- Expand past the plan, refactor a neighbor, or touch a file outside it without reason
+- Loop on a failed verify. One fix attempt against the reported errors, then stop.
+- Fix an inherited review finding or a failing check. Both stops are deliberate, since a green pull request reached by auto-fix hides what broke.
+- Loop on a self-introduced finding. One repair pass, then stop, which is the bound a failed verify already carries.
+- Read the plan's file list as the boundary on a repair. It scopes what the run builds, and a finding this run caused is in reach wherever it landed.
+- Restate the ship sequence. Two copies of one order drift with nothing comparing them, which is what the merge into `git-ship` closed.
+- Skip that skill's own verify for repeating this chain's. The gate exists for the resumed run, and a chain that suppresses it leaves the resumed run reaching nothing.
+- Run the memory Apply phase. Promoting an entry changes how the agent operates and ships as its own change.
+- Read an empty changed-file list as prose-only. It satisfies that test vacuously and would route the branch past review instead of through it.
+- Read a markdown extension as evidence the change only informs. A skill body, a governance rule, and a standard are behavior written in prose.
+
+## Guards
+
+- Detached HEAD: stop, no slug resolves
+- No approved plan at the branch's plan path: stop and route to the planning skill
+- Uncommitted changes unrelated to the plan: stop
+- No diff baseline against main: stop
+- Empty changed-file list: stop, and never advise removing the output from `.gitignore` to get past it
+
+## Out of scope
+
+- Writing the plan, which `claude-feature` owns. This chain starts from one already approved.
+- The behavior of each step, owned by the skill invoked. This skill owns the order and the stop conditions.
+- The ship sequence and the resume path after a stop, both of which `git-ship` owns. That skill is the tail of this chain, invoked at Step 7 rather than copied into it, so the overlap is one body reached two ways rather than two bodies stating one order.

package/claude/skills/claude-autoship/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: claude-autoship
+description: Chains implement → verify → review → ship after a feature plan is approved. Reads the plan the caller names, the plan a named task points at, or the plan for the current branch when none is named, runs the full pipeline in one session, and stops on any failure or non-minor review finding. Use when asked to "autoship", "ship this feature end to end", or "run the chain". Do NOT auto-trigger. Requires an approved plan file.
+disable-model-invocation: true
+---
+
+# Claude autoship
+
+Chain the post-plan pipeline in a single run. Every step has a stop condition. State is always recoverable on stop: code lives on the branch, review output on disk, plan still linked.
+
+## Guards
+
+- All `.claude/plans/` and `.claude/review/` reads resolve at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`.
+- Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. This skill takes the stop rather than the `latest` fallback, since it commits and opens a pull request. If empty, stop: `❌ Detached HEAD. Checkout the feature branch first.` Every later step keys its output on this slug, being the worktree, the review receipt, the branch, and the memory proposal, regardless of which plan Step 1 reads.
+- Resolve `<plan>` in Step 1, ahead of any other read.
+- If the working tree has uncommitted changes unrelated to the plan, stop: `❌ Uncommitted changes outside the plan. Commit or stash before autoshipping.`
+
+## Diff baseline
+
+Step 5 classifies the changed-file list to decide whether review runs. Resolve the base ref once:
+
+```bash
+git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null
+```
+
+Prefer `origin/main` over local `main`. A local `main` trailing the remote pulls other people's merged commits into the list, so the classifier decides against files this branch never touched.
+
+The baseline is unusable when no merge base resolves against either ref. Stop: `❌ No diff baseline against main. Fetch origin, then re-run autoship.`
+
+The base equalling HEAD stays usable here, unlike in the four read-only siblings carrying this section. Step 5 runs before anything is committed, since `git-stage` commits at Step 7, so the base equals HEAD on every ordinary run. The classifier diffs the base against the working tree rather than against HEAD, which keeps the uncommitted work in the set at correct scope. Do not port the sibling `base == HEAD` stop into this skill.
+
+## Step 0: take the role, then enter a worktree
+
+Invoke `canon:claude-worker` first, whatever the worktree state. This session is about to build one branch under one plan, and that skill states the boundaries, the lifetime, and the channel obligations the role carries. A dispatched worker reaches the role here and nowhere else, since the launch names this chain rather than the role, and a hand-launched one reaches it on the same path.
+
+Report it rather than proceeding silently when `canon:claude-worker` does not resolve. It ships with the plugin, so a session running this chain from a project holding the CLI alone builds with no role asserted.
+
+If `git rev-parse --git-dir` equals `git rev-parse --git-common-dir`, the session is in the main worktree. Invoke `canon:claude-worktree` before continuing. The wrapper handles name derivation and branch alignment. Do not call `EnterWorktree` directly.
+
+If neither command resolves, stop: `❌ Not a git repository. Autoship needs git or a WorktreeCreate hook.`
+
+If the two commands differ, the session is already in a linked worktree. Continue.
+
+## Step 1: read the plan
+
+Resolve `<plan>` in this order, stopping at the first match:
+
+1. **Caller-supplied task.** The invocation carried a path under `.claude/tasks/`. If it does not resolve to a file, stop: `❌ No task at <path>. Path was supplied, not derived, so check it and re-run.` Read that task's first `Plan:` line and take what it names as `<plan>`, per `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`.
+2. **Caller-supplied plan.** The invocation carried something else. Accept it as a plan path or a bare slug, in the same position `claude-worktree` tier 0 accepts its name. A bare slug resolves to `.claude/plans/feature-<slug>.md`, and a path is taken as given from the main worktree root. If it does not resolve to a file, stop: `❌ No plan at <path>. Path was supplied, not derived, so check it and re-run.`
+3. **Derived.** `.claude/plans/feature-<slug>.md`, from the `<slug>` the Guards derived. If it does not exist, stop: `❌ No approved plan at .claude/plans/feature-<slug>.md. Run /claude-feature first.`
+
+Only a path reaches tier 1, and a bare slug is read as a plan's throughout. The two would collide on any similar name, and a caller who means the task holds its path already, having read it off the board. One plan per task is what makes the tier 1 read unambiguous, so it takes the first `Plan:` line and never scans for a second.
+
+Read the target out of the link's parentheses, and take the rest of the line when the line carries no link, since an older task writes the target as a plain path with nothing around it. Resolve a relative target against the directory holding the task file rather than against `.claude/tasks/`, and take a project-root target from the root. The archived task is what makes that base matter, since the standard points its line at `../../plans/archive/feature-<slug>.md` once the task sits a folder deeper, and reading that from `.claude/tasks/` lands on a repository-root `plans/archive/` that never exists.
+
+### When a tier fails
+
+Tier 1 stops on three failures, and each names a different repair:
+
+- No `Plan:` line at all. Stop: `❌ <path> carries no Plan: line, so nothing there names a plan to run. Write the plan and point the task at it, or pass the plan path directly.` A row still awaiting a plan is the ordinary case, so the message names the missing pointer rather than the missing plan sections a reader would then go hunting for.
+- The pointer resolves into a plans archive. Stop: `❌ <path> points at an archived plan, which describes work that already shipped. Reopen the task against a live plan, or pass that plan directly.` Test the resolved path rather than the task's outcomes or its `Pull request:` line, since a stale board gets its ticks wrong and the standard fixes where a shipped pointer lands.
+- The pointer resolves to no file. Stop: `❌ <path> points at <target>, which does not exist. The citation is stale, so repoint the task or pass the plan path directly.`
+
+An archive is `.claude/plans/archive/` and also the two older spellings `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` leaves in place for a project that archived plans before the folder nested, written from a task as `../plans-archive/` and `../.tmp/plans-archive/`. Test all three, since a shipped pointer in a project nobody migrated lands on the older two. Run the archive test ahead of the existence test, so a pointer into an archive that no longer holds the file still refuses as shipped work rather than as a stale citation.
+
+Each tier fails for a different reason and says so. A supplied path resolving to nothing is a typo, a derived path resolving to nothing is a plan nobody wrote, and a task pointer resolving to nothing is a stale citation the board should have caught.
+
+Test the shape of whatever `<plan>` resolved to before reading it as one. A file resolving under any tier can still be the wrong document, and tier 1 resolves through a pointer rather than from the caller, so the test runs after all three rather than guarding a supplied path alone.
+
+Check for a `**Files to touch:**` or `## Files to touch` marker per `${CLAUDE_SKILL_DIR}/../../standards/plan.md`, the one section every plan carries structurally and a task never does, where `## Outcomes` and `## Findings` are the task's own. If neither form is present, stop: `❌ <path> carries no plan sections. A plan lives at .claude/plans/feature-<slug>.md, and a task reaches one through its Plan: line only from .claude/tasks/. Point autoship at either and re-run.`
+
+Read `<plan>` at the main worktree root. This file is the scope for this run.
+
+Its sections and its answer contract are fixed by `${CLAUDE_SKILL_DIR}/../../standards/plan.md`. A blank `- Answer:` accepts the `- Suggested:` line above it, so an unanswered question is a decision this run executes rather than a reason to stop.
+
+## Step 2: implement
+
+Implement only what the plan describes. Do not expand scope. Do not refactor neighbors. Do not touch files outside the plan's "Files to touch" list without reason.
+
+## Step 3: verify
+
+Run the verify commands defined in `CLAUDE.md` (lint, typecheck, tests). On failure:
+
+- Make **one** fix attempt targeting the reported errors
+- Re-run only the failing command
+- If it still fails, stop: `❌ Verify failed after one fix attempt. Review logs and retry manually.`
+
+Do not loop. Do not bypass hooks.
+
+## Step 4: UI test (conditional)
+
+If the diff touches UI files (JSX, TSX, Vue, Svelte, HTML, or CSS under `src/`), invoke `canon:claude-ui-test`.
+
+If `claude-ui-test` produces a manual checklist, stop: `❌ UI requires visual verification. Checklist at .claude/review/ui-checklist-<slug>.md. Verify manually, then run /git-ship.`
+
+If all UI changes are covered by e2e tests, continue.
+
+## Step 5: review
+
+Classify the diff first. Take the union of `git diff --name-only <base>` and `git ls-files --others --exclude-standard`, resolving `<base>` per Diff baseline, then hand that set to the verb rather than reading it against the list below yourself:
+
+```bash
+canon autoship classify --json <path>...
+```
+
+The verb reads names only and touches git not at all, so the set stays the one this step already computed and no second baseline resolves to disagree with the first. Branch on the record's `decision` rather than on the exit code, which a shell function wrapping `canon` can flatten to zero.
+
+- `skip`. Every path reads as prose and none states agent behavior. Skip review entirely and continue to Step 7.
+- `review`. Invoke `canon:claude-review`. The record names the `file` that decided it and the `test` it failed, `extension` for a path that is not prose and `behavior-path` for prose that states what an agent does.
+- `refused`, carrying reason `no-changes`. The changed set was empty, so take the stop below.
+
+Say in the run which of the two decided, the verb or the written fallback, since a reader otherwise cannot tell a classification from a judgment.
+
+An empty list stops the chain: `❌ No changed files to classify. Re-run when the plan has yet to produce its output. When the output is gitignored by design, autoship cannot ship it, so take the work out of the chain.` An empty list satisfies the prose-only test vacuously, so reading it as prose-only routes the branch past review instead of through it.
+
+The two causes want different responses. A plan that has yet to produce its output is a re-run once it has. A plan whose output is gitignored by design, such as a read pass writing to `.claude/.tmp/`, is work the chain cannot carry at all, since `git-stage` finds nothing to commit six steps later. Never advise removing the output from `.gitignore`, which trades a stopped run for scratch committed into the repository.
+
+### When the verb is absent
+
+The verb ships with the CLI and this body ships with the plugin, so a target holding an older binary meets a missing subcommand. Apply the written test by hand there, and say the fallback decided it.
+
+Never read an absent subcommand as a skip. Failing open is the exact defect the verb closes, and a shell that answers `command not found` reaching a body that skips on anything other than a `skip` record would ship every branch unreviewed.
+
+The skip needs both tests to pass: every changed file matches `*.md` or `*.txt`, and no changed file sits under a behavior path. On a pass, skip review entirely and continue to Step 7. Otherwise invoke `canon:claude-review`.
+
+Behavior paths carry two spellings, the one a surface authors at and the one it reaches a session at, so the rule reads the same in a toolkit and in a project that consumed one:
+
+- `claude/skills/` and `.claude/skills/`
+- `governance/rules/` and `.claude/rules/`
+- `standards/`, which is the authoring root and reaches a reader by resolution rather than by an install, so it carries no `.claude/` spelling
+- `snippets/`, which reaches a session through the `claude/snippets` symlink rather than an install, so it carries no `.claude/` spelling either
+- `internal/` and `tooling/`, which hold the stack references and the seed documents a target is handed
+- `CLAUDE.md` at the repository root, named as a file because a path prefix reaches nothing that sits in no folder
+
+Markdown under one of them states what an agent does, so a change there is a behavior change wearing a prose extension. Everything outside them is informational, which keeps `docs/`, `README.md`, and `CHANGELOG.md` skipping without naming them. One behavior file sends the whole branch to review, since documentation shipped beside a behavior change does not cancel it.
+
+Informational prose is already gated by `docs-sync`, `claude-standards-audit`, and pre-push hooks. Running a code-style review on it burns tokens with no signal.
+
+The list covers this toolkit's authoring layout and the layout it installs, which is not every layout. A project keeping executable prose where neither spelling reaches adds the path, and until it does every branch touching it skips review silently.
+
+The verb reads the same set from `src/autoship/paths.ts`, so a path added here belongs there too and a path added there belongs here. Two copies is what the fallback costs, and it stands until a release retires the written half.
+
+## Step 6: evaluate findings
+
+Skip this step when Step 5 skipped review. Otherwise read `.claude/review/branch/review-<slug>.md` at the main worktree root. Split every finding by origin before parsing the summary line (`X critical, Y should-fix, Z minor`), since the stop exists for a defect the branch inherited rather than for one this run introduced.
+
+- **This run caused it, at any severity.** Fix it, re-run the Step 3 verify commands, re-read the fixed file against what the finding claimed, and continue. Do not report it as a stop and do not offer the fix as a choice, which is the same stop wearing a proposal.
+- **It predates this run, critical or should-fix.** Stop: `❌ Review found non-minor issues that predate this run. See .claude/review/branch/review-<slug>.md. Fix and run /git-ship.`
+- **It predates this run, minor only.** Continue. The minor findings stay in the on-disk review receipt. Fold any a reviewer needs into the PR's `## Technical Context`. Do not add a separate review-notes section to the PR body.
+
+Read origin as causation rather than authorship. Staleness this run induced in a file it never opened is a finding it caused, and the plan's "Files to touch" list scopes what the run builds rather than what it may repair.
+
+Bound the repair at one pass, the way Step 3 bounds verify. When that re-read shows the finding still standing, stop: `❌ A self-introduced finding survived one fix pass. See .claude/review/branch/review-<slug>.md. Fix and run /git-ship.`
+
+This chain owns the receipt's lifetime, which is what makes the Output block's citation resolve on a run that reaches it. `claude-docs` used to delete the current slug's receipt while running under Step 7 below, so the closing line named a file the same run had already removed. That sweep now reaches only reports whose branch is gone, which collects this one a branch later rather than during the run that wrote it. The cost is one receipt per live branch left in `.claude/review/branch/`, bounded by the branch count rather than by the lifetime of the checkout.
+
+## Step 7: ship
+
+Invoke `canon:git-ship`. That body owns the sequence, being the verify gate, memory capture, both doc syncs, staging, the commit grouping, the branch rename, the pull request, the CI watch, and the scoped memory review, along with the reason each step sits where it does. This step used to restate that list and the two drifted apart with nothing comparing them, so read the order there and never here.
+
+One thing this chain adds. Mark the pull request as a draft as soon as `git-ship`'s pull request step returns, ahead of its CI watch:
+
+```bash
+gh pr ready --undo
+```
+
+Placement is the whole point of naming it. Marking after the watch leaves the pull request ready to merge for as long as CI runs, which is the window an unattended worker's branch is least supervised.
+
+`git-ship` verifies again at its own gate, which repeats this chain's Step 3 on the run where nothing stopped. That cost is deliberate: four of the stop points in the table below hand the run straight back to that body, and a gate the chain skips for being redundant is a gate no resumed run ever meets.
+
+## Output
+
+Respond with up to five lines:
+
+```plaintext
+✅ Autoshipped (draft): <PR url>
+<N minor findings kept in .claude/review/branch/review-<slug>.md>
+<N facts routed to context entries>
+<N memories captured in .claude/memory/>
+<Memory proposal at .claude/review/memory/memory-review-<slug>.md>
+```
+
+Omit the second line if there were no minor findings, and the third if nothing routed. Omit the fourth and fifth if `claude-memory-capture` wrote no memory file this session, since an empty pen means no scoped review and no proposal. A run that routes every fact and writes none is the shape to expect, and it reports three lines.
+
+This block replaces the one `git-ship` closes on rather than following it. The two carry the same three trailing lines and differ on the two above them, since the first names the draft state and the second reports the minor findings Step 6 kept, neither of which that body has a counterpart for. Emitting both reports one run twice and buries the draft under a `✅ Shipped` that does not name it.
+
+## Failure recovery
+
+Every stop point leaves recoverable state. The user resumes manually from the appropriate step.
+
+| Stop point                                 | Recovery                                                                                                                                       |
+| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| No plan (derived)                          | Run `/claude-feature` to create one                                                                                                            |
+| No plan (caller-supplied)                  | Check the path or slug passed to autoship, then re-run                                                                                         |
+| No task (caller-supplied)                  | Check the task path passed to autoship, then re-run                                                                                            |
+| Task carries no `Plan:` line               | Write the plan, point the task's `Plan:` line at it, then re-run                                                                               |
+| Task points at an archived plan            | The work already shipped. Reopen the task against a live plan, or pass that plan's path directly.                                              |
+| Task's `Plan:` pointer resolves to nothing | Repoint the task's `Plan:` line at the plan that exists, then re-run                                                                           |
+| Resolved file carries no plan shape        | Point autoship at a plan under `.claude/plans/feature-<slug>.md` or at a task under `.claude/tasks/`, then re-run                              |
+| No diff baseline                           | Fetch origin so a merge base resolves against `main`, then re-run autoship                                                                     |
+| Empty changed-file list                    | Re-run once the plan produces tracked output. Ship gitignored output outside the chain, never by tracking it.                                  |
+| Branch collision on worktree entry         | `claude-worktree` Step 5 found `<slug>` already as a local branch. Resolve manually (rename or delete the stale branch), then re-run autoship. |
+| Verify fails                               | Read logs, fix manually, run `/git-ship`                                                                                                       |
+| UI checklist                               | Verify visually, run `/git-ship`                                                                                                               |
+| Inherited review findings                  | Fix findings, run `/git-ship`                                                                                                                  |
+| Self-introduced finding survived           | Read the receipt for what the one repair pass left open, fix it, run `/git-ship`                                                               |
+| git-ship fails                             | Inspect hook or remote error, run again                                                                                                        |

package/claude/skills/claude-design-extract/REQUIREMENT.md

@@ -0,0 +1,42 @@
+---
+name: claude-design-extract
+description: Why a design system is drafted from what the tree already holds, and how a proposed value is kept distinguishable from a sourced one
+---
+
+# Claude design extract requirement
+
+## Gap
+
+Without this skill, a session asked for a design system either invents token values with nothing behind them or refuses because the project ships no stylesheet. It writes over a `.claude/DESIGN.md` someone already filled. It fills every cell so the file looks complete, which leaves a reader unable to tell a hex sampled from the CLI apart from one the session made up, and a proposal nobody flagged gets built on. A trailing tag column added to mark that uncertainty breaks the render parser instead.
+
+The greenfield case is the one that fails quietly. A project with no UI code still has a personality paragraph and a stated platform, so values can be proposed against a signal rather than pulled from a default palette. A session that does not know this reports there is nothing to extract.
+
+## Must
+
+- Pick the source or greenfield path from what the project tree holds, never from a flag or an argument
+- Announce which path ran, since the two produce different-looking output from one skill
+- Fetch the seed template and keep every heading and table header intact, because the render parser reads them
+- Mark any cell not traced to a source value inline inside the cell value, and take the uncertainty into the sentence when the section is prose
+- Anchor every greenfield proposal to a personality or requirements signal rather than to a default
+- Render the preview and report its path, so the proposals get looked at before they are committed
+
+## Must not
+
+- Overwrite a `.claude/DESIGN.md` that already carries content beyond the seed
+- Guess a value on the source path when no signal exists. Leave the cell blank instead.
+- Invent a non-goal. A proposed motion line is correct when nothing rules motion out.
+- Put the verify tag in a trailing column, which breaks the row
+- Rewrite the transcribed personality paragraph, which is the one section that is not a proposal
+
+## Guards
+
+- `.claude/DESIGN.md` already populated: stop rather than mutating it
+- `canon` not on PATH: stop, since the seed template and the render both need it
+- Greenfield path with no `.claude/REQUIREMENTS.md` or no `## Personality` section: stop, because there is nothing to propose against. Evaluate this only after Step 1 picks the path.
+
+## Out of scope
+
+- Mutating an existing design system, which is a direct edit of the file rather than a skill
+- Producing the HTML and CSS preview, which `canon design render` owns
+- Auditing the implemented UI against the tokens, which `claude-ux-audit` owns
+- Architecture and flow diagrams, which `claude-diagram` owns