@erclx/canon 4.66.0 → 4.68.0

package/claude/skills/{claude-memory-review → memory-review}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-memory-review
+name: memory-review
 description: What memory review is for, the gaps it closes, and why every action waits on approval
 ---
 
-# Claude memory review requirement
+# Memory review requirement
 
 ## Gap
 
@@ -15,7 +15,7 @@ A pen the caller cannot face is the same gap wearing a different shape. Routing
 
 - Treat the folder as a holding pen, so every entry in scope leaves it as a promotion, a handoff, or an archive rather than surviving by default
 - Archive an entry out of the pen rather than deleting it, since nothing recovers a file from a gitignored folder
-- Hand a fact a context entry owns to `claude-docs` through the routing file, rather than editing the entry here
+- Hand a fact a context entry owns to `docs-fold` through the routing file, rather than editing the entry here
 - Verify the rule is not already stated or implied in the target before proposing a promotion, by reading the target rather than trusting the memory's claim about it
 - Rewrite a rule into the destination's voice instead of moving it unchanged
 - Write the proposal to a receipt on disk and take no action until the user decides per item
@@ -45,6 +45,6 @@ A pen the caller cannot face is the same gap wearing a different shape. Routing
 
 ## Out of scope
 
-- Writing memories, which `claude-memory-capture` owns
+- Writing memories, which `memory-capture` owns
 - Judging whether an entry should have been captured. That is a gate at capture time, and re-deciding it here would delete evidence the capture rule is wrong.
 - Editing the governance rules a handoff points at

package/claude/skills/{claude-memory-review → memory-review}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-memory-review
+name: memory-review
 description: Reviews `.canon/memory/` and proposes per-entry actions (promote to `CLAUDE.md`, move into a skill body, route to a context entry, hand off to governance, or retire as stale). Also runs the discuss, challenge, apply, and cleanup phases on an existing review file. Use when asked to "review memory", "discuss memory questions", "challenge the promotes", "apply memory decisions", "cleanup memory review", "promote memory", or "consolidate memories". Do NOT auto-apply. Output a grouped proposal and wait for block-by-block approval.
 ---
 
-# Claude memory review
+# Memory review
 
 This skill drives the full memory review lifecycle in five phases. Pick the phase from what the user said and whether a review receipt already exists at `<main-root>/.canon/review/memory/memory-review-*.md`.
 
@@ -21,7 +21,7 @@ If the user re-pings the skill with no new phrase and a receipt exists, default
 
 ## Guards
 
-- All `.canon/memory/` reads, edits, and archive moves resolve at the main worktree root, not the current worktree. Resolve that root the way `claude-worktree` does.
+- All `.canon/memory/` reads, edits, and archive moves resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
 - If no `.canon/memory/` directory exists at the main worktree root, stop: `❌ No .canon/memory/ directory found.`
 - If `.canon/memory/` contains no `*.md` entries other than `index.md`, stop: `✅ No memory entries to review.`
 - Cleanup is exempt from the two stops above. It works on receipts in `.canon/review/`, and a drained pen is the normal state once Apply has run, so a pen-shaped stop would strand the receipt it exists to delete.
@@ -34,7 +34,7 @@ Propose is the ship-time entry point. The ship skills run it right after capture
 
 ### Scope
 
-- **Ship-scoped:** when a ship caller (`git-ship`, `claude-autoship`) names the entries captured this session, classify only those entries. Read the full pen for merge and absorbed comparison, but do not propose actions on carried entries the captures do not touch. Each carried entry was already proposed on in its own ship cycle.
+- **Ship-scoped:** when a ship caller (`git-ship`, `auto-ship`) names the entries captured this session, classify only those entries. Read the full pen for merge and absorbed comparison, but do not propose actions on carried entries the captures do not touch. Each carried entry was already proposed on in its own ship cycle.
 - **Full sweep:** when invoked standalone with no named set, classify every entry in the pen, including entries carried from earlier sessions, so cross-session duplicates merge into one rule.
 
 ### Step 1: read the memory folder
@@ -58,14 +58,14 @@ Read in parallel from the project root. Skip any file or folder that does not ex
 
 `.canon/memory/` is a holding pen. Default every entry to promote or retire on review. Skip is the rare exception, reserved for active task overlap or user-type memories with no in-repo target.
 
-`claude-memory-capture` routes a project fact naming a domain with a context entry to that entry, so a pen filled since routing shipped is mostly feedback: rules about how to work, which no context entry owns. Propose against what the pen holds rather than expecting the older mix. An entry carried from before routing may still name a domain that has a context entry, and that entry's action is **Promote to a context entry**, which hands it to `claude-docs` the same way capture does rather than editing the entry here.
+`memory-capture` routes a project fact naming a domain with a context entry to that entry, so a pen filled since routing shipped is mostly feedback: rules about how to work, which no context entry owns. Propose against what the pen holds rather than expecting the older mix. An entry carried from before routing may still name a domain that has a context entry, and that entry's action is **Promote to a context entry**, which hands it to `docs-fold` the same way capture does rather than editing the entry here.
 
 For each in-scope entry (see Scope), pick one action:
 
 - **Promote to `CLAUDE.md`**: the rule is cross-domain behavior or a design principle applied across the whole project.
 - **Promote to a skill body**: the rule fires only when editing a specific path-scoped domain. Name the target skill.
 - **Promote to a standards file**: the rule is an authoring reference that belongs in the project's own standards folder as `<domain>.md`.
