@erclx/canon 4.66.0 → 4.68.0

package/docs/workflow/ai-workflow.md

@@ -51,12 +51,12 @@ One session works for most features. Prefer splitting across two sessions only w
 
 Work in Claude Code directly. It reads `CLAUDE.md` automatically and has full file access, no pasting needed.
 
-- When the input is a pile of findings rather than one feature, invoke `canon:claude-intake` first. It files the dump into `.canon/intake/<nn>-<slug>/`, one item per finding carrying a problem measured against the tree, a proposed fix, and a verdict, then names which items are plan-ready, which need measuring, and which are already settled.
-- When the current state is unmeasured and more than one approach is live, invoke `canon:claude-groundwork` first. It opens a track folder under `.canon/groundwork/<nn>-<slug>/` and ends in a decision, which may be to do nothing. Skip it when the approach is already settled.
-- Invoke `canon:claude-feature` to scan for code-level conflicts and ambiguities, confirm approach before proceeding
+- When the input is a pile of findings rather than one feature, invoke `canon:plan-intake` first. It files the dump into `.canon/intake/<nn>-<slug>/`, one item per finding carrying a problem measured against the tree, a proposed fix, and a verdict, then names which items are plan-ready, which need measuring, and which are already settled.
+- When the current state is unmeasured and more than one approach is live, invoke `canon:plan-groundwork` first. It opens a track folder under `.canon/groundwork/<nn>-<slug>/` and ends in a decision, which may be to do nothing. Skip it when the approach is already settled.
+- Invoke `canon:plan-feature` to scan for code-level conflicts and ambiguities, confirm approach before proceeding
 - Implement the feature, then Claude Code runs the commands defined in `CLAUDE.md`, fixes failures, and iterates until all pass
-- For UI changes, invoke `canon:claude-ui-test` to generate and run Playwright e2e tests
-  End the session once the feature works and tests pass. Invoke `canon:claude-docs` to capture any decisions made during implementation before closing.
+- For UI changes, invoke `canon:ui-test` to generate and run Playwright e2e tests
+  End the session once the feature works and tests pass. Invoke `canon:docs-fold` to capture any decisions made during implementation before closing.
 
 The routing test is whether the repository can answer an item today. A session grepping handles the yes, and a groundwork track handles the no.
 
@@ -68,7 +68,7 @@ What a spike produces goes somewhere else again. An input the run reads is re-ru
 
 Start a fresh Claude Code session. The diff is sufficient context for both review and ship.
 
-- Invoke `canon:claude-review` to review all changes since main and output a findings report
+- Invoke `canon:review-branch` to review all changes since main and output a findings report
 - Fix any valid findings
 - Invoke `canon:git-ship` to run the project's verify commands, sync docs, commit by concern, rename branch, and open PR
 
@@ -77,12 +77,12 @@ Start a fresh Claude Code session. The diff is sufficient context for both revie
 When features are independent, run them in parallel instead of sequentially. Use one git worktree per feature so each session has its own working tree and branch.
 
 - Create a worktree per feature, then start a Claude Code session in each
-- Invoke `canon:claude-feature` in each session. Plans land at the main worktree root as `.canon/plans/feature-<slug>.md`, one per feature, no collisions. Small features stay in chat and skip the file.
-- Implement, verify, and review each feature independently. `claude-review` writes a per-branch report at the main worktree root (`review/branch/review-<slug>.md`), and `claude-ui-test` writes a per-branch checklist handoff there too (`tmp/ui-checklist/<slug>.md`) that `git-pr` posts to the pull request and removes, so parallel sessions do not overwrite each other. The slug is the branch name with any leading type segment dropped, so `feat/jwt-expiration` and the plan at `feature-jwt-expiration.md` meet on one name
+- Invoke `canon:plan-feature` in each session. Plans land at the main worktree root as `.canon/plans/feature-<slug>.md`, one per feature, no collisions. Small features stay in chat and skip the file.
+- Implement, verify, and review each feature independently. `review-branch` writes a per-branch report at the main worktree root (`review/branch/review-<slug>.md`), and `ui-test` writes a per-branch checklist handoff there too (`tmp/ui-checklist/<slug>.md`) that `git-pr` posts to the pull request and removes, so parallel sessions do not overwrite each other. The slug is the branch name with any leading type segment dropped, so `feat/jwt-expiration` and the plan at `feature-jwt-expiration.md` meet on one name
 - Ship each worktree separately with `canon:git-ship`
-- For full autonomy per worktree, invoke `canon:claude-autoship` instead of the manual chain. Approve the plan, walk away, come back to a pull request the chain marked as a draft and then read the flag back on. The mark says the work has had no review yet, and it holds no window, since readying a pull request to merge lifts it and is the operator's act.
+- For full autonomy per worktree, invoke `canon:auto-ship` instead of the manual chain. Approve the plan, walk away, come back to a pull request the chain marked as a draft and then read the flag back on. The mark says the work has had no review yet, and it holds no window, since readying a pull request to merge lifts it and is the operator's act.
 
-To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `canon:claude-orchestrate`. It holds the cross-feature call, plans each feature itself or dispatches a cold planner under `canon:claude-planner` to write the plan, refills the ready queue so a free worker never waits, and reviews each worker's PR with `canon:claude-pr-review`, then tells the session holding that branch to run `canon:claude-address-review` whenever the pass posted a finding at any severity, which is the same threshold `canon:claude-pr-review` states and posts its open heading under. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
+To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `canon:role-orchestrator`. It holds the cross-feature call, plans each feature itself or dispatches a cold planner under `canon:role-planner` to write the plan, refills the ready queue so a free worker never waits, and reviews each worker's PR with `canon:review-pr`, then tells the session holding that branch to run `canon:review-address` whenever the pass posted a finding at any severity, which is the same threshold `canon:review-pr` states and posts its open heading under. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
 
 Execution order comes off `.canon/tasks/priority.md` and nothing sequences work into versions. Scope stays in `.claude/REQUIREMENTS.md` as a statement of what is wanted, and it reaches the board as discrete tasks the orchestrator orders by readiness.
 
