@erclx/canon 4.67.0 → 4.69.0

package/claude/skills/docs-sync/REQUIREMENT.md

@@ -35,7 +35,7 @@ The quiet one is the baseline. A diff resolved against a bare local ref equals H
 
 ## Out of scope
 
-- `.claude/` planning docs, tasks, plans, and context entries: `claude-docs`, which runs immediately before this skill in the ship chain and resolves the same baseline. The split is by audience, so a file's location decides which skill owns it rather than its subject.
-- `CLAUDE.md` and the installed seed docs: `claude-seed-sync`, which reconciles them per section against the toolkit source
+- `.claude/` planning docs, tasks, plans, and context entries: `docs-fold`, which runs immediately before this skill in the ship chain and resolves the same baseline. The split is by audience, so a file's location decides which skill owns it rather than its subject.
+- `CLAUDE.md` and the installed seed docs: `seed-sync`, which reconciles them per section against the toolkit source
 - Changelog entries, which release tooling generates from commit messages
-- Whether the prose conforms to its standards. `claude-standards-audit` reports violations and fixes none, and this skill writes prose it does not audit.
+- Whether the prose conforms to its standards. `standards-audit` reports violations and fixes none, and this skill writes prose it does not audit.

package/claude/skills/docs-sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: docs-sync
-description: Rewrites stale `README.md` and `docs/*.md` sections based on changes since main. Use before staging, or when asked to "sync the public docs", "update the docs in docs/", or "update the README". Do NOT use for the `.claude/` planning surface, which `claude-docs` owns, or for changelog and `CLAUDE.md` updates.
+description: Rewrites stale `README.md` and `docs/*.md` sections based on changes since main. Use before staging, or when asked to "sync the public docs", "update the docs in docs/", or "update the README". Do NOT use for the `.claude/` planning surface, which `docs-fold` owns, or for changelog and `CLAUDE.md` updates.
 ---
 
 # Docs sync

package/claude/skills/draft-and-pick/REQUIREMENT.md

@@ -45,10 +45,10 @@ The refusal strings sit in the body, since the runtime loads that file and ignor
 
 ## Out of scope
 
-- `claude-feature` plans the work once the answer is settled, and declares the pull request boundary its plan carries. This produces the answer to pick from and stops before the plan.
-- `claude-ux-audit` reads source to find roughness and reports it. This takes its input from the operator and changes nothing until they pick.
-- `claude-ux-measure` measures what a running interface costs to paint. This measures whatever a visual claim depends on, which is usually geometry or contrast rather than cost.
-- `claude-ui-test` writes tests for a change already made. This runs before there is a change to test.
+- `plan-feature` plans the work once the answer is settled, and declares the pull request boundary its plan carries. This produces the answer to pick from and stops before the plan.
+- `ux-audit` reads source to find roughness and reports it. This takes its input from the operator and changes nothing until they pick.
+- `ux-measure` measures what a running interface costs to paint. This measures whatever a visual claim depends on, which is usually geometry or contrast rather than cost.
+- `ui-test` writes tests for a change already made. This runs before there is a change to test.
 - `canon-screencast` scripts a recording of something already built. This has nothing built yet.
 - `canon capture`, `canon serve`, and `canon drive` own the render, the address, and the probes, and are invoked rather than reimplemented.
 

package/claude/skills/draft-and-pick/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: draft-and-pick
-description: Drafts several candidates for a decision judged by looking, renders them side by side on one page, hands the operator the addresses, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `claude-feature`. Do NOT use to read source for roughness, which is `claude-ux-audit`, to measure what a running interface costs to paint, which is `claude-ux-measure`, to write tests for a change already made, which is `claude-ui-test`, or to script a recording, which is `canon-screencast`.
+description: Drafts several candidates for a decision judged by looking, renders them side by side on one page, hands the operator the addresses, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, to write tests for a change already made, which is `ui-test`, or to script a recording, which is `canon-screencast`.
 ---
 
 # Draft and pick
@@ -9,14 +9,14 @@ Some decisions are settled by looking rather than by reasoning, and no draft is
 
 ## Guards
 
-- If the request names one answer and asks for it to be built, stop: `❌ This names one answer, so there is nothing to pick between. Use /canon:claude-feature.`
+- If the request names one answer and asks for it to be built, stop: `❌ This names one answer, so there is nothing to pick between. Use /canon:plan-feature.`
 - If the decision has no visible form, stop: `❌ Nothing to look at. Drafting candidates needs a decision a render can show.`
 - Draft no candidate for a decision the operator has not asked to make. A run offering options everywhere spends their attention rather than saving it.
 
 ## Step 1: name the decision and the arms
 
 1. State the decision in one sentence, naming what changes between arms and what stays fixed.
-2. Derive a kebab slug from that sentence. Call the folder every file this run writes to `<dest>` below. `<dest>` is `.canon/tmp/<slug>/`, per `.claude/rules/canon/core/055-scratch.md`. Running inside a live `claude-groundwork` track is the one exception: `<dest>` is the track's own `evidence/<slug>/` instead, since a candidate render is evidence the track's decision file cites rather than spike input.
+2. Derive a kebab slug from that sentence. Call the folder every file this run writes to `<dest>` below. `<dest>` is `.canon/tmp/<slug>/`, per `.claude/rules/canon/core/055-scratch.md`. Running inside a live `plan-groundwork` track is the one exception: `<dest>` is the track's own `evidence/<slug>/` instead, since a candidate render is evidence the track's decision file cites rather than spike input.
 3. Write one arm per candidate, each carrying an id, a label, and what the arm costs. An arm with no stated cost is not an option.
 4. Make the current state arm `0`, so the baseline is a candidate rather than an absence. A decision with nothing shipped yet says so and starts at arm `1`.
 5. Stop at three to five arms. Two is a comparison the operator can hold in prose, and past five the pick stops being a look and becomes a sort.