-- **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `.claude/context/index.md`. Append it to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root, in the format `claude-memory-capture` writes, and tell the user to run `/claude-docs` from a branch. Do not edit the context entry here.
+- **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `.claude/context/index.md`. Append it to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root, in the format `memory-capture` writes, and tell the user to run `/docs-fold` from a branch. Do not edit the context entry here.
 - **Hand off to governance**: the rule is coding-standards class (typescript, testing, naming, error-handling, performance, logging, concurrency, planning). Do not author the rule file inline. Never edit the synced `.claude/rules/` copies of toolkit rules, because `canon gov sync` overwrites them. Stop at handoff.
   - In the toolkit repo, point the user at `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own the source-of-truth rules under `governance/rules/`.
   - In a target project, point the user at the `create-rule` skill, which scaffolds a project-local rule under `.claude/rules/`.
@@ -132,7 +132,7 @@ Before applying any item, check the worktree state:
 [ "$(git rev-parse --git-dir 2>/dev/null)" = "$(git rev-parse --git-common-dir 2>/dev/null)" ] && echo "MAIN" || echo "LINKED"
 ```
 
-If the result is `MAIN`, stop and tell the user: `❌ Apply phase mutates tracked files. Run /claude-worktree first.` Discuss and Challenge phases only touch `.canon/review/` scratch and run from anywhere.
+If the result is `MAIN`, stop and tell the user: `❌ Apply phase mutates tracked files. Run /session-worktree first.` Discuss and Challenge phases only touch `.canon/review/` scratch and run from anywhere.
 
 Before applying a promote to root `CLAUDE.md`, load `internal-claude` so its seed-mirror rule fires on the edit.
 
@@ -150,7 +150,7 @@ Free-form text after the verb is a reason. Capture it in the receipt but do not
 Action by action type:
 
 - **Promote**: use `Edit` to insert the rewritten rule into the target surface, then archive the memory file.
-- **Promote to a context entry**: append the fact to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root, then archive the memory file. `claude-docs` folds it in on its next run from a branch, which is what keeps one skill writing context entries.
+- **Promote to a context entry**: append the fact to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root, then archive the memory file. `docs-fold` folds it in on its next run from a branch, which is what keeps one skill writing context entries.
 - **Hand off**: do not edit governance. Archive the memory file only if the user confirmed the handoff explicitly. Otherwise leave it in place.
 - **Retire**: archive the memory file.
 
@@ -178,7 +178,7 @@ Count the items still 📝 pending once the parse above has run. Apply leaves on
 
 Leave the receipt in place when any remain. When none do, collect it per the collection rule in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`, which owns what a fold writes and which entry types take one.
 
-`claude-docs` Step 10 sweeps the same folder on the same rule once per shipped branch, and either may reach a receipt first. Whichever does, the other finds no file and moves on.
+`docs-fold` Step 10 sweeps the same folder on the same rule once per shipped branch, and either may reach a receipt first. Whichever does, the other finds no file and moves on.
 
 End with: `✅ Applied: <nums> | ⏭ Skipped: <nums> | 📝 Pending: <nums>`. Omit empty buckets. If anything is pending, remind the user they can refine `Decision:` lines and re-ping, run "discuss" for question items, or commit a skip with `skip <nums>` in chat.
 
@@ -186,7 +186,7 @@ End with: `✅ Applied: <nums> | ⏭ Skipped: <nums> | 📝 Pending: <nums>`. Om
 
 Trigger: user says "cleanup" or "delete the receipt" after Apply has run.
 
-Cleanup folds one receipt's skips and removes that receipt, and does nothing else. It is the fallback route now that Apply and `claude-docs` Step 10 each collect a resolved receipt on their own, so it reaches a file those two left behind rather than being the only collector. Apply is still the only phase that moves a memory entry out of the pen, and it does so per approved item into `.canon/tmp/memory-archive/`. A user asking to sweep stale memories wants Propose, which classifies entries and writes a decision slot per entry.
+Cleanup folds one receipt's skips and removes that receipt, and does nothing else. It is the fallback route now that Apply and `docs-fold` Step 10 each collect a resolved receipt on their own, so it reaches a file those two left behind rather than being the only collector. Apply is still the only phase that moves a memory entry out of the pen, and it does so per approved item into `.canon/tmp/memory-archive/`. A user asking to sweep stale memories wants Propose, which classifies entries and writes a decision slot per entry.
 
 If no `.canon/review/memory/memory-review-*.md` exists at the main root, stop: `✅ No review receipt to clean up.` Every other refusal in this skill carries a message, and the phase reads a receipt before it does anything else.
 

package/claude/skills/migration-context/SKILL.md

@@ -60,7 +60,7 @@ Print one grouped proposal block. Omit empty groups.
 
 - docs/<file>.md (<one-line reason>)
 
-## Defer to claude-seed-sync
+## Defer to seed-sync
 
 - docs/<file>.md (matches toolkit base seed)
 

package/claude/skills/migration-standards-drop/REQUIREMENT.md

@@ -47,7 +47,7 @@ The last is the name map. `prose` split into `markdown.md` plus the `write-human
 - Classifying `CLAUDE.md` sections into the three-tier model: `migration-claude-md`
 - Relocating `docs/` files by audience: `migration-context`
 - Splitting a retired `.claude/` file into the folder that replaced it, which pairs one file against one folder rather than dropping a corpus: `migration-superseded`