@@ -110,9 +110,9 @@ A person points it at a private repository once and both verbs refuse until they
 
 A plan that ships is archived, never deleted. `canon tasks archive` moves it to `.canon/plans/archive/` alongside the task it belonged to and retargets that task's `Plan:` line at the new location, so a completed task still leads to the reasoning behind it. An archive sits inside the record folder it archives rather than beside it, so one ignore entry and one backed-folder entry cover a record and everything it has retired. The folder is gitignored, which is why a deleted plan had no recovery path. A plan cited by more than one task stays put until the last of them closes, since moving it early would strand every other pointer.
 
-A branch review report takes the other route and is swept rather than archived. `claude-review` writes it to `.canon/review/branch/`, the session addressing it reads it once, and the durable record of what a review found is the comment `claude-pr-review` posts on the pull request, so `claude-docs` deletes any report whose branch is gone. The body that writes a report owns how long it lives, which leaves the shipping branch's own report on disk through the run that cites it and collects it a branch later. What that loses is a local-only review on a branch that never opened a pull request, which is why the report says so where a reader meets it.
+A branch review report takes the other route and is swept rather than archived. `review-branch` writes it to `.canon/review/branch/`, the session addressing it reads it once, and the durable record of what a review found is the comment `review-pr` posts on the pull request, so `docs-fold` deletes any report whose branch is gone. The body that writes a report owns how long it lives, which leaves the shipping branch's own report on disk through the run that cites it and collects it a branch later. What that loses is a local-only review on a branch that never opened a pull request, which is why the report says so where a reader meets it.
 
-`canon:claude-docs` decides which task closed by reading the diff rather than the conversation. It resolves a merge base against `origin/main`, unions the committed diff with the working tree and untracked files, then matches unchecked outcomes on the board against what shipped. A task that shipped without ever being discussed still gets marked. Requirements, architecture, and design stay session-sourced, because a diff cannot carry a judgment.
+`canon:docs-fold` decides which task closed by reading the diff rather than the conversation. It resolves a merge base against `origin/main`, unions the committed diff with the working tree and untracked files, then matches unchecked outcomes on the board against what shipped. A task that shipped without ever being discussed still gets marked. Requirements, architecture, and design stay session-sourced, because a diff cannot carry a judgment.
 
 `.canon/tasks/` is gitignored and resolves at the main worktree root, so every session shares one board. One file per task is what keeps concurrent sessions from overwriting each other, since a gitignored board has no history to recover a lost write from. Its `index.md` is generated by a hook rather than by `bun run check`, because the whole-repo index walk skips gitignored folders.
 
@@ -122,19 +122,19 @@ A branch review report takes the other route and is swept rather than archived.
 
 Past that shape, it checks what a surviving row claims against what the tree holds: every plan pointer resolves, every task file is named by a board row or a backlog line and never by both, no task sits in two groups, and no two rows marked ready touch the same file. One check across both surfaces is what lets a task move between the board and the backlog without the move reading as a dropped file. The collision check is the half a reader cannot run by eye, and it is what keeps two workers from being handed colliding work. Blockers re-takes what a parked row waits on, reporting one whose cited task reached the trunk and one whose cited file nothing running still holds. A cited task settles the row by being archived, or by closing every outcome and naming a pull request the trunk carries, since the checkbox alone is marked while the branch is still in review. Both halves read a citation out of the blocker cell, so a row citing neither is reported as untested rather than counted clean, and so is a cited task the trunk could not answer for. It reports and never writes, because a row is the orchestrator's claim and a validator repairing one would assert the claim it exists to test. Nothing fires it automatically, since the board is gitignored per-machine scratch with no shared moment to hang a hook on, so the orchestrator's sweep calls it at the point the readiness claim is made and follows it with the parked re-test.
 
-`canon:claude-tasks` owns the two operations that bracket a task's life. It creates the file, holding the filename convention and the frontmatter contract so a malformed write cannot break the index for every sibling, and it moves a shipped task to `.canon/tasks/archive/`. Creation is where the origin invariant is enforced: every task names a plan, a groundwork folder, an intake folder, or an issue, since a task with no origin is either lost context or work nobody decided to do.
+`canon:task-board` owns the two operations that bracket a task's life. It creates the file, holding the filename convention and the frontmatter contract so a malformed write cannot break the index for every sibling, and it moves a shipped task to `.canon/tasks/archive/`. Creation is where the origin invariant is enforced: every task names a plan, a groundwork folder, an intake folder, or an issue, since a task with no origin is either lost context or work nobody decided to do.
 
 Archiving a task carries its plan with it, in the same act. The merge is what settles a plan, and the hook below reaches the archive with nobody watching, so a second call after it would be a second failure point leaving the task archived and the plan live. A task whose plan a sibling still cites archives on its own and leaves the plan live, since moving it on the first task to close strands every other pointer at a path that has gone.
 
-Nothing chained that archive until the `post-merge` git hook landed. Every earlier step fires from `canon:claude-autoship` or `canon:git-ship`, both of which finish while the pull request is still open, so a task archived there would close for work that may be abandoned. The board is gitignored, which rules out reading it from anywhere but the machine that pulled. The hook names the board's archive candidates and stays silent otherwise, including on a project with no board.
+Nothing chained that archive until the `post-merge` git hook landed. Every earlier step fires from `canon:auto-ship` or `canon:git-ship`, both of which finish while the pull request is still open, so a task archived there would close for work that may be abandoned. The board is gitignored, which rules out reading it from anywhere but the machine that pulled. The hook names the board's archive candidates and stays silent otherwise, including on a project with no board.
 
-Candidates rather than closed tasks, because outcomes are marked on the branch. A task can read all `[x]` while its pull request is still open, so `canon:claude-tasks` confirms the work reached `main` before it moves anything, and the hook's own output says that check is still owed. A companion `post-rewrite` hook carries the same announcement for anyone pulling with rebase, which fires that event instead of `post-merge`.
+Candidates rather than closed tasks, because outcomes are marked on the branch. A task can read all `[x]` while its pull request is still open, so `canon:task-board` confirms the work reached `main` before it moves anything, and the hook's own output says that check is still owed. A companion `post-rewrite` hook carries the same announcement for anyone pulling with rebase, which fires that event instead of `post-merge`.
 