@@ -66,7 +66,7 @@ Put the choice to the operator through the structured question surface, per `.cl
 
 1. Apply the winning arm to the real surface, in one change.
 2. Close out whatever document stated the decision as open, in the same change, naming the arm that won and the ones that stayed defensible. A pick that changes a surface and records nothing about why leaves the next reader to re-derive it from a diff, and the losing arms are gone by the next step where `<dest>` is deleted. Skip this where nothing stated the decision.
-3. Delete `<dest>` and every losing arm with it, when `<dest>` is the scratch path. A variant left behind there is a second design nobody maintains. Leave `<dest>` in place when it is a live track's `evidence/<slug>/`: `claude-groundwork`'s write scope treats evidence as durable rather than as scratch a session may delete, and the render a decision file cites has to stay where that file points.
+3. Delete `<dest>` and every losing arm with it, when `<dest>` is the scratch path. A variant left behind there is a second design nobody maintains. Leave `<dest>` in place when it is a live track's `evidence/<slug>/`: `plan-groundwork`'s write scope treats evidence as durable rather than as scratch a session may delete, and the render a decision file cites has to stay where that file points.
 4. Report `<dest>` as still standing when the scratch-path delete is refused, naming the path for the operator to remove, rather than closing on a report the tree contradicts. The pick is applied either way, so the run has done its work and the folder is what outlives it.
 5. Report every surface that changed, each on its own line, and name the arm that won by its id and its cost.
 
@@ -86,7 +86,7 @@ Three rules no probe reaches:
 
 Cite these rather than restating them. A step reimplemented here rots against the skill that owns it.
 
-- `claude-feature` plans the work once the pick is made, and declares the pull request boundary that plan carries
+- `plan-feature` plans the work once the pick is made, and declares the pull request boundary that plan carries
 - `write-human` carries the voice for any copy an arm puts in front of a reader
 - `git-stage`, `git-pr`, and `git-followup` carry the commits and the pull request
-- `claude-review` and `claude-address-review` run the review pass
+- `review-branch` and `review-address` run the review pass

package/claude/skills/draft-context/REQUIREMENT.md

@@ -1,6 +1,6 @@
 ---
 name: draft-context
-description: Why a brand-new .claude/context/<domain>.md entry needs a catalog collision check and a confirm step, not the refresh path claude-docs already owns
+description: Why a brand-new .claude/context/<domain>.md entry needs a catalog collision check and a confirm step, not the refresh path docs-fold already owns
 ---
 
 # Context draft requirement
@@ -31,7 +31,7 @@ Without this skill, a session documenting a domain that has no context entry yet
 
 ## Out of scope
 
-- Refreshing an existing `.claude/context/<domain>.md` entry against a diff: `claude-docs`
+- Refreshing an existing `.claude/context/<domain>.md` entry against a diff: `docs-fold`
 - Drafting a `.claude/wireframes/<surface>.md` file: `draft-wireframes`
 - Drafting a `docs/*.md` page: `draft-docs`
 - Drafting a standard, a snippet, or a governance rule: `create-standard`, `create-snippet`, `create-rule`

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

@@ -1,6 +1,6 @@
 ---
 name: draft-context
-description: Drafts a brand-new `.claude/context/<domain>.md` entry against the context standard, checks the catalog for a name-or-topic collision, decides flat-file placement, confirms with the user, then writes. Use when asked to "write a context entry for X", "document the X domain", "add a context entry for X", or "create a .claude/context page for X" where no existing entry covers the domain. Do NOT use to refresh an existing entry against a diff, which is `claude-docs`.
+description: Drafts a brand-new `.claude/context/<domain>.md` entry against the context standard, checks the catalog for a name-or-topic collision, decides flat-file placement, confirms with the user, then writes. Use when asked to "write a context entry for X", "document the X domain", "add a context entry for X", or "create a .claude/context page for X" where no existing entry covers the domain. Do NOT use to refresh an existing entry against a diff, which is `docs-fold`.
 ---
 
 # Context draft
@@ -16,12 +16,12 @@ Read these files in parallel:
 ## Guards
 
 - If no domain is given, stop: `❌ No domain given. Name the domain this entry should cover.`
-- Derive a kebab-case slug from the domain and check whether `.claude/context/<slug>.md` or `.claude/context/<slug>/index.md` already exists. Either resolving means the domain is already covered under that exact name. Stop: `❌ <slug> already has a context entry. Use claude-docs to refresh it instead.`
+- Derive a kebab-case slug from the domain and check whether `.claude/context/<slug>.md` or `.claude/context/<slug>/index.md` already exists. Either resolving means the domain is already covered under that exact name. Stop: `❌ <slug> already has a context entry. Use docs-fold to refresh it instead.`
 
 ## Placement
 
 - Read `.claude/context/index.md` and check every title and description it lists against the domain. The Guards check above only catches an exact-slug collision, and a domain already covered under a different name still resolves here at no extra cost, since this read already runs.
-- Stop the same way on a match: `❌ <path> already covers this domain under a different name. Use claude-docs to refresh it instead.`
+- Stop the same way on a match: `❌ <path> already covers this domain under a different name. Use docs-fold to refresh it instead.`
 - Default a brand-new entry to a flat file, `.claude/context/<slug>.md`. A domain starts as one page's worth of narrative, and the standard only splits it into a folder once it holds three or more sub-areas, which a fresh domain never does on day one.
 
 ## Draft

package/claude/skills/{claude-diagram → draft-diagram}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-diagram
+name: draft-diagram
 description: Why diagrams are a folder of per-kind entries rather than one file, and why the verified marker is spent only on a render that was read back
 ---
 
-# Claude diagram requirement
+# Draft diagram requirement
 
 ## Gap
 
@@ -39,7 +39,7 @@ The verification failure is the expensive one. A mermaid source can satisfy ever
 
 ## Out of scope
 
-- Design tokens and the visual system, which `claude-design-extract` owns
-- UI roughness, which `claude-ux-audit` owns
+- Design tokens and the visual system, which `design-extract` owns
+- UI roughness, which `ux-audit` owns
 - Writing the catalog file, which the index regen owns from frontmatter
 - Deleting a pre-split flat diagrams file after a migration, which stays the user's call

package/claude/skills/{claude-diagram → draft-diagram}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-diagram
-description: Writes per-kind Mermaid diagram entries into `.canon/diagrams/`, covering system context, components, request flow, data pipeline, and deployment. Reads `.claude/ARCHITECTURE.md` and `REQUIREMENTS.md` when present, falls back to a code-structure scan. Use when asked to "draw the architecture", "diagram the system", "show the components", "give me a flow chart", "refresh the deploy diagram", or "visualize the project". Do NOT use for design tokens (use `claude-design-extract`) or UI audits (use `claude-ux-audit`).
+name: draft-diagram
+description: Writes per-kind Mermaid diagram entries into `.canon/diagrams/`, covering system context, components, request flow, data pipeline, and deployment. Reads `.claude/ARCHITECTURE.md` and `REQUIREMENTS.md` when present, falls back to a code-structure scan. Use when asked to "draw the architecture", "diagram the system", "show the components", "give me a flow chart", "refresh the deploy diagram", or "visualize the project". Do NOT use for design tokens (use `design-extract`) or UI audits (use `ux-audit`).
 ---
 
-# Claude diagram
+# Draft diagram
 
 Write one entry per diagram kind. Never rewrite the folder wholesale. A pass that refreshes the deploy view leaves the other four files byte-identical, which is the whole reason the surface is a folder.
 

package/claude/skills/draft-docs/REQUIREMENT.md

@@ -31,5 +31,5 @@ Without this skill, a session drafting documentation for a surface that has no p
 ## Out of scope
 
 - Rewriting or syncing an existing `docs/*.md` section against a diff since main: `docs-sync`
-- The `.claude/` planning surface: `claude-docs`
+- The `.claude/` planning surface: `docs-fold`
 - Drafting a standard, a snippet, or a governance rule: `create-standard`, `create-snippet`, `create-rule`

package/claude/skills/draft-wireframes/REQUIREMENT.md

@@ -31,7 +31,7 @@ Without this skill, a session drafting a wireframe for a surface with no file ye
 
 ## Out of scope
 
-- Stubbing a surface a diff touched, or reporting drift in an existing wireframe against a diff: `claude/skills/claude-docs/references/wireframe-sweep.md`
+- Stubbing a surface a diff touched, or reporting drift in an existing wireframe against a diff: `claude/skills/docs-fold/references/wireframe-sweep.md`
 - Drafting a `.claude/context/<domain>.md` entry: `draft-context`
 - Drafting a `docs/*.md` page: `draft-docs`
 - Drafting a standard, a snippet, or a governance rule: `create-standard`, `create-snippet`, `create-rule`

package/claude/skills/draft-wireframes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: draft-wireframes
-description: Drafts a brand-new `.claude/wireframes/<surface>.md` file against the wireframes standard, walks the tree for a name collision, detects an existing higher visual-design tier without building one, confirms with the user, then writes. Use when asked to "draft a wireframe for X", "write the wireframe for this surface", "add a .claude/wireframes entry for X", or "wireframe this screen" where no surface file covers it yet. Do NOT use to fix a stale TODO stub or report wireframe drift against a diff, which is `claude-docs`'s wireframe-sweep step.
+description: Drafts a brand-new `.claude/wireframes/<surface>.md` file against the wireframes standard, walks the tree for a name collision, detects an existing higher visual-design tier without building one, confirms with the user, then writes. Use when asked to "draft a wireframe for X", "write the wireframe for this surface", "add a .claude/wireframes entry for X", or "wireframe this screen" where no surface file covers it yet. Do NOT use to fix a stale TODO stub or report wireframe drift against a diff, which is `docs-fold`'s wireframe-sweep step.
 ---
 
 # Wireframe draft
@@ -13,7 +13,7 @@ Read these files in parallel:
 - `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for the prose around the fences
 - The `write-human` skill: voice, rhythm, and sentence construction for the prose around the fences
 
-This skill stays fully independent of `claude-docs`'s wireframe coverage sweep, which only ever writes a bare `TODO` stub for a surface a diff touched and reports drift against one a wireframe already covers. Neither the stub nor the drift check is a draft, and this skill never reads or writes through that mechanism.
+This skill stays fully independent of `docs-fold`'s wireframe coverage sweep, which only ever writes a bare `TODO` stub for a surface a diff touched and reports drift against one a wireframe already covers. Neither the stub nor the drift check is a draft, and this skill never reads or writes through that mechanism.
 
 ## Guards
 

package/claude/skills/git-followup/REQUIREMENT.md

@@ -39,5 +39,5 @@ A fix commit answering a review is the sharpest case of the first paragraph, sin
 ## Out of scope
 
 - Opening the pull request, which `git-pr` owns and `git-ship` chains
-- Deciding what to fix from a review, which `claude-address-review` owns. This skill is that flow's push leg and takes the fixes as already made.
+- Deciding what to fix from a review, which `review-address` owns. This skill is that flow's push leg and takes the fixes as already made.
 - Grouping a multi-concern diff, which `git-stage` owns. A follow-up is one concern by definition, which is why this skill stages everything into a single commit.

package/claude/skills/git-followup/SKILL.md

@@ -7,7 +7,7 @@ description: Ships a small self-review edit on the current PR branch by staging,
 
 Ship a small self-review edit on the current PR branch in one pass.
 
-When invoked with `reply-owned`, a caller such as `claude-address-review` posts
+When invoked with `reply-owned`, a caller such as `review-address` posts
 its own reply, so skip the comment in step 7. The push and body sync still run.
 
 ## Guards

package/claude/skills/git-pr/SKILL.md

@@ -154,7 +154,7 @@ printf 'number=%s\nurl=%s\n' "$pr_number" "$pr_url"
 
 ### Post the UI checklist
 
-`claude-ui-test` writes a manual checklist to `.canon/tmp/ui-checklist/<slug>.md` at the main worktree root when a change needs visual verification, with `<slug>` derived per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. This step is the file's sole consumer. Resolve the main root the way `claude-worktree` does (`git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd`) and check for the file there. A missing file means no checklist was produced, and there is nothing to post.
+`ui-test` writes a manual checklist to `.canon/tmp/ui-checklist/<slug>.md` at the main worktree root when a change needs visual verification, with `<slug>` derived per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. This step is the file's sole consumer. Resolve the main root the way `session-worktree` does (`git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd`) and check for the file there. A missing file means no checklist was produced, and there is nothing to post.
 
 When it exists, scan it against `${CLAUDE_SKILL_DIR}/../../standards/publish.md` before posting, the same as the pull request body above. Post it as its own comment on `<number>`, the number the final command above resolved, rather than folding it into the body, since a later push editing the body would overwrite checkboxes a reviewer already ticked:
 
@@ -180,7 +180,7 @@ The `rmdir` is a no-op when another branch's pending checklist still sits in the
 
 Write the `number` the final command printed onto the task the branch is closing. Do not resolve it again. `${CLAUDE_SKILL_DIR}/REQUIREMENT.md` states why: a lookup that resolves by branch alone can return a closed pull request sharing that head, so the number is resolved once and reused rather than re-derived.
 
-The task is the one whose `Plan:` line names the plan this branch implemented. Name that plan by its file, which is `.canon/plans/feature-<slug>.md` at the main worktree root with `<slug>` derived per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. `claude-feature` writes the plan under the branch slug, so the two correspond on any branch that came through the plan-to-execute path. When the session already knows which plan it implemented, because a caller read it earlier in the chain, use that filename instead of re-deriving.
+The task is the one whose `Plan:` line names the plan this branch implemented. Name that plan by its file, which is `.canon/plans/feature-<slug>.md` at the main worktree root with `<slug>` derived per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. `plan-feature` writes the plan under the branch slug, so the two correspond on any branch that came through the plan-to-execute path. When the session already knows which plan it implemented, because a caller read it earlier in the chain, use that filename instead of re-deriving.
 
 ```bash
 canon tasks pull-request <number> --plan feature-<slug> --json
@@ -188,7 +188,7 @@ canon tasks pull-request <number> --plan feature-<slug> --json
 
 The slug is a guess at which plan this branch carries rather than a fact about the task, which is why the verb re-checks it against the board and refuses instead of writing on a near miss. A branch whose slug names no plan file falls to the silent skip below, the same as one whose plan no task cites.
 
-The verb resolves the board at the main worktree root in-process, adds `Pull request: #NNN` under the `Plan:`, `Groundwork:`, `Intake:`, or `Issue:` lines the task already carries, and corrects the number in place when the line exists. This is the route because the write is an edit inside an existing file, which the file-editing tools refuse from a linked worktree and which no shell stream editor may make. That root is the one `claude-worktree` resolves on entry.
+The verb resolves the board at the main worktree root in-process, adds `Pull request: #NNN` under the `Plan:`, `Groundwork:`, `Intake:`, or `Issue:` lines the task already carries, and corrects the number in place when the line exists. This is the route because the write is an edit inside an existing file, which the file-editing tools refuse from a linked worktree and which no shell stream editor may make. That root is the one `session-worktree` resolves on entry.
 
 Skip this silently when the record is `ok: false` and `reason` is `no-board`, `no-match`, or `ambiguous`. Those are the three cases a guessed write would compound: no board, no task naming the plan, or more than one. One task, one pull request, and a wrong match archives the wrong task unattended once the branch merges. Report any other refusal rather than swallowing it.
 

package/claude/skills/git-ship/REQUIREMENT.md

@@ -9,7 +9,7 @@ description: What the ship chain is for, the gaps it closes, and why it does not
 
 Without this skill, the post-feature sequence runs from memory. Doc sync gets skipped, so the pull request ships with planning docs describing the previous scope, or it runs after staging has already closed and its output never reaches a commit. Chaining by hand is also where a session narrates between steps, which turns one flow into a conversation and invites a decision at every boundary.
 
-The sequence also reaches the remote on work nothing re-checked. This skill is the resume point `claude-autoship` names at four of its stop points, including the one a failed verify takes, so the fix the user makes by hand after that stop is pushed with no suite run against it. Every branch shipped so far passed that verify on its first attempt, which is why the path has produced no instance rather than being closed.
+The sequence also reaches the remote on work nothing re-checked. This skill is the resume point `auto-ship` names at four of its stop points, including the one a failed verify takes, so the fix the user makes by hand after that stop is pushed with no suite run against it. Every branch shipped so far passed that verify on its first attempt, which is why the path has produced no instance rather than being closed.
 
 ## Must
 
@@ -38,5 +38,5 @@ The sequence also reaches the remote on work nothing re-checked. This skill is t
 
 ## Out of scope
 
-- Implementation and review, which `claude-autoship` chains ahead of this same sequence. That skill is the full pipeline and this one is the resume point after a stop, which is why the two overlap by design. Verification is the one of the three that belongs on both, since a resume point that trusts the caller's verify trusts a run that stopped.
+- Implementation and review, which `auto-ship` chains ahead of this same sequence. That skill is the full pipeline and this one is the resume point after a stop, which is why the two overlap by design. Verification is the one of the three that belongs on both, since a resume point that trusts the caller's verify trusts a run that stopped.
 - The behavior of each step, owned by the skill invoked. This skill owns the order and nothing else.

package/claude/skills/git-ship/SKILL.md

@@ -7,7 +7,7 @@ description: Runs the full post-feature workflow by syncing docs, staging commit
 
 Run the full post-feature workflow by invoking each skill in sequence using the Skill tool. After each skill returns, invoke the next step immediately in the same response.
 
-Do not output any text between steps and do not wait for user input. Tool permission dialogs are the only interrupts allowed. The final output is `✅ Shipped`, unless a wrapping caller states it closes on its own block, which `claude-autoship` does.
+Do not output any text between steps and do not wait for user input. Tool permission dialogs are the only interrupts allowed. The final output is `✅ Shipped`, unless a wrapping caller states it closes on its own block, which `auto-ship` does.
 
 ## Verify
 
@@ -15,7 +15,7 @@ Run the verify commands `CLAUDE.md` names (lint, typecheck, tests) before the se
 
 When `CLAUDE.md` names no verify command, say so on one line and continue. A project with no suite is not a project with a failing one.
 
-Verify runs ahead of the sync skills so a stop leaves the tree exactly as the user left it. Re-running a suite the caller already ran costs one command, and the path it closes is the one that has no other guard: `claude-autoship` verifies at its own Step 3 and then hands four of its stop points straight back here, so a fix made by hand after one of those stops otherwise reaches the remote with nothing re-run.
+Verify runs ahead of the sync skills so a stop leaves the tree exactly as the user left it. Re-running a suite the caller already ran costs one command, and the path it closes is the one that has no other guard: `auto-ship` verifies at its own Step 3 and then hands four of its stop points straight back here, so a fix made by hand after one of those stops otherwise reaches the remote with nothing re-run.
 
 ## Pre-check
 
@@ -23,17 +23,17 @@ Run `git diff --cached --name-only 2>/dev/null` to check for staged files. If ou
 
 ## Sequence
 
-1. Invoke `canon:claude-memory-capture` to route what this session learned to the context entries that own it and write the residue to `.canon/memory/`
-2. Invoke `canon:claude-docs` to sync internal planning docs against session decisions, folding in the routed facts
+1. Invoke `canon:memory-capture` to route what this session learned to the context entries that own it and write the residue to `.canon/memory/`
+2. Invoke `canon:docs-fold` to sync internal planning docs against session decisions, folding in the routed facts
 3. Invoke `canon:docs-sync` to sync public docs against changes since main
 4. Run `git add -A` to stage any files the sync skills wrote
 5. Invoke `canon:git-stage` to group staged changes and commit by concern
 6. Invoke `canon:git-branch` to rename branch to match conventional format
 7. Invoke `canon:git-pr` to push branch and open pull request
 8. After the PR opens, watch CI. Poll `canon pr checks <number> --json` until the record's `state` leaves `pending`, branching on that field rather than on the exit, and fall back to `gh pr checks <number>` when no record comes back at all, which is a target whose CLI predates the verb. On `passing`, continue. On `failing`, stop the sequence and report the failing check with its URL. Do not auto-fix. This step may output on failure, the one exception to the no-text-between-steps rule.
-9. If step 1 wrote or updated at least one memory file, invoke `canon:claude-memory-review` scoped to those entries to propose fixes while session context is fresh. If the pen got nothing, skip this step.
+9. If step 1 wrote or updated at least one memory file, invoke `canon:memory-review` scoped to those entries to propose fixes while session context is fresh. If the pen got nothing, skip this step.
 
-A caller wrapping this sequence may act between step 7 and step 8, which is the one gap the order leaves open, since the pull request exists there and nothing has read its checks yet. `claude-autoship` marks the pull request draft in it. Nothing else may go there, and a caller that needs a step anywhere else in the sequence is asking for a change to this body rather than for a place to stand.
+A caller wrapping this sequence may act between step 7 and step 8, which is the one gap the order leaves open, since the pull request exists there and nothing has read its checks yet. `auto-ship` marks the pull request draft in it. Nothing else may go there, and a caller that needs a step anywhere else in the sequence is asking for a change to this body rather than for a place to stand.
 
 Capture leads the sequence because a routed fact lands in a context entry, which is a tracked file. Running it after the pull request opens leaves that edit off the branch entirely, so the fact reaches nothing. Memory files are gitignored either way, which is what hid the ordering while capture wrote only those.
 
@@ -50,6 +50,6 @@ Output up to four lines:
 <Memory proposal at .canon/review/memory/memory-review-<slug>.md>
 ```
 
-Omit the second line if nothing routed. Omit the third and fourth if `claude-memory-capture` wrote no memory file this session, since an empty pen means no scoped review and no proposal.
+Omit the second line if nothing routed. Omit the third and fourth if `memory-capture` wrote no memory file this session, since an empty pen means no scoped review and no proposal.
 
-Emit nothing here when a wrapping caller states it closes on its own block. `claude-autoship` is that caller and its block carries these same three trailing lines above a first line naming the draft state, so emitting both reports one run twice. A caller that states no such thing gets this block, which is every direct invocation.
+Emit nothing here when a wrapping caller states it closes on its own block. `auto-ship` is that caller and its block carries these same three trailing lines above a first line naming the draft state, so emitting both reports one run twice. A caller that states no such thing gets this block, which is every direct invocation.

package/claude/skills/git-worktree/REQUIREMENT.md

@@ -14,7 +14,7 @@ Without this skill, linked worktrees accumulate past the point where any of them
 - Resolve merge state per branch from the pull request first, and fall back to local ancestry when no pull request exists
 - Match the ancestry fallback against the branch name alone. `git branch --merged` decorates the current branch and every branch checked out in a linked worktree, which is the whole set this skill enumerates.
 - Remove the worktree and its local branch together, since either one left alone is the state the skill exists to prevent
-- Exclude five kinds of row from the remove set: the main root, the current session's worktree, any dirty tree, any worktree registered from outside the path prefix `claude-worktree` creates under, and any worktree a live session is occupying
+- Exclude five kinds of row from the remove set: the main root, the current session's worktree, any dirty tree, any worktree registered from outside the path prefix `session-worktree` creates under, and any worktree a live session is occupying
 - Give every skipped row a one-word reason, so the skip is a decision the user can overturn rather than a silence
 - Pick exactly one mode. Listing and removing are different requests and inferring both from one invocation removes worktrees the user meant to read about.
 
@@ -33,6 +33,6 @@ Without this skill, linked worktrees accumulate past the point where any of them
 
 ## Out of scope
 
-- Entering a worktree, which `claude-worktree` owns. That skill derives the name and aligns the branch, and this one never creates.
+- Entering a worktree, which `session-worktree` owns. That skill derives the name and aligns the branch, and this one never creates.
 - Deciding which features can run in parallel, which is a planning call rather than a git operation
 - The pull request lifecycle, which `git-pr` and `git-followup` own. This skill reads pull request state and never writes it.

package/claude/skills/git-worktree/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: git-worktree
-description: Lists linked worktrees with PR state and cleans up merged ones. Use when asked to "list worktrees", "clean up worktrees", or after shipping a PR to reclaim slots. Do NOT use to enter a worktree from scratch (use `claude-worktree`).
+description: Lists linked worktrees with PR state and cleans up merged ones. Use when asked to "list worktrees", "clean up worktrees", or after shipping a PR to reclaim slots. Do NOT use to enter a worktree from scratch (use `session-worktree`).
 ---
 
 # Git worktree
 
-List linked worktrees with their PR state and remove the merged ones. For entry, use `claude-worktree`.
+List linked worktrees with their PR state and remove the merged ones. For entry, use `session-worktree`.
 
 ## Shipping order
 
@@ -53,7 +53,7 @@ Determine dirtiness: `git -C <path> status --porcelain` non-empty means `dirty`.
 
 Determine current: the row whose `path` equals `git rev-parse --show-toplevel`. Resolve the root rather than comparing `pwd`, which equals the worktree root only when the session sits at the top of it. A session in any subdirectory would match no row, and the current-worktree exclusion in `cleanup` would pass its own worktree into the remove set.
 
-Determine provenance: a non-main row is `foreign` when its `path` does not start with `<MAIN_ROOT>/.claude/worktrees/`. That prefix is the folder `claude-worktree` creates under, a convention of that skill rather than a fact this one owns. A tree an operator registered by hand anywhere else on disk reads as `foreign`. Step 1 has already marked the main row `main`, so it never reaches this test.
+Determine provenance: a non-main row is `foreign` when its `path` does not start with `<MAIN_ROOT>/.claude/worktrees/`. That prefix is the folder `session-worktree` creates under, a convention of that skill rather than a fact this one owns. A tree an operator registered by hand anywhere else on disk reads as `foreign`. Step 1 has already marked the main row `main`, so it never reaches this test.
 
 Determine occupancy: run `canon sessions list --json` once for the whole enumeration, never once per row. Resolve each enumerated row's `path` and each live session's `worktree` field with `realpath` before comparing, since a session registered from a second clone of this repository reports a path under that clone rather than under `MAIN_ROOT`, and a raw string compare would hold nothing back. A row is `occupied` when a resolved `worktree` from any live session equals its resolved `path`. A resolved session `worktree` outside `MAIN_ROOT` names a different checkout, so it clears no row here and marks none as occupied.
 

package/claude/skills/identity/REQUIREMENT.md

@@ -24,7 +24,7 @@ A session building this without a shared loop restates `draft-and-pick`'s render
 
 - Restate `draft-and-pick`'s render, hand-off, pick, or loop mechanics
 - Add a `## Logo` section to `standards/design.md`'s fixed section set. `src/design/parse.ts` reads a fixed key set, and no outcome behind this skill asks for a schema change.
-- Modify `draft-and-pick`, `claude-design-extract`, `canon capture`, or `canon design render`. This skill composes all four and extending any of them is a separate change.
+- Modify `draft-and-pick`, `design-extract`, `canon capture`, or `canon design render`. This skill composes all four and extending any of them is a separate change.
 - Assume this skill's own invocation frequency needs no check. Whether anything reaches for it beyond an operator typing its name has no answer at creation time, so a review pass some months in should read that back rather than take it on faith.
 
 ## Guards
@@ -37,4 +37,4 @@ A session building this without a shared loop restates `draft-and-pick`'s render
 - Wiring the produced files into a project's own HTML head or manifest, which is a separate edit this skill leaves for the operator to make against their own markup
 - Recording the mark's construction rules in `standards/design.md`, which the task's own constraint keeps out of the fixed section set
 - Mutating an existing logo file directly, which is a direct edit rather than a skill
-- Auditing an implemented UI against its tokens, which `claude-ux-audit` owns
+- Auditing an implemented UI against its tokens, which `ux-audit` owns

package/claude/skills/identity/SKILL.md

@@ -16,7 +16,7 @@ One identity rendered twice: the same mark sized down to an icon sequence and co
 
 Read these in parallel, skipping any that do not exist:
 
-- `.claude/DESIGN.md`: the `## Personality`, `## Color`, and `## Typography` sections, the same three cells `claude-design-extract` Step 2 sources from
+- `.claude/DESIGN.md`: the `## Personality`, `## Color`, and `## Typography` sections, the same three cells `design-extract` Step 2 sources from
 - `.claude/REQUIREMENTS.md`: the `## Personality` paragraph, when `.claude/DESIGN.md` carries none
 - `CLAUDE.md`: the project's stated voice, when neither file above carries a personality signal
 
@@ -38,7 +38,7 @@ Announce which of the two decided the sequence.
 
 ## Step 3: detect the write folder
 
-Check for `public/`, `static/`, or a stack-declared asset folder, taking the first that exists. Fall back to the project root when none is detected, mirroring `claude-design-extract`'s own source-versus-greenfield split. Announce the folder so the operator can move the files if the project's own convention differs.
+Check for `public/`, `static/`, or a stack-declared asset folder, taking the first that exists. Fall back to the project root when none is detected, mirroring `design-extract`'s own source-versus-greenfield split. Announce the folder so the operator can move the files if the project's own convention differs.
 
 ## Step 4: name the decision and the arms
 
@@ -82,5 +82,5 @@ Write folder: <detected <path>|defaulted to project root>. Move the files if thi
 Cite these rather than restating them.
 
 - `draft-and-pick` owns Steps 1 through 5 of the render-and-pick loop, cited above
-- `claude-design-extract` owns building `.claude/DESIGN.md`. This skill only reads it.
+- `design-extract` owns building `.claude/DESIGN.md`. This skill only reads it.
 - `canon capture` owns the render mechanics, its font refusal, and its reported dimensions

package/claude/skills/{claude-markdown-propose → markdown-propose}/REQUIREMENT.md

@@ -1,15 +1,15 @@
 ---
-name: claude-markdown-propose
+name: markdown-propose
 description: Why a markdown rewrite is proposed per file and answered before anything applies, rather than edited live or argued in chat
 ---
 
-# Claude markdown propose requirement
+# Markdown propose requirement
 
 ## Gap
 
-Rewriting a passage in a governing document today means editing it live or arguing in chat, and three surfaces sit near this moment without covering it. `claude-standards-audit` maps changed markdown to the standards claiming it and reports violations, ending on its own description: `Do NOT fix violations. Reporting only.` `canon markdown audit` measures bans and structural checkpoints from package data.
+Rewriting a passage in a governing document today means editing it live or arguing in chat, and three surfaces sit near this moment without covering it. `standards-audit` maps changed markdown to the standards claiming it and reports violations, ending on its own description: `Do NOT fix violations. Reporting only.` `canon markdown audit` measures bans and structural checkpoints from package data.
 
-`claude-review` reports findings on a diff someone already wrote. None of the three drafts a replacement, carries an answer slot, or waits.
+`review-branch` reports findings on a diff someone already wrote. None of the three drafts a replacement, carries an answer slot, or waits.
 
 A review delivered in chat gets applied from memory across files nobody reopened, and nothing records which changes the operator approved. A change nobody agreed to either lands unreviewed, because the session acting on a chat review cannot tell an approved line from an inferred one, or never gets written down at all, because a finding with no draft behind it hands the rewrite back to whoever reads it next.
 
@@ -41,7 +41,7 @@ A second failure compounds the first. A claim copied across several files is cor
 
 ## Out of scope
 
-- Reporting a violation with no drafted replacement, which `claude-standards-audit` and `canon markdown audit` already own
-- Reviewing a diff someone already wrote, which `claude-review` owns
-- Filing a raw brain dump as findings, which `claude-intake` owns
-- Reviewing `.canon/memory/` and proposing promote-or-retire actions per entry, which `claude-memory-review` owns on a different subject with a different answer contract
+- Reporting a violation with no drafted replacement, which `standards-audit` and `canon markdown audit` already own
+- Reviewing a diff someone already wrote, which `review-branch` owns
+- Filing a raw brain dump as findings, which `plan-intake` owns
+- Reviewing `.canon/memory/` and proposing promote-or-retire actions per entry, which `memory-review` owns on a different subject with a different answer contract

package/claude/skills/{claude-markdown-propose → markdown-propose}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-markdown-propose
-description: Reviews a named markdown surface against a named concern, drafts a per-file proposal under `.canon/proposals/<slug>/` carrying a diff and a reason for each change, and stops without editing a source file. Takes the concern and the surface as inputs, such as a claim stated stronger than the record, a fact gone stale, two files disagreeing, or a passage duplicated without derivation. A later invocation applies what the operator answered. Use when asked to "propose a change to CLAUDE.md", "draft a rewrite of this standard", "propose fixes to this doc", "draft alternatives for this passage", or "apply the answered proposals". Do NOT use to report without drafting a replacement (`claude-standards-audit` or `canon markdown audit`), to review a diff already made (`claude-review`), or to file a raw brain dump as findings (`claude-intake`).
+name: markdown-propose
+description: Reviews a named markdown surface against a named concern, drafts a per-file proposal under `.canon/proposals/<slug>/` carrying a diff and a reason for each change, and stops without editing a source file. Takes the concern and the surface as inputs, such as a claim stated stronger than the record, a fact gone stale, two files disagreeing, or a passage duplicated without derivation. A later invocation applies what the operator answered. Use when asked to "propose a change to CLAUDE.md", "draft a rewrite of this standard", "propose fixes to this doc", "draft alternatives for this passage", or "apply the answered proposals". Do NOT use to report without drafting a replacement (`standards-audit` or `canon markdown audit`), to review a diff already made (`review-branch`), or to file a raw brain dump as findings (`plan-intake`).
 ---
 
-# Claude markdown propose
+# Markdown propose
 
 Reviews what a markdown surface says against a named concern and proposes what it should say instead. Writes proposals and stops. The operator answers per change, and a later invocation applies the answered set.
 
@@ -20,12 +20,12 @@ The value is the gate. A rewrite delivered in chat gets applied from memory acro
 
 Two phases share this body, picked by whether a proposal folder already exists for the request's slug.
 
-Derive `<slug>` from the concern and the surface, kebab-case, naming the subject rather than the activity. List `.canon/proposals/` at the main worktree root and match the topic against the folders already there before deriving a fresh one, the same way `claude-intake` matches its own folder. Never match against `.claude/` itself.
+Derive `<slug>` from the concern and the surface, kebab-case, naming the subject rather than the activity. List `.canon/proposals/` at the main worktree root and match the topic against the folders already there before deriving a fresh one, the same way `plan-intake` matches its own folder. Never match against `.claude/` itself.
 
 - No matching folder, or the operator names a concern and a surface: **Propose**.
 - A matching folder exists and the operator says apply, ship, or commit the answers: **Apply**.
 
-All `.canon/proposals/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `claude-worktree` does.
+All `.canon/proposals/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
 
 ## Write scope
 

package/claude/skills/{claude-markdown-propose → markdown-propose}/references/format.md

@@ -1,6 +1,6 @@
 # Proposal format reference
 
-Governs the proposal `claude-markdown-propose` writes before it edits anything. The concern being screened is an input and does not change the format.
+Governs the proposal `markdown-propose` writes before it edits anything. The concern being screened is an input and does not change the format.
 
 ## Folder
 

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

@@ -1,9 +1,9 @@
 ---
-name: claude-memory-capture
+name: memory-capture
 description: Which surface a session fact is owed to, what earns a memory file once routing has run, and why capture never edits a context entry itself
 ---
 
-# Claude memory capture requirement
+# Memory capture requirement
 
 ## Gap
 
@@ -27,7 +27,7 @@ The threshold is what the remaining folder lives or dies on. A first-occurrence
 
 ## Must not
 
-- Edit a context entry, which `claude-docs` owns
+- Edit a context entry, which `docs-fold` owns
 - Route a feedback, user, or reference candidate, since no context entry owns how to work or who to ask
 - Route anything when the caller does not commit, because a context entry is a tracked file
 - Hand-append a row to the memory index, which is generated from sibling frontmatter
@@ -45,6 +45,6 @@ The threshold is what the remaining folder lives or dies on. A first-occurrence
 
 ## Out of scope
 
-- Editing the context entries themselves, which `claude-docs` owns on its own pass
-- Curating what is already in the folder, which `claude-memory-review` owns
+- Editing the context entries themselves, which `docs-fold` owns on its own pass
+- Curating what is already in the folder, which `memory-review` owns
 - Promoting an entry into an instruction file or a skill body, which mutates how the agent operates and ships as its own change

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

@@ -1,11 +1,11 @@
 ---
-name: claude-memory-capture
-description: Extracts durable patterns from the current session, routes a domain fact to the context entry that owns it, and writes the residue to `.canon/memory/` as feedback, project, user, or reference files. Use when asked to "capture memory", "capture lessons", "wrap up the session", "end of session memory", or as a step in autoship. Do NOT use to curate existing memory. Use `claude-memory-review` for that.
+name: memory-capture
+description: Extracts durable patterns from the current session, routes a domain fact to the context entry that owns it, and writes the residue to `.canon/memory/` as feedback, project, user, or reference files. Use when asked to "capture memory", "capture lessons", "wrap up the session", "end of session memory", or as a step in autoship. Do NOT use to curate existing memory. Use `memory-review` for that.
 ---
 
-# Claude memory capture
+# Memory capture
 
-Scan the current session for patterns worth persisting, send each to the surface that owns it, and leave in `.canon/memory/` only what no surface owns. Pair with `claude-memory-review` for later curation.
+Scan the current session for patterns worth persisting, send each to the surface that owns it, and leave in `.canon/memory/` only what no surface owns. Pair with `memory-review` for later curation.
 
 A fact about a domain belongs in that domain's context entry, which the three-tier model already loads on demand. Writing it to memory instead puts it in a folder nothing opens. Routing is therefore the point of this skill and the memory file is the fallback.
 
@@ -13,11 +13,11 @@ The filename and its type prefix, the frontmatter, the body shape each type carr
 
 ## Guards
 
-- All `.canon/memory/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `claude-worktree` does.
+- All `.canon/memory/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
 - From a linked worktree the file-editing tools refuse every path below, so each write in this skill goes out through `Bash` as a plain single command. A memory entry holds one fact and this session has read it, so an update rewrites the whole file with a heredoc rather than editing a line inside it.
 - If `.canon/memory/` does not exist at the main worktree root, create it, along with an `index.md` carrying `title` and `subtitle` frontmatter. `canon claude init` seeds both, and a project predating that seed has neither. Regeneration errors without the index, so the first write into a bare folder would report a frontmatter failure against a file that is fine.
 - If the session produced no user corrections, confirmations, or context disclosures worth persisting, stop: `✅ Nothing worth capturing.`
-- Routing edits a tracked file, so it runs only where the caller commits. When the session is in the main worktree, or the caller states it does not commit, skip Step 3 and write every candidate as a memory file. `claude-orchestrate` is the caller this covers.
+- Routing edits a tracked file, so it runs only where the caller commits. When the session is in the main worktree, or the caller states it does not commit, skip Step 3 and write every candidate as a memory file. `role-orchestrator` is the caller this covers.
 
 ## Step 1: read context
 
@@ -44,7 +44,7 @@ For each project candidate, match its subject against `.claude/context/index.md`
 
 Fail closed. A project candidate matching no entry stays a memory file, and so does one matching two entries where neither is clearly the owner. The residue is what the folder is for, and a fact filed under the wrong entry is worse than one in memory because a context entry is a surface sessions trust.
 
-Do not edit a context entry here. `claude-docs` owns those edits and folds the routed facts in on its own pass, or two skills write one file at the same step. Write each routed fact to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root instead, appending when the file exists. Name the heading with the entry's own path from `.claude/context/index.md`, flat or the nested `index.md`, since that heading is what tells `claude-docs`'s routed-facts fold which file to open. An append is a whole-file operation the shell does directly, so send it as a plain single `Bash` command carrying a heredoc:
+Do not edit a context entry here. `docs-fold` owns those edits and folds the routed facts in on its own pass, or two skills write one file at the same step. Write each routed fact to `.canon/tmp/memory-routing/<slug>.md` at the main worktree root instead, appending when the file exists. Name the heading with the entry's own path from `.claude/context/index.md`, flat or the nested `index.md`, since that heading is what tells `docs-fold`'s routed-facts fold which file to open. An append is a whole-file operation the shell does directly, so send it as a plain single `Bash` command carrying a heredoc:
 
 A flat domain takes:
 
@@ -64,7 +64,7 @@ A domain split into a folder takes its own generated index instead:
 
 Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
 
-The handoff is a file rather than a spoken result so the routed fact survives a compaction between this step and the `claude-docs` pass, and so the standalone caller leaves something behind for a later `/claude-docs` to consume.
+The handoff is a file rather than a spoken result so the routed fact survives a compaction between this step and the `docs-fold` pass, and so the standalone caller leaves something behind for a later `/docs-fold` to consume.
 
 ## Step 4: dedupe
 
@@ -94,17 +94,17 @@ Respond with one line per fact routed, written, or updated:
 - `✅ Wrote: .canon/memory/<file> (<type>)`
 - `✏️ Updated: .canon/memory/<file> (<type>)`
 
-When anything routed, add a line naming the handoff so the caller knows a `claude-docs` pass is owed:
+When anything routed, add a line naming the handoff so the caller knows a `docs-fold` pass is owed:
 
-`→ Routed facts wait at .canon/tmp/memory-routing/<slug>.md. Run /claude-docs to fold them in.`
+`→ Routed facts wait at .canon/tmp/memory-routing/<slug>.md. Run /docs-fold to fold them in.`
 
-Omit that line when the caller runs `claude-docs` itself later in its own chain.
+Omit that line when the caller runs `docs-fold` itself later in its own chain.
 
 When at least one memory file was written or updated, add a closing line so the standalone caller proposes fixes while context is fresh:
 
-`→ Run /claude-memory-review to propose fixes for the pen before the session ends.`
+`→ Run /memory-review to propose fixes for the pen before the session ends.`
 
-The ship skills run review Propose themselves, so this line is for the standalone `/claude-memory-capture` path.
+The ship skills run review Propose themselves, so this line is for the standalone `/memory-capture` path.
 
 If nothing was captured, output: