@erclx/canon 4.67.0 → 4.69.0

package/claude/skills/{claude-orchestrate → role-orchestrator}/references/orchestrator-poll.md

@@ -11,7 +11,7 @@ Run the orchestrator's review trigger. The poll reports pull request movement an
 
 Start the poll on an open pull request and stop it when the last one merges with nothing else out. That is the whole condition and it resolves from `gh pr list` without asking the operator. A release pull request alone does not qualify, since its sweep carries no findings.
 
-A dispatch no longer starts it. The script reads pull requests and a building worker has none, so every interval between the launch and the push is a fixed cost returning nothing, measured as five consecutive runs reporting no movement across roughly fifteen minutes while one worker built. What replaces it is the worker announcing its own pull request the moment it opens one, per the `claude-worker` skill that session loads, which covers exactly the transition the poll cannot observe.
+A dispatch no longer starts it. The script reads pull requests and a building worker has none, so every interval between the launch and the push is a fixed cost returning nothing, measured as five consecutive runs reporting no movement across roughly fifteen minutes while one worker built. What replaces it is the worker announcing its own pull request the moment it opens one, per the `role-worker` skill that session loads, which covers exactly the transition the poll cannot observe.
 
 The dispatched-worker condition survives as a fallback rather than as a trigger. Start the poll against any dispatch still out after thirty minutes with no announcement, which is past the upper end of the ten to thirty minutes a row here takes. The announcement is newer than the narrowing it justifies, so a silent failure would otherwise leave a finished worker unnoticed the way one already sat idle for eighteen minutes, and the fallback keeps the cover a straight narrowing would have removed. `${CLAUDE_SKILL_DIR}/scripts/watch.sh` covers the same window at a lower cost, since it reads the roster alongside the pull request list and reports a worker that vanished as well as one that finished.
 
@@ -35,17 +35,17 @@ Resolve `${CLAUDE_SKILL_DIR}/scripts/poll.sh` to an absolute path and paste that
 Poll GitHub for pull request movement by running <POLL_SCRIPT>, then act on what it reports.
 
 - A release pull request, whatever state follows it: report it and stop. Its sweep carries no findings, so no pass is owed. Test this before any rule below, since a release pull request is reported OPENED like any other and would otherwise match that rule first.
-- MOVED or RESPONSE on a pull request I have already reviewed: run the canon:claude-pr-review skill on it immediately, narrow pass. Re-reviews read prior..head and gain nothing from waiting.
-- OPENED, or a pull request with no prior review pass: run the canon:claude-pr-review skill on it. A draft counts, since every pull request here opens as one and skipping drafts skips everything.
+- MOVED or RESPONSE on a pull request I have already reviewed: run the canon:review-pr skill on it immediately, narrow pass. Re-reviews read prior..head and gain nothing from waiting.
+- OPENED, or a pull request with no prior review pass: run the canon:review-pr skill on it. A draft counts, since every pull request here opens as one and skipping drafts skips everything.
 - SEEN: report it and stop. A pass already covers that head, whether it arrived out of band or before the poll first saw the pull request, so no review follows.
 - STALLED: read the last pass and report what it carried. The pass has sat open for hours with nothing following it, so a worker mid-task is already ruled out and the dispatch either never went out or the session holding it is gone. Confirm and re-send it under the dispatch rule below, whatever grades the pass carried. Do not re-run a review to correct the heading, since a pass on an unchanged head with no response behind it stops by design.
 - CONFLICT: report it and stop. The branch owner rebases, not this session.
 - UNMATCHED: report it and stop. A comment posted under a heading outside the known set reaches nobody automatically, so a person decides whether to answer it by hand or the set needs a sixth heading.
-- GONE: report it, then sweep the board by invoking the canon:claude-orchestrate skill and following its queue-refill sweep.
+- GONE: report it, then sweep the board by invoking the canon:role-orchestrator skill and following its queue-refill sweep.
 - A line starting `poll:`: report it verbatim and treat that pull request as unread this run. It is a failed query, not a state.
 - Nothing changed: say exactly "No movement." and nothing else.
 