-It announces and moves nothing, so `canon:claude-tasks` stays the only writer. A shell-side archive would change a gitignored board with no diff to review and no session watching, and `index.md` regenerates from a session hook that a shell `mv` never fires. Both hooks ship with the `base` tooling stack, so a target project running this workflow gets the same trigger.
+It announces and moves nothing, so `canon:task-board` stays the only writer. A shell-side archive would change a gitignored board with no diff to review and no session watching, and `index.md` regenerates from a session hook that a shell `mv` never fires. Both hooks ship with the `base` tooling stack, so a target project running this workflow gets the same trigger.
 
 ### Autonomous ship
 
-For features on a mature stack, chain the post-plan pipeline in one session. Approve the plan, invoke `canon:claude-autoship`, and the skill runs implement → verify → review → ship sequentially.
+For features on a mature stack, chain the post-plan pipeline in one session. Approve the plan, invoke `canon:auto-ship`, and the skill runs implement → verify → review → ship sequentially.
 
 - Use when the plan is tight and the stack has real verify commands and test coverage
 - Autoship stops on: verify failure after one fix attempt, UI manual checklist non-empty, an inherited review finding above minor, no diff baseline resolving against `main`, an empty changed-file list, or hook failure
@@ -147,7 +147,7 @@ Review findings split by origin before severity is read. One the branch inherite
 
 Review is skipped when the diff is prose that only informs: every changed file matches `*.md` or `*.txt`, and none sits under a behavior path. Behavior paths cover skills and rules in both the authoring and the installed spelling, so the list matches whether a repository authors those surfaces or consumed them from the toolkit. Standards, snippets, `internal/`, and `tooling/` carry the authoring spelling alone, since none of the four reaches a session through a `.claude/` copy, and root `CLAUDE.md` is named as a file because a path prefix reaches nothing sitting in no folder.
 
-Markdown under one states what an agent does, so a branch touching it reaches review while `docs/` and `wiki/` still skip and stay gated by `docs-sync`, `claude-standards-audit`, and pre-push hooks.
+Markdown under one states what an agent does, so a branch touching it reaches review while `docs/` and `wiki/` still skip and stay gated by `docs-sync`, `standards-audit`, and pre-push hooks.
 
 An empty changed-file list stops the chain rather than counting as prose-only. The filename test passes vacuously on an empty set, which routed a branch past review instead of through it.
 
@@ -157,19 +157,19 @@ The list stays written in the skill body as the fallback for a target whose inst
 
 #### Memory in the chain
 
-`git-ship` runs its verify gate and then opens on `claude-memory-capture`, which sends what the session learned to the surface that owns it. `autoship` reaches the same step by invoking that skill at its Step 8 rather than restating the order. A fact about a domain carrying an entry in `.claude/context/index.md` is routed to that entry, and `claude-docs` folds it in on the next step, so it ships in the same pull request. Anything no entry owns stays a file in `.canon/memory/`.
+`git-ship` runs its verify gate and then opens on `memory-capture`, which sends what the session learned to the surface that owns it. `autoship` reaches the same step by invoking that skill at its Step 8 rather than restating the order. A fact about a domain carrying an entry in `.claude/context/index.md` is routed to that entry, and `docs-fold` folds it in on the next step, so it ships in the same pull request. Anything no entry owns stays a file in `.canon/memory/`.
 
 Capture leads rather than trails because a routed fact edits a tracked file, which has to reach the branch before the commit steps run.
 
-If capture wrote at least one memory file, `claude-memory-review` then proposes a decision-ready fix scoped to those entries while context is fresh, otherwise it is skipped. It stops at Propose. Review the receipt and run Apply yourself, on its own commit separate from the feature.
+If capture wrote at least one memory file, `memory-review` then proposes a decision-ready fix scoped to those entries while context is fresh, otherwise it is skipped. It stops at Propose. Review the receipt and run Apply yourself, on its own commit separate from the feature.
 
-Run `claude-memory-review` standalone to curate the whole pen. An entry it retires moves to `.canon/tmp/memory-archive/` rather than being deleted, since the folder is gitignored and a bulk pass has no undo.
+Run `memory-review` standalone to curate the whole pen. An entry it retires moves to `.canon/tmp/memory-archive/` rather than being deleted, since the folder is gitignored and a bulk pass has no undo.
 
-The receipt is collected once every item on it has been decided, and it survives untouched while any item is still pending. Whichever runs first takes it: Apply collects the receipt it has resolved, and `claude-docs` scans the folder on every shipped branch for one an earlier session left behind. Before the file goes, each declined item is folded into the entry it was about, since a promotion survives in its target and in git while a decline is recorded nowhere else. `canon standards memory` states what a fold writes and which entry types take one.
+The receipt is collected once every item on it has been decided, and it survives untouched while any item is still pending. Whichever runs first takes it: Apply collects the receipt it has resolved, and `docs-fold` scans the folder on every shipped branch for one an earlier session left behind. Before the file goes, each declined item is folded into the entry it was about, since a promotion survives in its target and in git while a decline is recorded nowhere else. `canon standards memory` states what a fold writes and which entry types take one.
 
 ### UI polish
 
-Verify the change manually in the browser. Invoke `canon:claude-ui-test` if you need e2e tests and a visual verification checklist for the session. For the fix itself, describe the change in Claude Code directly.
+Verify the change manually in the browser. Invoke `canon:ui-test` if you need e2e tests and a visual verification checklist for the session. For the fix itself, describe the change in Claude Code directly.
 
 ### Quick fix
 
@@ -179,7 +179,7 @@ Verify the change manually in the browser. Invoke `canon:claude-ui-test` if you
 
 ### Review
 
-Invoke `canon:claude-review` at the start of session 2. It reads all changed files and outputs a findings report. Fix valid findings before invoking `canon:git-ship`. If nothing is valid, skip directly to ship.
+Invoke `canon:review-branch` at the start of session 2. It reads all changed files and outputs a findings report. Fix valid findings before invoking `canon:git-ship`. If nothing is valid, skip directly to ship.
 
 ### UI-heavy project
 
@@ -193,92 +193,92 @@ This section is the corpus the coverage claim is measured against: every name `c
 
 ### Set up a project
 
-| Skill                         | When to use                                                                                                     |
-| ----------------------------- | --------------------------------------------------------------------------------------------------------------- |
-| `canon:setup-init`            | On a fresh scaffold, to detect the stack and run the whole install chain in one pass                            |
-| `canon:canon-operator`        | On a project that already exists, to read what it carries before an install is picked                           |
-| `canon:setup-gov`             | When the governance rules are wanted without the tooling chain                                                  |
-| `canon:setup-indexes`         | When a markdown-heavy folder needs an `index.md` a session can browse                                           |
-| `canon:setup-plugins`         | On a new machine, to install the community and official plugins user-scoped                                     |
-| `canon:setup-verify`          | After the agent generates configs, to run the installed scripts and report pass or fail                         |
-| `canon:setup-smoke`           | After `setup-verify` passes, to check the dev and preview servers, end-to-end tests, and the screenshot harness |
-| `canon:claude-design-extract` | Before the first UI feature, to draft `.claude/DESIGN.md`                                                       |
-| `canon:claude-diagram`        | Once the architecture is written, to draft per-kind entries under `.canon/diagrams/`                            |
-| `canon:repo-metadata`         | When the GitHub About text, homepage, or topics may have drifted, to reconcile them against the README          |
+| Skill                  | When to use                                                                                                     |
+| ---------------------- | --------------------------------------------------------------------------------------------------------------- |
+| `canon:setup-init`     | On a fresh scaffold, to detect the stack and run the whole install chain in one pass                            |
+| `canon:canon-operator` | On a project that already exists, to read what it carries before an install is picked                           |
+| `canon:setup-gov`      | When the governance rules are wanted without the tooling chain                                                  |
+| `canon:setup-indexes`  | When a markdown-heavy folder needs an `index.md` a session can browse                                           |
+| `canon:setup-plugins`  | On a new machine, to install the community and official plugins user-scoped                                     |
+| `canon:setup-verify`   | After the agent generates configs, to run the installed scripts and report pass or fail                         |
+| `canon:setup-smoke`    | After `setup-verify` passes, to check the dev and preview servers, end-to-end tests, and the screenshot harness |
+| `canon:design-extract` | Before the first UI feature, to draft `.claude/DESIGN.md`                                                       |
+| `canon:draft-diagram`  | Once the architecture is written, to draft per-kind entries under `.canon/diagrams/`                            |
+| `canon:repo-metadata`  | When the GitHub About text, homepage, or topics may have drifted, to reconcile them against the README          |
 
 ### Decide what to build
 
-| Skill                        | When to use                                                                     |
-| ---------------------------- | ------------------------------------------------------------------------------- |
-| `canon:claude-intake`        | When the input is a pile of findings rather than one feature                    |
-| `canon:claude-intake-answer` | When an intake folder holds unread slots waiting on your decision               |
-| `canon:claude-groundwork`    | When the state is unmeasured and more than one approach is live                 |
-| `canon:decision-escalate`    | When open decisions turn on your preference and want batching into one set      |
-| `canon:draft-and-pick`       | When the call is taste and wants several candidates rendered side by side       |
-| `canon:claude-tasks`         | When a decided item needs a file on the board, or a shipped one needs archiving |
-| `canon:claude-feature`       | When the approach is settled and the next step is a plan                        |
+| Skill                      | When to use                                                                     |
+| -------------------------- | ------------------------------------------------------------------------------- |
+| `canon:plan-intake`        | When the input is a pile of findings rather than one feature                    |
+| `canon:plan-intake-answer` | When an intake folder holds unread slots waiting on your decision               |
+| `canon:plan-groundwork`    | When the state is unmeasured and more than one approach is live                 |
+| `canon:decision-escalate`  | When open decisions turn on your preference and want batching into one set      |
+| `canon:draft-and-pick`     | When the call is taste and wants several candidates rendered side by side       |
+| `canon:task-board`         | When a decided item needs a file on the board, or a shipped one needs archiving |
+| `canon:plan-feature`       | When the approach is settled and the next step is a plan                        |
 
 ### Build the feature
 
 | Skill                        | When to use                                                               |
 | ---------------------------- | ------------------------------------------------------------------------- |
-| `canon:claude-worktree`      | At the plan-to-execute boundary, to get an isolated tree and branch       |
-| `canon:claude-autoship`      | After plan approval, to chain implement, verify, review, draft PR         |
+| `canon:session-worktree`     | At the plan-to-execute boundary, to get an isolated tree and branch       |
+| `canon:auto-ship`            | After plan approval, to chain implement, verify, review, draft PR         |
 | `canon:project-commands`     | When the project's own command needs running                              |
 | `canon:test-first`           | Before implementing a planned change, to write and run its test red first |
 | `canon:systematic-debugging` | When a test fails or a bug surfaces, to force root cause first            |
-| `canon:claude-ui-test`       | After a UI change, to generate e2e tests and a visual checklist           |
+| `canon:ui-test`              | After a UI change, to generate e2e tests and a visual checklist           |
 
 ### Check the work before it leaves the branch
 
-| Skill                           | When to use                                                                             |
-| ------------------------------- | --------------------------------------------------------------------------------------- |
-| `canon:claude-review`           | On the local branch diff, before anything is pushed                                     |
-| `canon:claude-standards-audit`  | When changed markdown has to answer to the authoring standards                          |
-| `canon:claude-markdown-propose` | When a markdown claim needs rewriting and the change should wait for an answer per file |
-| `canon:claude-ux-audit`         | To read UI source for missing states, edge cases, and inconsistencies                   |
-| `canon:claude-ux-measure`       | To start the interface and measure paint, processor, and layout cost                    |
+| Skill                    | When to use                                                                             |
+| ------------------------ | --------------------------------------------------------------------------------------- |
+| `canon:review-branch`    | On the local branch diff, before anything is pushed                                     |
+| `canon:standards-audit`  | When changed markdown has to answer to the authoring standards                          |
+| `canon:markdown-propose` | When a markdown claim needs rewriting and the change should wait for an answer per file |
+| `canon:ux-audit`         | To read UI source for missing states, edge cases, and inconsistencies                   |
+| `canon:ux-measure`       | To start the interface and measure paint, processor, and layout cost                    |
 
 ### Ship it
 
-| Skill                         | When to use                                                                           |
-| ----------------------------- | ------------------------------------------------------------------------------------- |
-| `canon:git-ship`              | To run the whole post-feature chain from the verify gate through open PR              |
-| `canon:claude-memory-capture` | First skill in that chain, to route what the session learned to the surface owning it |
-| `canon:claude-docs`           | When decisions diverged from the plan, or a shipped task needs its outcomes marked    |
-| `canon:docs-sync`             | When a change since main left `README.md` or `docs/` stale                            |
-| `canon:git-stage`             | When the staged set spans several concerns and wants one commit each                  |
-| `canon:git-commit`            | When the staged set is one concern, or was staged hunk by hand                        |
-| `canon:git-branch`            | When a branch name needs generating or renaming to conventional form                  |
-| `canon:git-pr`                | When a pull request needs a title and body written from the diff                      |
-| `canon:claude-memory-review`  | After capture writes an entry, to propose where each one belongs                      |
+| Skill                  | When to use                                                                           |
+| ---------------------- | ------------------------------------------------------------------------------------- |
+| `canon:git-ship`       | To run the whole post-feature chain from the verify gate through open PR              |
+| `canon:memory-capture` | First skill in that chain, to route what the session learned to the surface owning it |
+| `canon:docs-fold`      | When decisions diverged from the plan, or a shipped task needs its outcomes marked    |
+| `canon:docs-sync`      | When a change since main left `README.md` or `docs/` stale                            |
+| `canon:git-stage`      | When the staged set spans several concerns and wants one commit each                  |
+| `canon:git-commit`     | When the staged set is one concern, or was staged hunk by hand                        |
+| `canon:git-branch`     | When a branch name needs generating or renaming to conventional form                  |
+| `canon:git-pr`         | When a pull request needs a title and body written from the diff                      |
+| `canon:memory-review`  | After capture writes an entry, to propose where each one belongs                      |
 
 ### After the pull request opens
 
-| Skill                         | When to use                                                          |
-| ----------------------------- | -------------------------------------------------------------------- |
-| `canon:claude-pr-review`      | From an independent session, to post findings on the PR itself       |
-| `canon:claude-address-review` | On the worker's side, to fix posted findings and push a follow-up    |
-| `canon:git-followup`          | For a small self-review edit on a branch whose PR is already open    |
-| `canon:git-split`             | When a branch turns out to carry unrelated commits                   |
-| `canon:git-issue`             | When something surfaced that belongs on the tracker rather than here |
-| `canon:git-worktree`          | After a PR merges, to list worktrees and reclaim the slot            |
+| Skill                  | When to use                                                          |
+| ---------------------- | -------------------------------------------------------------------- |
+| `canon:review-pr`      | From an independent session, to post findings on the PR itself       |
+| `canon:review-address` | On the worker's side, to fix posted findings and push a follow-up    |
+| `canon:git-followup`   | For a small self-review edit on a branch whose PR is already open    |
+| `canon:git-split`      | When a branch turns out to carry unrelated commits                   |
+| `canon:git-issue`      | When something surfaced that belongs on the tracker rather than here |
+| `canon:git-worktree`   | After a PR merges, to list worktrees and reclaim the slot            |
 
 ### Run several tracks at once
 
-| Skill                      | When to use                                                                     |
-| -------------------------- | ------------------------------------------------------------------------------- |
-| `canon:claude-orchestrate` | To assert the control session that owns the queue and reviews each worker's PR  |
-| `canon:claude-planner`     | To assert the planner role for a cold session writing one plan under one task   |
-| `canon:claude-worker`      | To assert the worker role for a cold session building one branch under one plan |
-| `canon:session-resume`     | At the start of a session, to pick up what a previous one left                  |
-| `canon:session-map`        | At the close of a session, to write the handoff a compaction would destroy      |
+| Skill                     | When to use                                                                     |
+| ------------------------- | ------------------------------------------------------------------------------- |
+| `canon:role-orchestrator` | To assert the control session that owns the queue and reviews each worker's PR  |
+| `canon:role-planner`      | To assert the planner role for a cold session writing one plan under one task   |
+| `canon:role-worker`       | To assert the worker role for a cold session building one branch under one plan |
+| `canon:session-resume`    | At the start of a session, to pick up what a previous one left                  |
+| `canon:session-map`       | At the close of a session, to write the handoff a compaction would destroy      |
 
 ### Keep the project current with the toolkit
 
 | Skill                            | When to use                                                                        |
 | -------------------------------- | ---------------------------------------------------------------------------------- |
-| `canon:claude-seed-sync`         | After a toolkit update, to reconcile installed seeds without losing customizations |
+| `canon:seed-sync`                | After a toolkit update, to reconcile installed seeds without losing customizations |
 | `canon:migration-claude-md`      | When `CLAUDE.md` grew past what always-load context should carry                   |
 | `canon:migration-context`        | When `docs/` holds agent-flavored files belonging in `.claude/context/`            |
 | `canon:migration-superseded`     | When a drift report names a `.claude/` file a folder has replaced                  |
@@ -315,13 +315,13 @@ This section is the corpus the coverage claim is measured against: every name `c
 | `canon:index-lookup`        | To find where a topic is documented across the tracked `index.md` catalogs                                                                                             |
 | `canon:youtube-transcripts` | When a video transcript is wanted in the repo as context                                                                                                               |
 | `canon:canon-frames-read`   | To read a recorded demo back frame by frame and report what each one shows, with no verdict on whether the recording looks right                                       |