-- Reconciling a seed file against its source section by section: `claude-seed-sync`
+- Reconciling a seed file against its source section by section: `seed-sync`
 - Applying the drop and the sweep, which the user does after reviewing
 
 ## Why it ships while its consumer row is parked

package/claude/skills/migration-superseded/REQUIREMENT.md

@@ -40,5 +40,5 @@ The last is the two-speed release skew arriving as a confident wrong answer. `su
 
 - Classifying `CLAUDE.md` sections into the three-tier model: `migration-claude-md`
 - Relocating `docs/` files by audience: `migration-context`
-- Reconciling a seed file against its source section by section, which diffs two files rather than splitting one into a folder: `claude-seed-sync`
+- Reconciling a seed file against its source section by section, which diffs two files rather than splitting one into a folder: `seed-sync`
 - Applying the split and running the untrack, which the user does after reviewing

package/claude/skills/{claude-feature → plan-feature}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-feature
+name: plan-feature
 description: What feature planning is for, the gaps it closes, and why it stops before implementing
 ---
 
-# Claude feature requirement
+# Plan feature requirement
 
 ## Gap
 
@@ -32,5 +32,5 @@ Without this skill, implementation starts before anyone knows what it touches. A
 ## Out of scope
 
 - Executing the plan, which is the ship pipeline
-- Task-board state, which `claude-tasks` owns. A plan links to its task and does not create one.
-- Reconciling the planning docs after the work lands, which `claude-docs` owns
+- Task-board state, which `task-board` owns. A plan links to its task and does not create one.
+- Reconciling the planning docs after the work lands, which `docs-fold` owns

package/claude/skills/{claude-feature → plan-feature}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-feature
+name: plan-feature
 description: Plans a feature by reading the project's Claude setup and scanning relevant source files. Outputs which files to touch, risks, and ambiguities, then stops. Use before implementing anything, or when asked to "implement X", "add X", "build X", or "I want to add X". Do NOT implement. Plan only.
 ---
 
-# Claude feature
+# Plan feature
 
 ## Guards
 
@@ -91,7 +91,7 @@ Omit empty sections. Do not print `None identified.` in chat.
 
 ### Full mode
 
-Derive a 2-to-4-word kebab-case slug from the feature description. Write the full plan to `.canon/plans/feature-<slug>.md` at the main worktree root, not the current worktree. Resolve that root the way `claude-worktree` does. Create the directory if it does not exist.
+Derive a 2-to-4-word kebab-case slug from the feature description. Write the full plan to `.canon/plans/feature-<slug>.md` at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does. Create the directory if it does not exist.
 
 From a linked worktree, or from a background session sitting at the main root with none entered, the file-editing tools refuse that path, so the plan goes out through `Bash`. Send the `mkdir -p` and the heredoc as two plain commands rather than joining them with `&&`, which is refused as compound.
 
@@ -113,7 +113,7 @@ Then output in chat:
 1. <question>
    - Suggested: <pick>, <reason or tradeoff>
 
-Next: /claude-worktree
+Next: /session-worktree
 ```
 
 Show only the path line and the `Next:` line when there are no questions. The `.canon/plans/` directory is gitignored. Do not stage or commit the file.

package/claude/skills/{claude-groundwork → plan-groundwork}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-groundwork
+name: plan-groundwork
 description: Why a question that has not been measured gets a disposable folder instead of a plan, and the write scope that lets the track run without pausing
 ---
 
-# Claude groundwork requirement
+# Plan groundwork requirement
 
 ## Gap
 
@@ -21,8 +21,8 @@ A track that closes with several separable findings writes only one task, and th
 - Measure the current state now rather than carrying a figure from a previous session
 - Carry a lean and the finding that would overturn it on every open question, or admit that a measurement is missing
 - Confine writes to the track folder, with the close-time task file, the experiment fixture, and the intake routing below as the only exceptions