-After any pass that posts a finding, at any severity, tell the session holding that branch to run the canon:claude-address-review skill. Resolve the target by running `canon sessions list --branch <branch> --json` at that moment, which scopes the match to this repository, then route on how many sessions it returned. Zero: report the invocation for me and dispatch nobody. Exactly one, with the confidence field reading "confirmed": address that name directly. Any other count, any other confidence, or a command that is missing or refuses: fall back to picking from a session listing, open by naming the worktree and branch you believe the reader holds, and ask to be corrected. Two sessions can hold one branch, so read the count rather than the first row. The threshold is stated once in the canon:claude-pr-review skill and governs the heading with it, so an open heading and an owed dispatch answer the same question and either one is enough to send.
+After any pass that posts a finding, at any severity, tell the session holding that branch to run the canon:review-address skill. Resolve the target by running `canon sessions list --branch <branch> --json` at that moment, which scopes the match to this repository, then route on how many sessions it returned. Zero: report the invocation for me and dispatch nobody. Exactly one, with the confidence field reading "confirmed": address that name directly. Any other count, any other confidence, or a command that is missing or refuses: fall back to picking from a session listing, open by naming the worktree and branch you believe the reader holds, and ask to be corrected. Two sessions can hold one branch, so read the count rather than the first row. The threshold is stated once in the canon:review-pr skill and governs the heading with it, so an open heading and an owed dispatch answer the same question and either one is enough to send.
 ```
 
 ## Reading the output
@@ -56,13 +56,13 @@ The script exits non-zero and classifies nothing when the open pull request list
 
 The baseline lives at `.canon/tmp/pr-poll/baseline.txt` under the main worktree root and is per-machine. A first run against a board already in flight reports each open pull request once before it settles.
 
-The five review headings the script matches are written by `claude-pr-review` and `claude-address-review`, and the whole set is stated once in the first. A project that posts its reviews under different headings edits the jq filters in the script to match, or every pull request reads as never reviewed.
+The five review headings the script matches are written by `review-pr` and `review-address`, and the whole set is stated once in the first. A project that posts its reviews under different headings edits the jq filters in the script to match, or every pull request reads as never reviewed.
 
 `UNMATCHED` is what a heading outside the five reaches, carried the same way `RESPONSE` is: a rising count against the baseline is what is new to this script, and the message names the heading so a person can tell whether to answer it by hand or add it to the set. It fires on a tracked pull request only, since a first sighting reports `SEEN` or `OPENED` and takes whatever count already sits on the thread as its starting baseline rather than flagging history the poll never watched.
 
-`RESPONSE` is qualified by recency as well as by count, so it means a reply the last pass has not already answered rather than one this script has not seen before. A worker answers a finding and the reviewing session posts its close-out seconds later, which is the ordinary handback rather than a race, so a count on its own reported the answered thread on the next run and the re-review it routed to stopped at its own guard. The state now fires when the newest reply is stamped later than the last pass, and on a pull request carrying no pass at all, which is a worker talking to nobody and worth the turn. A reply landing inside the same second as the pass is dropped, matching the comparison `claude-pr-review` makes on the same two fields.
+`RESPONSE` is qualified by recency as well as by count, so it means a reply the last pass has not already answered rather than one this script has not seen before. A worker answers a finding and the reviewing session posts its close-out seconds later, which is the ordinary handback rather than a race, so a count on its own reported the answered thread on the next run and the re-review it routed to stopped at its own guard. The state now fires when the newest reply is stamped later than the last pass, and on a pull request carrying no pass at all, which is a worker talking to nobody and worth the turn. A reply landing inside the same second as the pass is dropped, matching the comparison `review-pr` makes on the same two fields.
 
-`STALLED` is the one state the script derives from a heading rather than from a commit or a count, since `claude-pr-review` posts the open heading exactly when a dispatch is owed, per the threshold that skill states. The heading alone cannot carry it, because an open pass means a dispatch was owed and made, so the ordinary healthy thread is a worker still working. The age of that pass is the third test: the state fires when the open pass covers the head, nothing has followed it, and it is older than the `STALE_AFTER` seconds set at the top of the script. It reports once per entry and fires again after any commit or reply resets the thread. A project whose workers run longer than the default two hours raises that number.
+`STALLED` is the one state the script derives from a heading rather than from a commit or a count, since `review-pr` posts the open heading exactly when a dispatch is owed, per the threshold that skill states. The heading alone cannot carry it, because an open pass means a dispatch was owed and made, so the ordinary healthy thread is a worker still working. The age of that pass is the third test: the state fires when the open pass covers the head, nothing has followed it, and it is older than the `STALE_AFTER` seconds set at the top of the script. It reports once per entry and fires again after any commit or reply resets the thread. A project whose workers run longer than the default two hours raises that number.
 
 The state reaches every stalled dispatch, since one threshold governs the heading and the dispatch alike and a pass carrying anything posts the open heading. A minors-only pass therefore reports here on the same terms as a blocking one, which widens the state from what it caught while the two were split. It stays a heading test rather than a count test, so nothing here pins the summary line, which is a second string this script does not own.
 

package/claude/skills/{claude-orchestrate → role-orchestrator}/references/orchestrator-resume.md

@@ -21,7 +21,7 @@ Next: <the one or two tasks ready to hand a worker>
 
 Treat a groundwork folder as three kinds of content with different shelf lives. Trust the reasoning and the method, which stay correct. Re-measure every count, size, and cost, because they were true when written. Check every `Leaning:` against what has shipped, because work spawned by a track routinely overturns the lean that spawned it and nothing writes back.
 
-A plan a live task cites goes stale the same way, and `claude-orchestrate` states the check that catches it.
+A plan a live task cites goes stale the same way, and `role-orchestrator` states the check that catches it.
 
 After each merge, place every finding the work produced before starting anything else. A finding that changes a standard goes to the standard, one that changes another task goes to that task's Findings, and one that overturns a groundwork lean gets marked answered in that folder. Findings recorded in a pull request thread and nowhere else are lost at merge.
 

package/claude/skills/{claude-orchestrate → role-orchestrator}/references/orchestrator-sweep.md

@@ -6,7 +6,7 @@ description: The once-per-batch board sweep, plan re-verification, and where eac
 Sweep the board as orchestrator after merging. Run this once per batch of merges, before answering what to do next, because the surfaces that record what shipped are the ones nothing updates on its own.
 
 1. Pull into the main worktree rather than fetching. A fetch leaves the local branch behind, so `git log` reports a state that has not arrived. A repository that adds a post-merge hook to name archive candidates gets it on a pull and never on a fetch.
-2. Follow `## Refilling the ready queue` in `claude-orchestrate`, every step in order. It owns the procedure. Do not restate it here and do not run it from memory.
+2. Follow `## Refilling the ready queue` in `role-orchestrator`, every step in order. It owns the procedure. Do not restate it here and do not run it from memory.
 3. Re-verify every plan already written, not only the ones this sweep writes. A queued plan goes stale from whatever merged while it waited, and the loop's verify step fires at handoff rather than after a merge, so nothing else catches it. Grep each construct the plan names and count the sites against its claim, then open each file rather than trusting its account.
 4. Re-check any precondition a plan states about live state outside the repository. A remote branch, an open issue, or an installed version was true when the plan was written and is not a fact about the tree.
 