-| `canon:claude-teach`        | To learn a subject across sessions, in a workspace that holds the progress                                                                                             |
+| `canon:teach-workspace`     | To learn a subject across sessions, in a workspace that holds the progress                                                                                             |
 | `canon:write-human`         | Before drafting or revising prose, for voice, rhythm, and density                                                                                                      |
 | `canon:restate-plainly`     | When an answer or a document has to be read again in plain words                                                                                                       |
 
 Every row answers a question rather than marking a point in a project's life, so a phase above would send a reader to the wrong group.
 
-A learning workspace produces two halves and only one of them leaves. A lesson is worked through once and stays in the workspace, and a reference page or a glossary carries no learner, so it belongs wherever the project already keeps prose on that subject. Asking `canon:claude-teach` to promote sorts each durable page by who owns its subject, sending an outside subject to the wiki, an internal one to the matching context entry, and consumer-facing material to the public docs. It proposes and waits, because a promoted page is public prose that needs a line naming who owns the subject, and it writes nothing to a destination: each page the operator confirms goes to a handoff file that `canon:claude-docs` folds in from a branch. A project with no wiki folder gets a refusal naming `canon wiki init` rather than a folder it never asked for.
+A learning workspace produces two halves and only one of them leaves. A lesson is worked through once and stays in the workspace, and a reference page or a glossary carries no learner, so it belongs wherever the project already keeps prose on that subject. Asking `canon:teach-workspace` to promote sorts each durable page by who owns its subject, sending an outside subject to the wiki, an internal one to the matching context entry, and consumer-facing material to the public docs. It proposes and waits, because a promoted page is public prose that needs a line naming who owns the subject, and it writes nothing to a destination: each page the operator confirms goes to a handoff file that `canon:docs-fold` folds in from a branch. A project with no wiki folder gets a refusal naming `canon wiki init` rather than a folder it never asked for.
 
 ## Feedback routing
 