-- Route a closing-track finding the required task does not cover through `claude-intake`, rather than leaving it to be asked about. The route runs in the same session, so it is a write outside the folder rather than a handoff to a later one.
-- Place the closing task's row through `claude-tasks` Step 4 rather than writing `priority.md` or `backlog.md` directly
+- Route a closing-track finding the required task does not cover through `plan-intake`, rather than leaving it to be asked about. The route runs in the same session, so it is a write outside the folder rather than a handoff to a later one.
+- Place the closing task's row through `task-board` Step 4 rather than writing `priority.md` or `backlog.md` directly
 - Link every claim about a source outside the project, and list an unread source as a lead rather than citing it
 - Put a fixture a headless run is pointed at outside the repository
 - Write the next-session file self-contained, since the folder is unbacked and dies with the machine
@@ -44,6 +44,6 @@ A track that closes with several separable findings writes only one task, and th
 
 ## Out of scope
 
-- Writing the plan the track concludes toward, which `claude-feature` owns
+- Writing the plan the track concludes toward, which `plan-feature` owns
 - Implementing anything the track recommends
 - Persisting the folder. It is gitignored and disposable, which is what makes it the right container for an unanswered question.

package/claude/skills/{claude-groundwork → plan-groundwork}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-groundwork
-description: Opens and runs a numbered groundwork folder under `.canon/groundwork/<nn>-<slug>/` for a topic that has to be measured before it can be planned. Detects open, resume, and close from the folder itself. Use when asked to "research X", "dig into X", "work out what we should do about X", "measure this before we commit", or "open a groundwork folder". Do NOT use to write a feature plan or to implement. That is `claude-feature`.
+name: plan-groundwork
+description: Opens and runs a numbered groundwork folder under `.canon/groundwork/<nn>-<slug>/` for a topic that has to be measured before it can be planned. Detects open, resume, and close from the folder itself. Use when asked to "research X", "dig into X", "work out what we should do about X", "measure this before we commit", or "open a groundwork folder". Do NOT use to write a feature plan or to implement. That is `plan-feature`.
 ---
 
-# Claude groundwork
+# Plan groundwork
 
 Groundwork gathers and weighs. A plan commits. A groundwork folder costs nothing to throw away, which is what makes it the right container for a question nobody has answered yet.
 
@@ -12,9 +12,9 @@ Read `${CLAUDE_SKILL_DIR}/../../standards/groundwork.md` before writing any file
 ## Guards
 
 - If no topic is given, stop: `❌ No topic. Name what needs measuring.`
-- Apply the qualifying test in open mode alone, after Step 1 resolves the mode and before the folder is created. Two of these three must hold: the current state is not known, more than one approach is live, and committing wrong costs more than a day of measuring. When one or fewer holds, stop: `❌ Already decided enough to plan. Run /claude-feature instead.`
+- Apply the qualifying test in open mode alone, after Step 1 resolves the mode and before the folder is created. Two of these three must hold: the current state is not known, more than one approach is live, and committing wrong costs more than a day of measuring. When one or fewer holds, stop: `❌ Already decided enough to plan. Run /plan-feature instead.`
 - Resume and close are exempt from the test above. A track that has already been measured fails it by definition, since its current state is now known and its approaches have narrowed, so applying the test to either mode refuses the folder that same test admitted.
-- A refused topic that is a broad dump rather than one question routes to `claude-intake`, not to the planning skill the stop names. Intake dispositions many findings in breadth from what the repository already holds, and one folder holding dozens of unrelated threads is what forcing them past this guard produces.
+- A refused topic that is a broad dump rather than one question routes to `plan-intake`, not to the planning skill the stop names. Intake dispositions many findings in breadth from what the repository already holds, and one folder holding dozens of unrelated threads is what forcing them past this guard produces.
 - Do not pause for approval between steps. The write scope below is what makes that safe.
 
 ## Write scope
@@ -92,8 +92,8 @@ The standard sets the open question format and requires it inside a topic file a
 1. Write `06-decision.md`. It states the problem once, names the goal, lists what to do, and lists what was considered and dropped.
 2. Write `07-next-session.md` self-contained, so it survives a compaction that loses the conversation.
 3. Update the file map in `README.md`.
-4. Write one task file in `.canon/tasks/` recording what the track concluded, even when the conclusion is to do nothing. Follow `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` for the filename and frontmatter. Place the row through `claude-tasks` Step 4, which checks the roster for a live orchestrator before writing `priority.md` or `backlog.md` directly. Aside from an experiment fixture, this and the routing in Step 5 are the only ways close mode reaches outside the folder.
-5. When the task written in Step 4 does not cover every finding the track surfaced, route what it leaves out through `claude-intake`. Skip this step when it does.
+4. Write one task file in `.canon/tasks/` recording what the track concluded, even when the conclusion is to do nothing. Follow `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` for the filename and frontmatter. Place the row through `task-board` Step 4, which checks the roster for a live orchestrator before writing `priority.md` or `backlog.md` directly. Aside from an experiment fixture, this and the routing in Step 5 are the only ways close mode reaches outside the folder.
+5. When the task written in Step 4 does not cover every finding the track surfaced, route what it leaves out through `plan-intake`. Skip this step when it does.
 6. Report uncited external claims. Closing already reads every file in the folder, so list any statement about a source outside the project that carries neither a link nor a lead entry. Report and do not block, because judging whether a sentence makes an external claim is the call a checker gets wrong.
 
 Do not close while an open question quietly fails an outcome. Resolve it, or record it in `06-decision.md` as knowingly accepted.
@@ -137,7 +137,7 @@ Close:
 
 <the decision in one line>
 
-Next: /claude-feature
+Next: /plan-feature
 ```
 
 Omit the uncited-claims block when the count is zero.

package/claude/skills/{claude-intake → plan-intake}/REQUIREMENT.md

@@ -1,13 +1,13 @@
 ---
-name: claude-intake
+name: plan-intake
 description: Why a brain dump gets a filed inventory rather than ten plans, and why an empty operator slot means unread
 ---
 
-# Claude intake requirement
+# Plan intake requirement
 
 ## Gap
 
-Without this skill, a brain dump reaches a session that has nowhere to put it. `claude-feature` answers with one plan per independent concern, so forty findings produce ten plan files before anything has been measured. `claude-groundwork` refuses a breadth pass outright, since its qualifying test asks whether the current state is unknown and most items are knowable by grep. What gets filed instead is a list of opinions, because nothing forces a count against the tree and a complaint reads the same whether it covers three sites or three hundred.
+Without this skill, a brain dump reaches a session that has nowhere to put it. `plan-feature` answers with one plan per independent concern, so forty findings produce ten plan files before anything has been measured. `plan-groundwork` refuses a breadth pass outright, since its qualifying test asks whether the current state is unknown and most items are knowable by grep. What gets filed instead is a list of opinions, because nothing forces a count against the tree and a complaint reads the same whether it covers three sites or three hundred.
 
 Two failure modes cost more than the rest. An operator's silence on an item reads as consent when the folder borrows the plan file's blank-means-accept contract, which ships changes nobody approved across a folder read over weeks. And a report naming only a path cannot distinguish three new items from one reworded sentence in a file that holds a dozen items, so every reader diffs it against memory to find out what moved.
 
@@ -43,7 +43,7 @@ A session with no numbering convention re-decides the folder shape per dump, so
 
 ## Out of scope
 
-- Measuring one question in depth, which `claude-groundwork` owns
-- Planning a promoted item, which `claude-feature` owns
-- Promoting an item onto the board, which `claude-tasks` owns
+- Measuring one question in depth, which `plan-groundwork` owns
+- Planning a promoted item, which `plan-feature` owns
+- Promoting an item onto the board, which `task-board` owns
 - Enforcing any of this. The folder is gitignored, so no check reaches its contents and every rule holds only while a session reads it.

package/claude/skills/{claude-intake → plan-intake}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-intake
-description: Files a raw brain dump into a numbered intake folder under `.canon/intake/<nn>-<slug>/`, one item per finding carrying a measured problem, a proposed fix, and a verdict. Use when asked to "file this dump", "triage my notes", "work through this list", "sort out this brain dump", or "run an intake pass". Do NOT use for one question that has to be measured before anyone can plan it. That is `claude-groundwork`.
+name: plan-intake
+description: Files a raw brain dump into a numbered intake folder under `.canon/intake/<nn>-<slug>/`, one item per finding carrying a measured problem, a proposed fix, and a verdict. Use when asked to "file this dump", "triage my notes", "work through this list", "sort out this brain dump", or "run an intake pass". Do NOT use for one question that has to be measured before anyone can plan it. That is `plan-groundwork`.
 ---
 
-# Claude intake
+# Plan intake
 
 Intake dispositions many findings in breadth. A dump goes in, an inventory comes out, and every item carries a problem measured against the tree, one proposed fix, and a verdict. The item that turns out to be already settled is the highest-value output, and it is the one thing neither a plan nor a groundwork track has anywhere to put.
 
@@ -14,8 +14,8 @@ Read `${CLAUDE_SKILL_DIR}/../../standards/intake.md` before writing any file in
 The test is one question. Can the item be answered by reading the repository today?
 
 - Yes: intake owns it, and the cost is a session of grepping
-- No, because it needs an experiment or a source outside the project: route it to `claude-groundwork`, where the cost is measured in runs and days
-- Already decided, with only the work left: route it to `claude-feature`
+- No, because it needs an experiment or a source outside the project: route it to `plan-groundwork`, where the cost is measured in runs and days
+- Already decided, with only the work left: route it to `plan-feature`
 
 Apply the test per item rather than per dump. A dump of forty items typically yields one groundwork candidate, so routing the whole dump on its worst item buys a folder nobody can close.
 
@@ -24,13 +24,13 @@ Using the wrong one fails in two shapes. Intake on a question that needs measuri
 ## Guards
 
 - If no dump is given, stop: `❌ No dump to file. Paste the notes or name what to triage.`
-- If the dump is one question rather than a set of findings, stop: `❌ One question, not a dump. Run /claude-groundwork to measure it or /claude-feature to plan it.`
+- If the dump is one question rather than a set of findings, stop: `❌ One question, not a dump. Run /plan-groundwork to measure it or /plan-feature to plan it.`
 - Do not pause for approval between steps. The write scope below is what makes that safe.
 
 ## Write scope
 
 - Write only inside `.canon/intake/<nn>-<slug>/`. A plan file, a task file, a source change, a standard, and a rule all live outside that folder, so this one rule forbids every one of them.
-- There is no exception. Promoting an item onto the board runs through `claude-tasks` after the operator has answered, which is a separate invocation.
+- There is no exception. Promoting an item onto the board runs through `task-board` after the operator has answered, which is a separate invocation.
 - Reading is unrestricted inside the project. Measuring is the work.
 - Treat the folder as gitignored and unbacked. No check reaches its contents, so every rule stated here holds only while a session reads it.
 
@@ -101,14 +101,14 @@ A file the pass only read gets no line, which is what keeps the block short.
 
 **Open questions:** <N> awaiting your call
 
-Next: /claude-intake-answer to answer the `You:` slots from here, or type them
-into the files, then /claude-tasks to promote what is ready
+Next: /plan-intake-answer to answer the `You:` slots from here, or type them
+into the files, then /task-board to promote what is ready
 ```
 
 Use `📂 Resumed` in place of `📂 Opened` on a resume pass.
 
 ## Answering what this pass wrote
 
-The slots this pass leaves empty are answered by editing each cluster file, or from chat through `claude-intake-answer`, which walks the unread items in batches and writes each selection back onto the item it answers. Name that route in the closing line so the operator finds it where they look for it.
+The slots this pass leaves empty are answered by editing each cluster file, or from chat through `plan-intake-answer`, which walks the unread items in batches and writes each selection back onto the item it answers. Name that route in the closing line so the operator finds it where they look for it.
 
 Do not invoke it from here. It is operator-triggered, and a pass that files a dump and answers it in the same run decides items on silence.

package/claude/skills/{claude-intake-answer → plan-intake-answer}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-intake-answer
+name: plan-intake-answer
 description: Scope boundary for answering a filed intake from chat, and the write-back contract that keeps the file rather than the conversation as the record
 ---
 
-# Claude intake answer requirement
+# Plan intake answer requirement
 
 ## Gap
 
@@ -41,8 +41,8 @@ The batching fails a fifth way. A folder holding thirty unread items put as thir
 
 ## Out of scope
 
-- Filing a dump and writing the items, which is `claude-intake` and owns every other write into the folder
-- Promoting an answered item onto the board, which is `claude-tasks` and runs after the answers land
+- Filing a dump and writing the items, which is `plan-intake` and owns every other write into the folder
+- Promoting an answered item onto the board, which is `task-board` and runs after the answers land
 - The item format, the answer contract, and retrieval, which the toolkit's `standards/intake.md` owns and this skill cites
 - The comparable answer slots in groundwork and feature plans, which carry their own contracts and are a separate measurement
 - Deciding when to fire. The skill is user-invoked through `disable-model-invocation`, so answering is the operator's call rather than a description match.

package/claude/skills/{claude-intake-answer → plan-intake-answer}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: claude-intake-answer
-description: Walks an intake folder's unread items and puts them as batched questions in chat, writing each selection back onto the item it answers. Use when asked to "answer the intake", "work through the open items", "answer my intake questions", "go through the dump", or "let me answer these from here". Do NOT use to file a dump or write new items, which is `claude-intake`.
+name: plan-intake-answer
+description: Walks an intake folder's unread items and puts them as batched questions in chat, writing each selection back onto the item it answers. Use when asked to "answer the intake", "work through the open items", "answer my intake questions", "go through the dump", or "let me answer these from here". Do NOT use to file a dump or write new items, which is `plan-intake`.
 disable-model-invocation: true
 ---
 
-# Claude intake answer
+# Plan intake answer
 
 Put an intake folder's unread items as batched questions, then land each selection in the slot it answers.
 
@@ -14,11 +14,11 @@ Read `${CLAUDE_SKILL_DIR}/../../standards/intake.md` before writing anything. It
 
 ## Guards
 
-- If `canon intake list --json` reports no folder, stop: `❌ No intake to answer. Run /claude-intake to file a dump first.`
+- If `canon intake list --json` reports no folder, stop: `❌ No intake to answer. Run /plan-intake to file a dump first.`
 - If the named folder has no unread item, stop: `❌ Every item in <slug> carries an answer. Nothing to ask.`
 - Never fill a slot the operator did not answer. An abandoned batch leaves every unreached item unread, which is what the empty slot already means.
 - Never infer an answer from the conversation having happened. A selection reaches the file through the verb or not at all.
-- Do not promote an item, edit a verdict, or write outside the answer slots. Promoting runs through `claude-tasks` after the answers land.
+- Do not promote an item, edit a verdict, or write outside the answer slots. Promoting runs through `task-board` after the answers land.
 
 ## Step 1: pick the folder
 

package/claude/skills/{claude-address-review → review-address}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-address-review
+name: review-address
 description: What the review return leg is for, the gaps it closes, and why the push lands before the reply
 ---
 
-# Claude address review requirement
+# Review address requirement
 
 ## Gap
 
@@ -50,8 +50,8 @@ A declined finding fails on a third axis, which is where its reason ends up. A w
 
 ## Out of scope
 
-- Writing the review, which `claude-pr-review` owns. The split is by side of the channel: that one posts findings from an independent session and this one is the worker's return leg.
+- Writing the review, which `review-pr` owns. The split is by side of the channel: that one posts findings from an independent session and this one is the worker's return leg.
 - Staging, committing, and pushing the follow-up, which `git-followup` owns under this skill's direction
-- Refreshing the `.claude/` docs the fixes made stale, which `claude-docs` owns
+- Refreshing the `.claude/` docs the fixes made stale, which `docs-fold` owns
 - Re-reviewing its own fixes, which hands back to the orchestrator
-- Re-reading a rewritten branch, which `claude-pr-review` absorbs by testing whether the prior reviewed commit still reaches the head and paying for a full pass when it does not
+- Re-reading a rewritten branch, which `review-pr` absorbs by testing whether the prior reviewed commit still reaches the head and paying for a full pass when it does not

package/claude/skills/{claude-address-review → review-address}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: claude-address-review
-description: Pulls review findings and CI status on the current branch's open PR, fixes each in the working tree, refreshes any stale `.claude/` docs, replies with a summary comment, and pushes a follow-up commit. The worker's return leg after `claude-pr-review`. Use when asked to "address the review", "fix the PR comments", "respond to review", or after an orchestrator posts findings. Do NOT use to write a review. That is `claude-pr-review`.
+name: review-address
+description: Pulls review findings and CI status on the current branch's open PR, fixes each in the working tree, refreshes any stale `.claude/` docs, replies with a summary comment, and pushes a follow-up commit. The worker's return leg after `review-pr`. Use when asked to "address the review", "fix the PR comments", "respond to review", or after an orchestrator posts findings. Do NOT use to write a review. That is `review-pr`.
 ---
 
-# Claude address review
+# Review address
 
-The worker's half of the review channel. `claude-pr-review` posts findings to
+The worker's half of the review channel. `review-pr` posts findings to
 the PR from an independent session. This skill consumes them: fix, reply, push.
 
 ## Guards
@@ -46,7 +46,7 @@ Do not push a red follow-up.
 
 ## Step 4: refresh stale docs
 
-The fixes may have changed or added behavior that `.claude/` context entries, docs, or wireframes describe. Refresh them with the `claude-docs` skill, which maps the changed files to the entries that reference them and rewrites the stale sections. Do not reimplement that mapping here. When a fix adds a new capability with no existing entry, `claude-docs` flags it rather than creating one.
+The fixes may have changed or added behavior that `.claude/` context entries, docs, or wireframes describe. Refresh them with the `docs-fold` skill, which maps the changed files to the entries that reference them and rewrites the stale sections. Do not reimplement that mapping here. When a fix adds a new capability with no existing entry, `docs-fold` flags it rather than creating one.
 
 ## Step 5: rebase a stale branch
 
@@ -245,7 +245,7 @@ Do not merge. Hand back to the orchestrator for re-review.
 
 Not everything worth reaching the reviewing session surfaces inside the numbered flow above. A worker that settled a risk, filed a follow-up, or found something else worth reporting after Step 7 already closed the review posts it directly rather than waiting on a review pass that has nothing left to trigger it. Write the body the way Step 6 writes a reply: load `write-human` for voice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for the banned words, and run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan before posting with `canon labels scan --body-file .canon/tmp/address-review/reply-<number>.md`.
 
-Open with `## Post-review findings` rather than `## Review response`, since nothing on the thread is being answered. `claude-pr-review` states the full heading set this belongs to and routes it the same as a response: `claude-orchestrate`'s poll picks it up and sends the reviewing session back for a pass. Close the body with `🤖 Addressed by Claude Code` on its own line, matching the reply's footer.
+Open with `## Post-review findings` rather than `## Review response`, since nothing on the thread is being answered. `review-pr` states the full heading set this belongs to and routes it the same as a response: `role-orchestrator`'s poll picks it up and sends the reviewing session back for a pass. Close the body with `🤖 Addressed by Claude Code` on its own line, matching the reply's footer.
 
 ```bash
 gh pr comment <number> --body-file .canon/tmp/address-review/reply-<number>.md

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

@@ -5,7 +5,7 @@ description: The stash-and-rebase sequence, the conflict resolution rules, and t
 
 # Rebase a stale branch
 
-Mechanics for Step 5 of `claude-address-review` once `git merge-tree` exits non-zero. A branch that still merges skips this file entirely, which is the ordinary run.
+Mechanics for Step 5 of `review-address` once `git merge-tree` exits non-zero. A branch that still merges skips this file entirely, which is the ordinary run.
 
 ## The sequence
 

package/claude/skills/{claude-review → review-branch}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-review
+name: review-branch
 description: What local review is for, the gaps it closes, and why it reports without fixing
 ---
 
-# Claude review requirement
+# Review branch requirement
 
 ## Gap
 
@@ -34,6 +34,6 @@ Without this skill, a branch ships on the confidence of the session that wrote i
 
 ## Out of scope
 
-- Reviewing an open pull request, which `claude-pr-review` owns. The split is by vantage: this one reviews local work for the session that wrote it and writes to disk.
+- Reviewing an open pull request, which `review-pr` owns. The split is by vantage: this one reviews local work for the session that wrote it and writes to disk.
 - Deciding whether the findings block the ship. This skill grades and the caller gates.
-- Fixing anything it found, which `claude-address-review` owns once the work is on a pull request
+- Fixing anything it found, which `review-address` owns once the work is on a pull request

package/claude/skills/{claude-review → review-branch}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-review
+name: review-branch
 description: Reviews all changes since main for bugs, edge cases, and logic flaws. Reads CLAUDE.md, REQUIREMENTS.md, and ARCHITECTURE.md for context, then applies a structured review to the full diff and outputs a findings report. Coding standards from `.claude/rules/` are auto-loaded by Claude Code. Use when asked to review changes, run a code review, or check the current branch. Do NOT auto-trigger on vague signals like "looks good" or "can you check this". Require an explicit review request or an autoship invocation.
 ---
 
-# Claude review
+# Review branch
 
 ## Guards
 
@@ -114,7 +114,7 @@ If nothing is wrong, use: `✅ No findings.`
 
 Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
 
-Write the full report directly to `.canon/review/branch/review-<slug>.md` at the main worktree root, not the current worktree. Resolve that root the way `claude-worktree` does. Create the directory if it does not exist. Always overwrite.
+Write the full report directly to `.canon/review/branch/review-<slug>.md` at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does. Create the directory if it does not exist. Always overwrite.
 
 From a linked worktree the file-editing tools refuse that path, so the report goes out through `Bash`. Send the `mkdir -p` and the heredoc as two plain commands rather than joining them with `&&`, which is refused as compound.
 
@@ -122,7 +122,7 @@ If there are no findings, write `✅ No findings.` to the file with a timestamp.
 
 The `.canon/review/` directory is gitignored. Do not stage or commit the file.
 
-The report is disposable. It outlives the ship chain that reads it, and `claude-docs` sweeps it once the branch it names is gone, because the durable record of what a review found is the comment `claude-pr-review` posts on the pull request. A review run on a branch that never opens one leaves nothing behind once that branch is gone, so fold anything worth keeping into the pull request body or a task finding while the report is still on disk.
+The report is disposable. It outlives the ship chain that reads it, and `docs-fold` sweeps it once the branch it names is gone, because the durable record of what a review found is the comment `review-pr` posts on the pull request. A review run on a branch that never opens one leaves nothing behind once that branch is gone, so fold anything worth keeping into the pull request body or a task finding while the report is still on disk.
 
 ### Chat output
 

package/claude/skills/{claude-pr-review → review-pr}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-pr-review
+name: review-pr
 description: What the independent pull request review is for, the gaps it closes, and why it posts until nothing is open
 ---
 
-# Claude PR review requirement
+# Review PR requirement
 
 ## Gap
 
@@ -30,7 +30,7 @@ A request written under `## For the reviewer` also reached no reader. The author
 
 - Merge. Review and post, and leave the gate to the human.
 - Publish a claim the skill did not check. A failed fetch and a rebase both strand the prior commit, and only one of them is a rebase.
-- Invent a heading beyond the two it posts and the response heading `claude-address-review` owns, or append a number GitHub already renders
+- Invent a heading beyond the two it posts and the response heading `review-address` owns, or append a number GitHub already renders
 - Review local uncommitted changes
 - Lecture on process. The lenses land as findings, not as asides.
 
@@ -42,6 +42,6 @@ A request written under `## For the reviewer` also reached no reader. The author
 
 ## Out of scope
 
-- Fixing what it finds, which `claude-address-review` owns. The split is by side of the channel: this one posts findings from an independent session and that one consumes them.
-- Reviewing local uncommitted work, which `claude-review` owns. That one writes to disk for the session that wrote the code, and this one posts to a pull request it did not write.
+- Fixing what it finds, which `review-address` owns. The split is by side of the channel: this one posts findings from an independent session and that one consumes them.
+- Reviewing local uncommitted work, which `review-branch` owns. That one writes to disk for the session that wrote the code, and this one posts to a pull request it did not write.
 - Merging, which stays the human's decision