package/claude/skills/{claude-orchestrate → role-orchestrator}/scripts/poll.sh

@@ -32,9 +32,9 @@ if [ -z "$BASE_REF" ]; then
 fi
 BASE_BRANCH="${BASE_REF#origin/}"
 
-# These five strings are owned elsewhere and pinned here. `claude-pr-review`
+# These five strings are owned elsewhere and pinned here. `review-pr`
 # writes `## Review` and `## Review closed`, and states the full five-heading
-# set once, beside the threshold it already states once. `claude-address-review`
+# set once, beside the threshold it already states once. `review-address`
 # writes `## Review response`, `## Rebase`, and `## Post-review findings`, the
 # last for a finding a worker produces after a close-out rather than in answer
 # to one already on the thread. All three surfaces ship separately, so a
@@ -90,7 +90,7 @@ JQ_UNMATCHED_STATE='
     + (($unclassified | last) // "none")
 '
 
-# `claude-pr-review` states the threshold and posts `## Review` exactly when a
+# `review-pr` states the threshold and posts `## Review` exactly when a
 # pass carries a finding, so the heading of the last review is what says whether
 # any work is owed on it. Taking it as well as the commit is what separates a
 # thread waiting on a worker from one nothing is owed on. A project editing the
@@ -340,14 +340,14 @@ while read -r n head prior resp merges heading age pass_at reply_at unmatched_co
     # newer than the pass, and both are needed. A worker answers a finding and
     # the reviewing session closes out seconds later, so the count alone reports
     # an answered thread on the next run and the session spends a turn learning
-    # `claude-pr-review` will refuse it. The gaps observed were 96, 24, and 35
+    # `review-pr` will refuse it. The gaps observed were 96, 24, and 35
     # seconds, which is a reviewing session reading a reply and posting, so this
     # is the ordinary handback rather than a race.
     #
     # A pull request carrying no pass at all reads as stamp zero and reports,
     # which is the case the count was the right test for: a reply with nothing
     # behind it is a worker talking to nobody and worth the turn. The test is
-    # strictly greater to match the guard `claude-pr-review` states on the same
+    # strictly greater to match the guard `review-pr` states on the same
     # two fields, which drops a reply landing inside the same second as the
     # pass, a narrower failure than the one it removes.
     #
@@ -361,7 +361,7 @@ while read -r n head prior resp merges heading age pass_at reply_at unmatched_co
     # Three things at once: the last pass is open, it covers the head so no
     # commit followed it, and the two branches above found no reply either. The
     # open heading is posted exactly when a dispatch is owed, per the threshold
-    # `claude-pr-review` states, so a pass owing one left it here at any grade
+    # `review-pr` states, so a pass owing one left it here at any grade
     # it carried. Any two of these describe an ordinary review waiting on a
     # worker, which is why the age carries the third: without it every
     # dispatched worker is reported minutes into the work it was sent to do,

package/claude/skills/{claude-planner → role-planner}/REQUIREMENT.md

@@ -1,18 +1,18 @@
 ---
-name: claude-planner
+name: role-planner
 description: What a planning session is, how it reads what is in flight, the surfaces it may not write, and what it hands back to whoever dispatched it
 ---
 
-# Claude planner requirement
+# Role planner requirement
 
 ## Gap
 
 Without this skill, a planning session is told what to plan and never what it
-is. `claude-worker` states the building role and `claude-autoship` Step 0 reaches
+is. `role-worker` states the building role and `auto-ship` Step 0 reaches
 it on every build, so a builder takes a role whether a person launched it or a
 dispatcher did. Planning has no equivalent, and two trials on 2026-08-31 ran
 entirely on prose the controller retyped into each launch. That is the shape
-`claude-orchestrate` already bans on the building side, where one half held the
+`role-orchestrator` already bans on the building side, where one half held the
 only written copy of obligations the other half performs.
 
 Six rules went into each of those launches by hand: no worktree, no branch, no
@@ -49,7 +49,7 @@ four carried at least one, caught only because the planner ran
 
 ## Must
 
-- Assert what a planning session is, what it may not write, and how long the role lasts, since `claude-feature` carries the procedure and no body carries the role
+- Assert what a planning session is, what it may not write, and how long the role lasts, since `plan-feature` carries the procedure and no body carries the role
 - State the in-flight read as a command composing the session roster with open pull requests, and say that a branch and a worktree are not evidence, since a count of either reported merged work as live
 - Run that read once per task rather than once per batch, since a reused session ages its picture of the tree while it works
 - Name every read a plan needed and a launch string did not carry, the task file's findings and the source files among them, since a count quoted from a row was wrong or stale in ten places across four plans
@@ -58,17 +58,17 @@ four carried at least one, caught only because the planner ran
 - Owe an announcement when the plan lands, carrying the path and what the row got wrong, since the controller cannot watch the read happen
 - Owe a message before a block becomes an interactive prompt, since a session already waiting on input never reaches the tool round an inbound message drains at
 - Keep correcting the dispatcher a first-class move carrying its evidence, since a trial corrected a brief's premise, planned every row anyway, and carried the consequence into a plan question
-- Point at `claude-feature` for the plan's shape and the steps that write it
+- Point at `plan-feature` for the plan's shape and the steps that write it
 
 ## Must not
 
-- Restate the plan's sections, its suggested-and-answer contract, or the steps `claude-feature` carries, since thinness is what keeps one body correct for a dispatched planner reading it as its whole contract
-- Restate a boundary `claude-orchestrate` or `claude-worker` states about itself
+- Restate the plan's sections, its suggested-and-answer contract, or the steps `plan-feature` carries, since thinness is what keeps one body correct for a dispatched planner reading it as its whole contract
+- Restate a boundary `role-orchestrator` or `role-worker` states about itself
 - Tell a planner to halt on a plan question, which the suggested line already answers, rather than on what blocks writing the plan at all
 - Tell a planner to report the path with no account of what the row got wrong. That instruction came from a trial condition holding a blind comparison intact, and it is not a durable obligation.
 - Report progress through the channel, which rebuilds on the sender's side the poll the announcement exists to retire
 - Write the priority board, the backlog, or the task file, at any size
-- Be a skill nothing invokes but its author typing the name. `orchestrator-dispatch.md` names it on the planning launch the way it names `claude-worker` on a build, so a stretch where only a typed invocation reaches it is the signal that the role never took.
+- Be a skill nothing invokes but its author typing the name. `orchestrator-dispatch.md` names it on the planning launch the way it names `role-worker` on a build, so a stretch where only a typed invocation reaches it is the signal that the role never took.
 
 ## Guards
 
@@ -79,7 +79,7 @@ four carried at least one, caught only because the planner ran
 
 ## Out of scope
 
-- The plan's sections and its answer contract, which `standards/plan.md` fixes, and the steps that write the file, which `claude-feature` owns
-- The branch, the build, and the pull request, which `claude-worker` and `claude-autoship` own
-- Deciding which rows run and in what order, which is the controlling session's call and stated in `claude-orchestrate`
+- The plan's sections and its answer contract, which `standards/plan.md` fixes, and the steps that write the file, which `plan-feature` owns
+- The branch, the build, and the pull request, which `role-worker` and `auto-ship` own
+- Deciding which rows run and in what order, which is the controlling session's call and stated in `role-orchestrator`
 - The dispatch itself, its collision check, and its disjointness gate, which `orchestrator-dispatch.md` holds

package/claude/skills/{claude-planner → role-planner}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-planner
-description: Asserts the planner role for a session writing one plan under one task, holding what it reads before deciding, the surfaces it may not write, and what it hands back. Use when asked to "be the planner", "you are a planner session", at the start of a dispatched or hand-launched planning run, or when a planning session needs to know what it may not write. Do NOT use to write the plan itself, which is `claude-feature`, to make the cross-feature merge call, or to implement.
+name: role-planner
+description: Asserts the planner role for a session writing one plan under one task, holding what it reads before deciding, the surfaces it may not write, and what it hands back. Use when asked to "be the planner", "you are a planner session", at the start of a dispatched or hand-launched planning run, or when a planning session needs to know what it may not write. Do NOT use to write the plan itself, which is `plan-feature`, to make the cross-feature merge call, or to implement.
 ---
 
-# Claude planner
+# Role planner
 
 This session is a planner: one session writing one plan for one task. It reads
 the row, measures what the row claims against the tree, writes the plan, and
@@ -14,7 +14,7 @@ not review. Those belong to a worker, to the controlling session, and to the
 human.
 
 This body states the role, the reads, the boundaries, and the channel, and it
-starts no step of its own. `claude-feature` owns the steps that write the plan
+starts no step of its own. `plan-feature` owns the steps that write the plan
 and cites the standard fixing its sections and its suggested-and-answer
 contract, so read the procedure there and reach it from the launch rather than
 from here.

package/claude/skills/{claude-worker → role-worker}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-worker
+name: role-worker
 description: What a building session is, the shared surfaces it may not write, and the two messages it owes the session that dispatched it
 ---
 
-# Claude worker requirement
+# Role worker requirement
 
 ## Gap
 
@@ -29,7 +29,7 @@ Nothing tells the session that refusing is allowed either. Four occasions across
 - Name the addressee as the session the launch named, falling back to the roster and saying so, since an operator's own launch names nobody
 - Keep refusing a dispatcher a first-class move carrying its evidence, since the halts measured so far were correct and the cost of each fell where it belonged
 - State that a held body may be older than the branch under it, since a plugin skill loads from the marketplace cache rather than from the working tree
-- Point at `claude-worktree`, `claude-autoship`, and `claude-address-review` for the steps each already owns
+- Point at `session-worktree`, `auto-ship`, and `review-address` for the steps each already owns
 
 ## Must not
 
@@ -37,7 +37,7 @@ Nothing tells the session that refusing is allowed either. Four occasions across
 - Restate a boundary the orchestrator already states about itself
 - Report progress through the channel, which rebuilds on the sender's side the poll the announcement exists to retire
 - Write the priority board or the backlog, at any size
-- Be a skill nothing invokes but its author typing the name. `claude-autoship` Step 0 invokes it on every build, dispatched or hand-launched, so a stretch where only a typed invocation reaches it is the signal that the role never took.
+- Be a skill nothing invokes but its author typing the name. `auto-ship` Step 0 invokes it on every build, dispatched or hand-launched, so a stretch where only a typed invocation reaches it is the signal that the role never took.
 
 ## Guards
 
@@ -48,7 +48,7 @@ Nothing tells the session that refusing is allowed either. Four occasions across
 
 ## Out of scope
 
-- Entering the worktree, which `claude-worktree` owns
-- The chain from implement through pull request, which `claude-autoship` owns
-- Answering a posted review, which `claude-address-review` owns
-- The controlling session's half of the channel, the review poll, and the watch beside it, which `claude-orchestrate` and its runbooks hold
+- Entering the worktree, which `session-worktree` owns
+- The chain from implement through pull request, which `auto-ship` owns
+- Answering a posted review, which `review-address` owns
+- The controlling session's half of the channel, the review poll, and the watch beside it, which `role-orchestrator` and its runbooks hold

package/claude/skills/{claude-worker → role-worker}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-worker
+name: role-worker
 description: Asserts the worker role for a building session, holding the boundary set, the lifetime, and the two channel obligations a session owes whoever dispatched it. Use when asked to "be the worker", "you are a worker session", at the start of a dispatched or hand-launched build, or when a building session needs to know what it may not write. Do NOT use to plan the next feature, to run the independent review pass, or to merge.
 ---
 
-# Claude worker
+# Role worker
 
 This session is a worker: one cold session building one branch under one plan. It
 implements, verifies, opens a pull request, and answers what the review posts
@@ -14,10 +14,10 @@ review pass, and it does not merge. Those belong to the controlling session and
 to the human.
 
 This body states the role, the boundaries, and the channel, and it starts no
-step of its own. `claude-worktree` enters the tree, `claude-autoship` chains the
-build, and `claude-address-review` answers a posted review, so read each step
+step of its own. `session-worktree` enters the tree, `auto-ship` chains the
+build, and `review-address` answers a posted review, so read each step
 from the skill that owns it and invoke none of the three from here. The ordinary
-path arrives through `claude-autoship` Step 0, which means that chain is already
+path arrives through `auto-ship` Step 0, which means that chain is already
 running and re-invoking it would restart the build.
 
 ## Where the session stands
@@ -40,7 +40,7 @@ The controlling session cannot watch this one build, so three messages are owed
 and nothing else.
 
 - Announce the pull request as the ship chain's pull request step returns, carrying the number, the branch, and the task it closes. That transition is the one moment only this session knows, and the controller's review poll no longer starts on a dispatch because of it.
-- Announce when an address-review pass finishes, as `claude-address-review` Step 8 returns, carrying what was addressed and the PR's new CI state. That transition is the other moment only this session knows, and it is what tells the controller to re-review rather than leaving it to poll for an answer nothing marks as landed.
+- Announce when an address-review pass finishes, as `review-address` Step 8 returns, carrying what was addressed and the PR's new CI state. That transition is the other moment only this session knows, and it is what tells the controller to re-review rather than leaving it to poll for an answer nothing marks as landed.
 - Send a block out as a message before it becomes an interactive prompt. A session already waiting on input never reaches the tool round that drains an inbound message, so a relayed answer arrives under the open question and changes nothing.
 - Send nothing on progress. A worker reporting progress rebuilds, on this side of the channel, the poll the announcement retired on the other.
 

package/claude/skills/{claude-seed-sync → seed-sync}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-seed-sync
+name: seed-sync
 description: Scope boundary for section-granular seed reconciliation against the bulk install and sync commands
 ---
 
-# Claude seed sync requirement
+# Seed sync requirement
 
 ## Gap
 

package/claude/skills/{claude-seed-sync → seed-sync}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-seed-sync
+name: seed-sync
 description: Audits a project's installed Claude seed docs against the toolkit's current seed source and proposes per-section edits without overwriting customizations. Use when asked to "sync seeds", "update my seeds", "check seed drift", "did the toolkit seeds change", or when reconciling `CLAUDE.md` and `.claude/` preambles after an upstream toolkit update.
 ---
 
-# Claude seed sync
+# Seed sync
 
 Surfaces drift between the toolkit's current seed docs and what was installed in this project, then proposes targeted edits. The CLI emits seed content. This skill diffs, reasons, and writes the proposal to a review file. It does not write target files until the user confirms.
 
@@ -140,7 +140,7 @@ Chat shortcut: the user replies with `all`, `none`, a comma-separated list of nu
 
 Apply edits one at a time via `Edit`, replacing one section at a time. Never rewrite a whole file. Claude Code's tool permission dialog is the confirmation gate per edit.
 
-As each item resolves, update its status in the review file: flip the H2 emoji from 📝 to ✅ for applied or ⏭ for skipped. Refresh the summary block counts at the top. Do not delete the review file. It stays as a receipt until the next `claude-seed-sync` run overwrites it or the user clears it.
+As each item resolves, update its status in the review file: flip the H2 emoji from 📝 to ✅ for applied or ⏭ for skipped. Refresh the summary block counts at the top. Do not delete the review file. It stays as a receipt until the next `seed-sync` run overwrites it or the user clears it.
 
 ## After completion
 

package/claude/skills/session-map/REQUIREMENT.md

@@ -51,7 +51,7 @@ A body that restates the sections, the frontmatter, or the numbered steps become
 ## Out of scope
 
 - Reading a handoff back at the start of the next session: `session-resume`
-- Routing a session fact to the context entry that owns it, and writing what no entry owns to the memory folder: `claude-memory-capture`
-- The sections a role adds over the core three, which belong to that role's own surface. `claude-orchestrate` owns the orchestrator's and cites this route for the generic half.
+- Routing a session fact to the context entry that owns it, and writing what no entry owns to the memory folder: `memory-capture`
+- The sections a role adds over the core three, which belong to that role's own surface. `role-orchestrator` owns the orchestrator's and cites this route for the generic half.
 - Validating a written map against the standard, which no record kind covers, so a conforming shape rests on the standard being followed
 - Firing the write without being asked, which is a question about what the harness supports and is measured on its own track

package/claude/skills/session-map/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: session-map
-description: Writes the session map, the pre-compaction handoff at `.canon/tasks/session-<slug>.md`, from any session whatever role it holds, running the skill-drift step the write procedure opens with. Use when asked to "write the handoff", "write the session map", "save the session before it compacts", "we are about to compact", "hand off to the next session", or "leave a note for whoever picks this up". Do NOT use to route session facts to a context entry or the memory folder, which is `claude-memory-capture` and writes a different artifact, and do NOT use to read a handoff back, which is `session-resume`.
+description: Writes the session map, the pre-compaction handoff at `.canon/tasks/session-<slug>.md`, from any session whatever role it holds, running the skill-drift step the write procedure opens with. Use when asked to "write the handoff", "write the session map", "save the session before it compacts", "we are about to compact", "hand off to the next session", or "leave a note for whoever picks this up". Do NOT use to route session facts to a context entry or the memory folder, which is `memory-capture` and writes a different artifact, and do NOT use to read a handoff back, which is `session-resume`.
 ---
 
 # Session map
@@ -25,7 +25,7 @@ Decline where the session holds no reasoning a reader could not get faster from
 
 ## Step 1: run the capture the procedure opens with
 
-Item 1 of `## Writing one` is a capture. Invoke `canon:claude-memory-capture` and let it return before writing, so the map cites what was written instead of restating the same lesson in prose.
+Item 1 of `## Writing one` is a capture. Invoke `canon:memory-capture` and let it return before writing, so the map cites what was written instead of restating the same lesson in prose.
 
 Pass on the caveat a caller states about committing. A caller that does not commit says so, and capture then skips routing and writes memory files alone, since a routed fact lands in a context entry and that is a tracked file. A caller stating nothing leaves capture to decide for itself, which is the ordinary run.
 

package/claude/skills/session-resume/REQUIREMENT.md

@@ -44,6 +44,6 @@ A resume is a read, and a session that treats it as a cleanup pass offers to arc
 
 - Writing a handoff, which happens at the close of a session rather than at its start. This skill names the standard that governs one and follows it no further.
 - The sections a role adds over the core handoff, which belong to that role's own surface
-- Archiving a shipped task out of the folder: `claude-tasks`
-- Archiving a plan and marking an outcome, which `claude-docs` does when the work ships
+- Archiving a shipped task out of the folder: `task-board`
+- Archiving a plan and marking an outcome, which `docs-fold` does when the work ships
 - Implementing the item it recommends, which is the next request rather than part of this one

package/claude/skills/session-resume/SKILL.md

@@ -7,7 +7,7 @@ description: Resumes a previous session by reading the handoff it left behind, t
 
 ## Step 1: read tracked work
 
-Resolve `.canon/plans/`, `.canon/memory/`, and `.canon/tasks/` at the main worktree root the way `claude-worktree` does.
+Resolve `.canon/plans/`, `.canon/memory/`, and `.canon/tasks/` at the main worktree root the way `session-worktree` does.
 
 Read these in parallel, skipping any that do not exist:
 
@@ -42,7 +42,7 @@ When the board is empty and a handoff was found, name what the handoff leaves op
 
 Do not offer to remove entries. A completed task is archived out of `.canon/tasks/` when work ships. The git log is the authoritative record of shipped work. Plan files are archived per the lifecycle rule in `${CLAUDE_SKILL_DIR}/../../standards/plan.md`.
 
-Memory is updated only when a recorded fact becomes wrong, never on resume. A domain fact reaches a session through `.claude/context/`, which `claude-memory-capture` routes to and the three-tier model loads on demand, so the memory folder read here is the residue no context entry owns.
+Memory is updated only when a recorded fact becomes wrong, never on resume. A domain fact reaches a session through `.claude/context/`, which `memory-capture` routes to and the three-tier model loads on demand, so the memory folder read here is the residue no context entry owns.
 
 ## Writing the next one
 

package/claude/skills/{claude-worktree → session-worktree}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-worktree
+name: session-worktree
 description: Why worktree entry is wrapped rather than called directly, covering name derivation, the conventional branch rename the ship chain depends on, and the shared-config repair
 ---
 
-# Claude worktree requirement
+# Session worktree requirement
 
 ## Gap
 
@@ -17,7 +17,7 @@ A declined request also has to land somewhere. The description turns away a list
 
 A submodule checkout is the state the entry path reads wrong while reporting nothing. The two directory reads that separate a linked worktree from a plain checkout return the same path there, so the guard passes and every derivation after it takes the submodule for the project: the main root, the plan lookup, and the folder entry builds all resolve inside a tree the superproject tracks as a commit.
 
-A stack that derives its ports from the working directory has the same shape. The number is correct and invisible, and `claude-orchestrate` sends a reader here to read it rather than assign one, so the entry that knows the working directory is the surface that owes it.
+A stack that derives its ports from the working directory has the same shape. The number is correct and invisible, and `role-orchestrator` sends a reader here to read it rather than assign one, so the entry that knows the working directory is the surface that owes it.
 
 ## Must
 

package/claude/skills/{claude-worktree → session-worktree}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-worktree
-description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/claude-feature`. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
+name: session-worktree
+description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/plan-feature`. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
 ---
 
-# Claude worktree
+# Session worktree
 
 Wrap the `EnterWorktree` entry path with name derivation so the user does not pick a name by hand.
 
@@ -53,7 +53,7 @@ Resolve `<type>` here as well, since Step 3 previews it and Step 5 renames onto
 
 The verb is the reading rather than this body, because a type read off a plan's `## Summary` and `**Files to touch:**` lines is a judgment, and it has disagreed with itself in production. One dispatch checked `fix/path-form-hook` and the worker took `feat/path-form-hook`, both sides reading the same plan and grading it differently. The verb answers `feat` for every plan, so two sides calling it cannot part.
 
-The caller's type still wins over the verb's, because tier 0 is the one source that knows something no file states. The ordinary caller is `claude-autoship` Step 0, which ran the verb itself and is handing over the answer it got, so nothing is overridden in that case either.
+The caller's type still wins over the verb's, because tier 0 is the one source that knows something no file states. The ordinary caller is `auto-ship` Step 0, which ran the verb itself and is handing over the answer it got, so nothing is overridden in that case either.
 
 Branch on the record rather than on the exit code, which a shell function wrapping `canon` can flatten to zero. Take `feat` and say the verb did not answer where it refuses, where the record carries no `type` key, or where the installed binary carries no `plan-branch` subcommand.
 
@@ -92,7 +92,7 @@ Call `EnterWorktree` with `name: "<name>"`. Claude Code's tool permission dialog
 
 ## Step 5: align the branch name and repair the shared config
 
-`EnterWorktree` creates a branch named `worktree-<name>`, which diverges from `<name>` and breaks downstream slug derivation in `claude-autoship` and any skill that reads `git branch --show-current`. A bare `<name>` fixes that and fails the branch-format guard in `git-pr`, which requires `<type>/<description>`. Rename to the conventional form, which satisfies both:
+`EnterWorktree` creates a branch named `worktree-<name>`, which diverges from `<name>` and breaks downstream slug derivation in `auto-ship` and any skill that reads `git branch --show-current`. A bare `<name>` fixes that and fails the branch-format guard in `git-pr`, which requires `<type>/<description>`. Rename to the conventional form, which satisfies both:
 
 ```bash
 git branch -m worktree-<name> <type>/<name>
@@ -153,6 +153,6 @@ Branch on the exit rather than on the output, since the helper prints nothing to
 
 The helper refuses a folder left behind after its worktree was removed, which Step 4 cannot land on, since it registers whatever it creates. The branch is here so a refusal is never read back as an offset of zero, which is the main checkout's port and the collision the helper exists to prevent.
 
-The offset is what `claude-orchestrate` sends a reader here to read rather than assign, and what an operator overrides through `WORKTREE_PORT_OFFSET` when two worktrees derive the same value. Deriving it correctly and printing it nowhere leaves both instructions naming a number no surface emits.
+The offset is what `role-orchestrator` sends a reader here to read rather than assign, and what an operator overrides through `WORKTREE_PORT_OFFSET` when two worktrees derive the same value. Deriving it correctly and printing it nowhere leaves both instructions naming a number no surface emits.
 
 Do not invoke `ExitWorktree` from this skill. Exit is the user's call.

package/claude/skills/setup-plugins/references/plugin-catalog.md

@@ -28,7 +28,7 @@ The `design` and `security` categories cover the common gaps for a new machine.
 When the user asks for a recommended set, propose `frontend-design` and
 `security-guidance`. Offer `code-review` and `superpowers` as additions.
 
-`code-review` overlaps the toolkit's own `claude-review` skill. They run in
+`code-review` overlaps the toolkit's own `review-branch` skill. They run in
 different places, the plugin on a PR and the toolkit skill on a local diff. Install
 `code-review` only when the user wants the GitHub-side flow too.
 

package/claude/skills/{claude-standards-audit → standards-audit}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-standards-audit
+name: standards-audit
 description: What the standards audit is for, the gaps it closes, and the fixing it deliberately refuses
 ---
 
-# Claude standards audit requirement
+# Standards audit requirement
 
 ## Gap
 

package/claude/skills/{claude-standards-audit → standards-audit}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-standards-audit
+name: standards-audit
 description: Audits changed markdown files against every authoring standard that declares jurisdiction over their paths and reports violations without fixing. Reads the standards catalog to map each file, greps for banned tokens, and groups findings by file. Use when asked to "audit prose", "audit standards", "check standards", "standards audit", or after editing markdown where standards compliance matters. Do NOT fix violations. Reporting only.
 ---
 
-# Claude standards audit
+# Standards audit
 
 ## Guards
 

package/claude/skills/systematic-debugging/REQUIREMENT.md

@@ -37,5 +37,5 @@ Two failures are about stopping rather than about fixing. A session that never c
 ## Out of scope
 
 - A typo fix and a cause already agreed on, where the phases cost more than they return
-- Reviewing a change for defects it has not yet exhibited: `claude-review`
+- Reviewing a change for defects it has not yet exhibited: `review-branch`
 - Deciding whether the architecture should change, which the three-attempt stop hands to the user rather than answering

package/claude/skills/{claude-tasks → task-board}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-tasks
+name: task-board
 description: Why creating and archiving a task file is one skill, the origin invariant enforceable only at creation, and why archiving routes through the command the merge hook calls
 ---
 
-# Claude tasks requirement
+# Task board requirement
 
 ## Gap
 
@@ -42,6 +42,6 @@ Placing a row without checking for another writer collides the same way. Two ses
 
 ## Out of scope
 
-- Editing the contents of a task that already exists, which `claude-docs` owns along with marking outcomes and sweeping plans
+- Editing the contents of a task that already exists, which `docs-fold` owns along with marking outcomes and sweeping plans
 - Deciding what the task should argue. This owns the file's existence and its shape, not its content.
 - Relocating a plan, which one skill owns so two do not relocate it differently

package/claude/skills/{claude-tasks → task-board}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: claude-tasks
-description: Creates a task file in `.canon/tasks/` with the filename, phase label, and frontmatter the standard requires, and archives a shipped one out of the folder. Use when asked to "add a task", "create a task", "queue this", "put this on the board", "archive that task", or "close out a shipped task". Do NOT use to mark an outcome `[x]`. That is `claude-docs`.
+name: task-board
+description: Creates a task file in `.canon/tasks/` with the filename, phase label, and frontmatter the standard requires, and archives a shipped one out of the folder. Use when asked to "add a task", "create a task", "queue this", "put this on the board", "archive that task", or "close out a shipped task". Do NOT use to mark an outcome `[x]`. That is `docs-fold`.
 ---
 
-# Claude tasks
+# Task board
 
-Owns the two operations that bring a task file into existence and take it out of the folder. `claude-docs` edits the contents of a task that already exists, marking outcomes `[x]`. Do not mark outcomes here, and do not move a plan by hand: the archive carries it.
+Owns the two operations that bring a task file into existence and take it out of the folder. `docs-fold` edits the contents of a task that already exists, marking outcomes `[x]`. Do not mark outcomes here, and do not move a plan by hand: the archive carries it.
 
 Read `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` before writing any file. It holds the filename convention, the frontmatter contract, and the file format. Do not work them from memory.
 
 ## Guards
 
 - Resolve the board at the main worktree root, not `pwd`. Run `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd` outside a git repo. Every read and write below resolves against that root. The board is gitignored scratch shared across worktrees, so a linked worktree writing to its own `pwd` creates a second board nothing else reads.
-- From a linked worktree the file-editing tools refuse that root, so a new task file goes out through `Bash` as a plain single command carrying a heredoc. Archiving already runs through `canon tasks archive`, which resolves the root in-process. Marking an outcome shipped is `claude-docs` and runs through `canon tasks outcome`. Resolve that root the way `claude-worktree` does.
+- From a linked worktree the file-editing tools refuse that root, so a new task file goes out through `Bash` as a plain single command carrying a heredoc. Archiving already runs through `canon tasks archive`, which resolves the root in-process. Marking an outcome shipped is `docs-fold` and runs through `canon tasks outcome`. Resolve that root the way `session-worktree` does.
 - If `.canon/tasks/` does not exist at that root, stop: `❌ No .canon/tasks/ board. Run canon claude init to set it up.`
 - Route on the request rather than on a flag. Creating names work that does not exist yet, archiving names a task file already on the board. If the request fits neither, stop: `❌ Ambiguous. Say whether to create a task or archive one.`
 - Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter after a write. Do not run the regen command directly, except after a shell write from a linked worktree: the hook matches `Write|Edit|MultiEdit` and nothing fires on `Bash`, so that one case regenerates explicitly with `canon indexes regen --no-stage --root <main-root> <main-root>/.canon/tasks/index.md`.
@@ -90,7 +90,7 @@ Do not move the file, edit `priority.md`, or regenerate the index by hand. `cano
 
 ### Step 1: confirm the work reached main
 
-`claude-docs` marks outcomes on the branch as step 1 of the ship chain, so an all-`[x]` task routinely describes a pull request that is still open. The command gates on the outcomes and cannot tell those two apart, which is what puts this check here:
+`docs-fold` marks outcomes on the branch as step 1 of the ship chain, so an all-`[x]` task routinely describes a pull request that is still open. The command gates on the outcomes and cannot tell those two apart, which is what puts this check here:
 
 ```bash
 git fetch origin main --quiet && git log origin/main --oneline -20
@@ -116,7 +116,7 @@ On success the record carries `from`, `to`, `priorityRowRemoved`, and `indexRege
 
 Each reason has one resolution and none of them is to archive around it:
 
-- `open-outcomes`: the named outcomes are unmarked or genuinely open. Run `claude-docs` when the work shipped and nothing marked it. Leave the task on the board when the outcome is real. When the work is being abandoned, cut it by striking the body, `- ~~<outcome>~~ <why>`, whatever the checkbox holds, so the board records what was dropped rather than meeting this refusal a second time.
+- `open-outcomes`: the named outcomes are unmarked or genuinely open. Run `docs-fold` when the work shipped and nothing marked it. Leave the task on the board when the outcome is real. When the work is being abandoned, cut it by striking the body, `- ~~<outcome>~~ <why>`, whatever the checkbox holds, so the board records what was dropped rather than meeting this refusal a second time.
 - `ambiguous`: two tasks name one pull request, which is the misfile `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` rules out. Resolve the citation by hand, since no sweep repairs it.
 - `no-match`: the stem or number names nothing on the board. Check the name against the listed stems.
 - `bad-input`: the command line was wrong rather than the board. Read the message, fix the arguments, and run it again. Nothing on the board needs repair, which is what separates this from the two above.

package/claude/skills/{claude-teach → teach-workspace}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-teach
+name: teach-workspace
 description: Scope boundary for learning a subject across sessions, and the split between the disposable lesson and the durable reference page
 ---
 
-# Claude teach requirement
+# Teach workspace requirement
 
 ## Gap