package/docs/workflow/operating-model.md

@@ -25,10 +25,10 @@ The split is by vantage, not by capability. All three are Claude Code sessions.
 | Worker       | One cold worktree session per feature | Implement, self-check, open PR, answer the orchestrator | Write the shared board, merge     |
 
 Each role is asserted explicitly rather than inferred. The orchestrator loads
-`claude-orchestrate` at the start of its session, a worker loads `claude-worker`,
-which `claude-autoship` invokes at Step 0 so a dispatched build and a
+`role-orchestrator` at the start of its session, a worker loads `role-worker`,
+which `auto-ship` invokes at Step 0 so a dispatched build and a
 hand-launched one reach it on the same path, and a planner loads
-`claude-planner` from the launch that dispatches it. All three are framing and
+`role-planner` from the launch that dispatches it. All three are framing and
 boundaries rather than logic.
 
 The planner is the one role the orchestrator also performs. Per-row planning
@@ -77,12 +77,12 @@ start, and only a count of the defect's extent decides how big it is.
 
 One feature travels this path end to end.
 
-1. The next feature is planned with `claude-feature`, writing a plan to `.canon/plans/`. The orchestrator runs it warm when the row turns on a contract other features consume or a shared wiring seam, and dispatches a planner under `claude-planner` otherwise. A cold planner measures the row against the tree rather than trusting what the row claims, and it reads what is in flight by composing the live session roster with open pull requests. A bare branch or worktree is not evidence on its own, since this repository leaves both behind after a squash merge.
-2. Orchestrator checks the plan waits on nobody, checks the branch is unclaimed, and checks the plan's file set is disjoint from every track in flight, then dispatches a background worker with `claude --bg` against the plan, naming the branch and the model on the launch rather than leaving the worker to derive either. No count caps how many run at once. The branch travels as the argument to the worker's own worktree call, which is the one place the name is read rather than inferred. It falls back to naming the invocation for a human to run through `claude-worktree` and `claude-autoship` when the plan still waits on an answer only the operator can give, the check refuses, the sets overlap, or a stated reason serializes the plan behind a track already in flight. Either way, the worker enters its own worktree, builds, self-checks, opens a PR, and stops at the PR boundary.
-3. Orchestrator reviews the PR with `claude-pr-review` and posts findings to it.
-4. Orchestrator tells the session holding that branch to run `claude-address-review` once the pass posted a finding at any severity, resolving the target then with `canon sessions list --branch` and reporting the invocation for the human when no live session holds it. The worker addresses the findings, rebases onto `origin/main` when a sibling landed first and left the branch unable to merge, then pushes a follow-up. A pass carrying only minor findings dispatches too, since the grade runs low often enough that a floor at should-fix loses fixes a worker would have made. `claude-pr-review` states that threshold and the heading follows it, so an open heading is itself the signal to send.
-5. Orchestrator closes the review out with `claude-pr-review` again. The second pass reads only the commits the follow-up added, or the worker's response alone when the follow-up added none, and posts under `## Review` when it finds anything and under `## Review closed` when it finds nothing, so a reader learns from the heading whether work is still owed and takes the merge decision from the counts on the line under it. A pass finding nothing where a close-out already stands rewrites that comment to cover what it read rather than posting a second one, so the thread carries one live verdict. Repeat from step 4 until a pass closes the review.
-6. The human reads the result and merges. The orchestrator tells any trailing worker whose branch shares a seam with the merged one to run `claude-address-review`, which rebases whether or not the review left anything open.
+1. The next feature is planned with `plan-feature`, writing a plan to `.canon/plans/`. The orchestrator runs it warm when the row turns on a contract other features consume or a shared wiring seam, and dispatches a planner under `role-planner` otherwise. A cold planner measures the row against the tree rather than trusting what the row claims, and it reads what is in flight by composing the live session roster with open pull requests. A bare branch or worktree is not evidence on its own, since this repository leaves both behind after a squash merge.
+2. Orchestrator checks the plan waits on nobody, checks the branch is unclaimed, and checks the plan's file set is disjoint from every track in flight, then dispatches a background worker with `claude --bg` against the plan, naming the branch and the model on the launch rather than leaving the worker to derive either. No count caps how many run at once. The branch travels as the argument to the worker's own worktree call, which is the one place the name is read rather than inferred. It falls back to naming the invocation for a human to run through `session-worktree` and `auto-ship` when the plan still waits on an answer only the operator can give, the check refuses, the sets overlap, or a stated reason serializes the plan behind a track already in flight. Either way, the worker enters its own worktree, builds, self-checks, opens a PR, and stops at the PR boundary.
+3. Orchestrator reviews the PR with `review-pr` and posts findings to it.
+4. Orchestrator tells the session holding that branch to run `review-address` once the pass posted a finding at any severity, resolving the target then with `canon sessions list --branch` and reporting the invocation for the human when no live session holds it. The worker addresses the findings, rebases onto `origin/main` when a sibling landed first and left the branch unable to merge, then pushes a follow-up. A pass carrying only minor findings dispatches too, since the grade runs low often enough that a floor at should-fix loses fixes a worker would have made. `review-pr` states that threshold and the heading follows it, so an open heading is itself the signal to send.
+5. Orchestrator closes the review out with `review-pr` again. The second pass reads only the commits the follow-up added, or the worker's response alone when the follow-up added none, and posts under `## Review` when it finds anything and under `## Review closed` when it finds nothing, so a reader learns from the heading whether work is still owed and takes the merge decision from the counts on the line under it. A pass finding nothing where a close-out already stands rewrites that comment to cover what it read rather than posting a second one, so the thread carries one live verdict. Repeat from step 4 until a pass closes the review.
+6. The human reads the result and merges. The orchestrator tells any trailing worker whose branch shares a seam with the merged one to run `review-address`, which rebases whether or not the review left anything open.
 
 There is no loop construct here. Each worker is a single build that halts at the
 PR. The merge stays a manual human gate. Reliability comes from the plan being
@@ -94,8 +94,8 @@ from merging promptly so the next PR does not rot against a moving main.
 The worker's self-review and the orchestrator's review are not the same pass run
 twice. They differ by vantage.
 
-- Worker self-review, inside `claude-autoship`: the session that wrote the code. Its job is "did I build the plan and does it pass?" Mechanical, and structurally blind to its own misreadings, because the same misreading wrote both the code and the review. This is the green gate that decides whether the PR opens.
-- Orchestrator review, via `claude-pr-review`: a fresh session with cross-feature context (the board, a sibling PR in flight, a downstream contract). Its job is "is this right and does it fit?" It can question the plan itself. This is the merge gate.
+- Worker self-review, inside `auto-ship`: the session that wrote the code. Its job is "did I build the plan and does it pass?" Mechanical, and structurally blind to its own misreadings, because the same misreading wrote both the code and the review. This is the green gate that decides whether the PR opens.
+- Orchestrator review, via `review-pr`: a fresh session with cross-feature context (the board, a sibling PR in flight, a downstream contract). Its job is "is this right and does it fit?" It can question the plan itself. This is the merge gate.
 
 They collide only if the worker also runs a deep pass. Keep the worker's review
 light and let the orchestrator own the deep, independent one. The human read at
@@ -111,9 +111,9 @@ the body rather than on a file. See
 
 ## The review channel
 
-Findings travel on the PR. `claude-pr-review` posts them there.
-`claude-address-review` reads them back, fixes each, replies or resolves the
-threads, and pushes a follow-up. `claude-pr-review` then runs again, reading only
+Findings travel on the PR. `review-pr` posts them there.
+`review-address` reads them back, fixes each, replies or resolves the
+threads, and pushes a follow-up. `review-pr` then runs again, reading only
 what the follow-up added.
 
 Both halves of that loop key on a commit rather than on the pull request object,
@@ -175,18 +175,18 @@ a delta and names its body from that response instead of from a tree that did no
 change.
 
 A branch that stopped merging while the review was open is the worker's problem
-to close. `claude-address-review` rebases onto `origin/main` between the fixes
+to close. `review-address` rebases onto `origin/main` between the fixes
 and the push, so one force-push carries both and the reviewer reads one delta.
 The staleness test sits ahead of the no-findings guard, so a branch whose review
 closed clean and then went stale still rebases when the skill is invoked. The
 re-read costs a full pass rather than a delta, since the prior reviewed commit no
-longer reaches the head, and `claude-pr-review` detects that itself.
+longer reaches the head, and `review-pr` detects that itself.
 
 The heading carries the state rather than the pass number. A pass carrying
 anything owed takes `## Review` and a pass carrying nothing takes
 `## Review closed`, so a thread can be scanned for what still owes work without
 opening a comment. One threshold governs the heading and the dispatch alike, and
-`claude-pr-review` is where it is stated, so every other surface cites that skill
+`review-pr` is where it is stated, so every other surface cites that skill
 rather than restating the grades.
 
 The merge decision comes off the counts on the summary line, since an open

package/docs/workflow/visual-design-workflow.md

@@ -22,7 +22,7 @@ Claude Code reads both and writes the implementation. Works for CLI tools, inter
 
 The toolkit seed in `tooling/claude/seeds/.claude/DESIGN.md` ships a token-table template with a starting set of roles, and `standards/design.md` carries the same tables under `## Template` with placeholder rows. The column headers are what the renderer parses, so they stay verbatim in either, while the rows and values are the project's own.
 
-The `canon:claude-design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from `.claude/REQUIREMENTS.md` and a `## Personality` paragraph when no UI code exists yet. `canon design render` writes an HTML plus CSS preview to `.canon/review/design/` for eyeballing the current system without leaving Claude Code. See `.claude/context/design.md`.
+The `canon:design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from `.claude/REQUIREMENTS.md` and a `## Personality` paragraph when no UI code exists yet. `canon design render` writes an HTML plus CSS preview to `.canon/review/design/` for eyeballing the current system without leaving Claude Code. See `.claude/context/design.md`.
 
 A project wanting the toolkit's own values rather than its own runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying the token set as custom properties and two components built on them. That file is toolkit-owned and `canon design sync` refreshes it, so a project overrides a value in `.claude/design/project/` instead, which sync never touches. Nothing arrives without that install, and the two channels are independent: a record drafted by the extract skill is the project's own, and the installed stylesheet is the toolkit's.
 
@@ -31,14 +31,14 @@ A cell no source anchors ends in `? verify`, and the preview shows that marker b
 ### Tools
 
 - None beyond Claude Code itself
-- Playwright CLI optional for verifying form submissions and interactive surfaces. See [`claude-ui-test`](../../claude/skills/claude-ui-test/SKILL.md).
+- Playwright CLI optional for verifying form submissions and interactive surfaces. See [`ui-test`](../../claude/skills/ui-test/SKILL.md).
 
 ### Skills
 
-- `canon:claude-design-extract` to draft `.claude/DESIGN.md`, from existing project signals or from requirements alone on day one
-- `canon:claude-ui-test` for e2e test generation after UI changes
-- `canon:claude-ux-audit` for UX gap detection on existing surfaces
-- `canon:claude-ux-measure` for what a running surface costs to paint, read against published thresholds
+- `canon:design-extract` to draft `.claude/DESIGN.md`, from existing project signals or from requirements alone on day one
+- `canon:ui-test` for e2e test generation after UI changes
+- `canon:ux-audit` for UX gap detection on existing surfaces
+- `canon:ux-measure` for what a running surface costs to paint, read against published thresholds
 - `canon:draft-and-pick` for a call settled by looking, drafting several candidates onto one page and taking your pick
 - `canon:identity` to draft a project's logo mark and compose it into an icon sequence and a social card, through `draft-and-pick`'s own render-and-pick loop
 - Anthropic's `frontend-design` plugin optional for light visual steering

package/governance/rules/core/045-memory.md

@@ -7,6 +7,6 @@ description: Keep memory writes scoped to .canon/memory/ and out of context-owne
 ## Writing memory
 
 - Write all memory files to `.canon/memory/`, not `~/.claude/projects/`
-- A fact about a domain goes to that domain's `.claude/context/` entry, not to memory. `canon:claude-memory-capture` routes it there and `canon:claude-docs` folds it in. Memory keeps only what no context entry owns. Report it rather than proceeding silently when either skill does not resolve. Both ship with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have them.
+- A fact about a domain goes to that domain's `.claude/context/` entry, not to memory. `canon:memory-capture` routes it there and `canon:docs-fold` folds it in. Memory keeps only what no context entry owns. Report it rather than proceeding silently when either skill does not resolve. Both ship with the plugin and this rule ships with the CLI, so a project that installed governance alone does not have them.
 - Never delete a memory entry. Retire one by moving it to `.canon/tmp/memory-archive/`. A bulk retire runs through the shell, where no file edit fires a path-scoped rule, and the folder is gitignored with nothing to recover from.
 - Follow the memory standard for the filename and type prefix, the frontmatter, the body shape each type carries, and the lifecycle. Read it with `canon standards memory`. Check every entry in the pen against that standard and fix what breaks it, since nothing keeps the folder conforming on its own.

package/governance/rules/core/085-worktrees.md

@@ -6,7 +6,7 @@ description: Route tracked-file writes and shared session scratch correctly from
 
 ## Entering a worktree
 
-- Implementation work runs in a linked worktree. From the main worktree, enter one with `/claude-worktree` before editing tracked files for a feature.
+- Implementation work runs in a linked worktree. From the main worktree, enter one with `/session-worktree` before editing tracked files for a feature.
 
 ## Shared session scratch
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "4.66.0",
+  "version": "4.68.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/scripts/core/regen-agent-fixture.sh

@@ -57,7 +57,7 @@ OUT="$PROJECT_ROOT/web/src/fixtures/agent-view.json"
 # Re-transcribe this table against a fresh listing rather than editing the
 # generated file.
 #
-# A planner belongs in this table as much as a worker does. `claude-planner`
+# A planner belongs in this table as much as a worker does. `role-planner`
 # forbids entering a worktree, so a planner registers on the default branch at
 # launch and stays there for its whole life, which is why the branch filter this
 # script used to carry dropped every one of them permanently rather than

package/scripts/core/regen-hero.sh

@@ -180,13 +180,13 @@ const sample = (names) => {
 // reading as an all-`claude-` catalog, which is the failure the sampler above
 // was written against.
 const FEATURED_SKILLS = [
-  "claude-feature",
-  "claude-groundwork",
-  "claude-intake",
-  "claude-orchestrate",
-  "claude-autoship",
-  "claude-pr-review",
-  "claude-tasks",
+  "plan-feature",
+  "plan-groundwork",
+  "plan-intake",
+  "role-orchestrator",
+  "auto-ship",
+  "review-pr",
+  "task-board",
   "git-ship",
   "setup-init",
   "systematic-debugging",

package/snippets/claude/decision-memo.md

@@ -1,4 +1,4 @@
-Produce a decision memo for a research or should-we question. This is the decision-heavy counterpart to `claude-feature`, which plans a build. Write one file per independent concern under `.canon/plans/feature-<slug>.md`, or answer inline when the plan is small. Use the same plans folder as `claude-feature`.
+Produce a decision memo for a research or should-we question. This is the decision-heavy counterpart to `plan-feature`, which plans a build. Write one file per independent concern under `.canon/plans/feature-<slug>.md`, or answer inline when the plan is small. Use the same plans folder as `plan-feature`.
 
 Read the current state from the code and docs before recommending. Do not assume it.
 

package/src/autoship/paths.ts

@@ -2,7 +2,7 @@
  * The surfaces where markdown states what an agent does, and the extensions
  * that read as prose, held as data one command parses.
  *
- * Lifted verbatim in content from the list `claude-autoship/SKILL.md` Step 5
+ * Lifted verbatim in content from the list `auto-ship/SKILL.md` Step 5
  * carried, which a session was asked to apply by hand. It failed that
  * application three times, so the set moved here and the body now calls a verb
  * that reads it. Being machine-parsed makes it permanently exempt from any

package/src/claude/cases/all.ts

@@ -1,9 +1,9 @@
 import type { SkillCase } from '@/claude/skills-rank'
 import { AUTHORING_CASES } from '@/claude/cases/authoring'
-import { CLAUDE_WORKFLOW_CASES } from '@/claude/cases/claude-workflow'
 import { GIT_CASES } from '@/claude/cases/git'
 import { MISC_CASES } from '@/claude/cases/misc'
 import { SETUP_CASES } from '@/claude/cases/setup'
+import { WORKFLOW_CASES } from '@/claude/cases/workflow'
 
 /**
  * The full routing case corpus, one file per domain so a description change
@@ -16,7 +16,7 @@ import { SETUP_CASES } from '@/claude/cases/setup'
  * for the extraction arm this corpus replaces as the shipped measure.
  */
 export const SKILL_CASES: readonly SkillCase[] = [
-  ...CLAUDE_WORKFLOW_CASES,
+  ...WORKFLOW_CASES,
   ...GIT_CASES,
   ...SETUP_CASES,
   ...AUTHORING_CASES,