@erclx/canon 4.6.1 → 4.8.0

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

@@ -25,10 +25,10 @@ session's review are different passes, and how a feature is sized.
 
 Read the board in parallel, resolving the paths at the main worktree root per Worktrees in `CLAUDE.md`:
 
-- `.claude/tasks/priority.md`: execution order and what each task is waiting on
-- `.claude/tasks/backlog.md`: what is not being scheduled, when the file exists
-- `.claude/tasks/index.md`: what is queued
-- `.claude/plans/*.md`: features already planned and ready to hand off
+- `.canon/tasks/priority.md`: execution order and what each task is waiting on
+- `.canon/tasks/backlog.md`: what is not being scheduled, when the file exists
+- `.canon/tasks/index.md`: what is queued
+- `.canon/plans/*.md`: features already planned and ready to hand off
 - open PRs via `gh pr list --json number,title,headRefName,isDraft`
 
 Then output the state of play so the human knows what to launch, review, and merge.
@@ -59,7 +59,7 @@ Orchestrator ready.
 Ready to build (hand each to its own worker):
 
 <feature>
-  plan: .claude/plans/feature-<slug>.md
+  plan: .canon/plans/feature-<slug>.md
   → /claude-autoship
 
 <feature>
@@ -85,7 +85,7 @@ Omit any section with nothing in it. Recommend a handoff only for a plan whose f
 
 `In flight` covers the state between the other two, which lasts ten to thirty minutes and is most of what an operator sees once this session dispatches its own workers. Before it existed, a session holding running workers reported them under no section and invented a shape per report, which the block below forbids two paragraphs down while giving it no term to use. Read the progress figures off each worker's worktree rather than from the worker, since a busy status says a session is alive and nothing about whether it is moving, and name the model because a dispatcher now picks one per row.
 
-Leave a plan out of `Ready to build` once a row in flight names it. The plan file stays in `.claude/plans/` for the whole build, so listing it there recommends handing off work already underway, and the disjointness rule below withdraws the recommendation only for a reader who already knows what is running.
+Leave a plan out of `Ready to build` once a row in flight names it. The plan file stays in `.canon/plans/` for the whole build, so listing it there recommends handing off work already underway, and the disjointness rule below withdraws the recommendation only for a reader who already knows what is running.
 
 The block opens on the board rather than on a version, because no committed file states one. Adding a version line here would restate what a reader can already see on the rows, dated by nothing, which is how the retired sequencing surface produced an unsourced claim on every run.
 
@@ -164,7 +164,7 @@ It counts unclaimed plans against workers rather than reading the reserve in ste
 3. Archive what closed.
    - A task whose outcomes are all `[x]` runs `claude-docs` for the plan sweep, then `claude-tasks` to archive
    - A task whose outcomes describe standing policy rather than a deliverable never closes on its own, so hand it to a worker to encode the policy where it is enforced, then cut the outcomes with the reason recorded and archive once that branch merges. Encoding it from this session would write a tracked file, which Boundaries forbids.
-4. Read `.claude/tasks/priority.md` and count entries under its `## Run now` heading that carry a written plan. Keep one in reserve beyond what is running.
+4. Read `.canon/tasks/priority.md` and count entries under its `## Run now` heading that carry a written plan. Keep one in reserve beyond what is running.
 5. Promote from the top of `## Needs a plan`, which is where the last sweep recorded what to plan next. Depart from that order when something has changed under it and say what changed, since a position nobody honors is the ordering going stale on the surface built to hold it. What sets the order in the first place is whether a task establishes functionality rather than how old it is, so prefer a task that adds or proves a mechanism over one that trims, tidies, or audits an existing surface.
    - Re-take the board-or-backlog call while the file is open. A row that has stopped being near-term moves to `backlog.md`, and a backlogged task the last wave made near-term moves onto the board. Both are one line removed from one surface and written to the other, and the standard states the test.
 6. Before promoting a candidate, list the files it touches against every task already running, per Parallelism below. Name the overlap and serialize when the sets are not disjoint.
@@ -191,7 +191,7 @@ Do not promote a task to fill the queue when nothing qualifies. A thin queue is
 
 ### Writing the board
 
-Promoting, demoting, and archiving a row all write `.claude/tasks/priority.md`, and this session is the only writer apart from `canon tasks archive`. Moving a task between the board and `.claude/tasks/backlog.md` writes both files, and this session is that file's only writer.
+Promoting, demoting, and archiving a row all write `.canon/tasks/priority.md`, and this session is the only writer apart from `canon tasks archive`. Moving a task between the board and `.canon/tasks/backlog.md` writes both files, and this session is that file's only writer.
 
 - Edit the file with the file-editing tool. A shell stream editor and an inline string replace both exit clean on a non-match, so a promotion that matched nothing leaves the board wrong with nothing reporting it, and the file-editing tool errors instead.
 - Write both halves of a move before reporting it. A row removed from one surface and not written to the other leaves a task file nothing names, and the folder is gitignored with no history to recover the row from. `canon tasks validate` reports that state, so run it after any move.
@@ -201,7 +201,7 @@ Promoting, demoting, and archiving a row all write `.claude/tasks/priority.md`,
 - Re-resolve every Plan pointer after anything archives a plan
 - Read the file back after writing it, since the row that lands is the row a worker acts on
 
-A Plan pointer goes stale from a branch this board never sees. `claude-docs` moves a plan to `.claude/plans/archive/` and rewrites the citation in the task file alone, so a row for a task still on the board keeps pointing into `.claude/plans/` at a file that has moved. Workers running the ship chain on their own branches archive plans this board still cites, and the board reads as correct until a pointer is followed.
+A Plan pointer goes stale from a branch this board never sees. `claude-docs` moves a plan to `.canon/plans/archive/` and rewrites the citation in the task file alone, so a row for a task still on the board keeps pointing into `.canon/plans/` at a file that has moved. Workers running the ship chain on their own branches archive plans this board still cites, and the board reads as correct until a pointer is followed.
 
 ## Parallelism
 

package/claude/skills/claude-orchestrate/references/orchestrator-dispatch.md

@@ -17,7 +17,7 @@ Run `canon tasks plan-answers <plan> --json` and read `launchable` off the recor
 
 - `launchable: true`: the plan answers itself, so proceed to the branch check.
 - `launchable: false`: the row is not dispatchable. Report every entry in `open`, each carrying the question label and the reason its suggestion gave for needing a person, and hand the row to the human-launch line below. Never fill the slot on the operator's behalf, which is the one move the plan standard forbids outright.
-- `reason: archived`: the row's plan sits in `.claude/plans/archive/` and describes work that already shipped. Repoint the row at a live plan rather than dispatching, since `claude-autoship` Step 1 refuses the same file and the worker would meet that refusal after the launch spent.
+- `reason: archived`: the row's plan sits in `.canon/plans/archive/` and describes work that already shipped. Repoint the row at a live plan rather than dispatching, since `claude-autoship` Step 1 refuses the same file and the worker would meet that refusal after the launch spent.
 - The command refuses for any other reason, or the record carries no `launchable` key: treat the row as unverified rather than clear, name what could not be read, and fall back to the human. A gate that reads nothing and proceeds is the gate not running.
 
 Branch on `launchable` rather than on the exit code, which a shell function wrapping `canon` can flatten to zero and so read a held row as a clear one.

package/claude/skills/claude-orchestrate/references/orchestrator-parked.md

@@ -15,7 +15,7 @@ The sweep's own question stays distinct from this one. It asks which parked row
 
 ## Scope
 
-Every row under `## Up next` and `## Needs a plan` in `.claude/tasks/priority.md`. A `## Run now` row carries no blocker by definition, so the pass skips it. Resolve the board and each task file at the main worktree root, per Worktrees in `CLAUDE.md`.
+Every row under `## Up next` and `## Needs a plan` in `.canon/tasks/priority.md`. A `## Run now` row carries no blocker by definition, so the pass skips it. Resolve the board and each task file at the main worktree root, per Worktrees in `CLAUDE.md`.
 
 Take the rows in board order and finish one before opening the next. Clearing a row changes what the next row collides with, so a pass that measures every row first and writes afterwards writes against a board it has already invalidated.
 

package/claude/skills/claude-orchestrate/references/orchestrator-poll.md

@@ -54,7 +54,7 @@ Every classification line names a pull request and a state. A line starting `pol
 
 The script exits non-zero and classifies nothing when the open pull request list itself fails to load. That case would otherwise report every tracked pull request as merged, so the baseline is left untouched and the run says so.
 
-The baseline lives at `.claude/.tmp/pr-poll/baseline.txt` under the main worktree root and is per-machine. A first run against a board already in flight reports each open pull request once before it settles.
+The baseline lives at `.canon/tmp/pr-poll/baseline.txt` under the main worktree root and is per-machine. A first run against a board already in flight reports each open pull request once before it settles.
 
 The five review headings the script matches are written by `claude-pr-review` and `claude-address-review`, and the whole set is stated once in the first. A project that posts its reviews under different headings edits the jq filters in the script to match, or every pull request reads as never reviewed.
 

package/claude/skills/claude-orchestrate/references/orchestrator-resume.md

@@ -6,7 +6,7 @@ description: What to read back after a compaction, and how to treat a groundwork
 Resume as orchestrator after a compaction. Read the board and the groundwork behind the live work before answering anything, because a compaction summary keeps conclusions and drops the reasoning that produced them.
 
 1. Resolve the main worktree root with `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd`. Every path below resolves against it.
-2. Read `.claude/tasks/priority.md` for the ordering and what each task waits on. Read the newest `.claude/tasks/session-*.md` when one exists, per `${CLAUDE_SKILL_DIR}/../../standards/session.md`, and treat it as the previous session's scratch rather than a source.
+2. Read `.canon/tasks/priority.md` for the ordering and what each task waits on. Read the newest `.canon/tasks/session-*.md` when one exists, per `${CLAUDE_SKILL_DIR}/../../standards/session.md`, and treat it as the previous session's scratch rather than a source.
 3. Read the task file for every entry under `## Run now`, plus any entry a live pull request names.
 4. Read the groundwork folder each of those tasks cites. Read `README.md` for the file map, then `06-decision.md` when the track is closed, or `07-next-session.md` and the numbered topic files when it is open. A task's Findings section is a lossy summary of its track, so planning against the summary re-derives what the folder already settled.
 5. Run `gh pr list --state open` and `git log --oneline -5` to see what shipped since the folder was written.

package/claude/skills/claude-orchestrate/scripts/poll.sh

@@ -18,7 +18,7 @@ if [ -z "$MAIN_ROOT" ]; then
   echo "poll: not a git repository, so nothing is classified" >&2
   exit 1
 fi
-STATE_DIR="$MAIN_ROOT/.claude/.tmp/pr-poll"
+STATE_DIR="$MAIN_ROOT/.canon/tmp/pr-poll"
 mkdir -p "$STATE_DIR"
 STATE="$STATE_DIR/baseline.txt"
 touch "$STATE"

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

@@ -42,7 +42,7 @@ before what, and whether a row should run at all stay with the controlling
 session, and no body states that boundary for the planning side.
 
 Nothing scans a plan for banned words either. `.gitignore` ignores
-`.claude/plans/`, and the audit's default path set is what git lists, so no gate
+`.canon/plans/`, and the audit's default path set is what git lists, so no gate
 ever opens one. Six ban hits landed across the four trial plans and three of the
 four carried at least one, caught only because the planner ran
 `canon markdown audit` unprompted.

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

@@ -21,9 +21,9 @@ from here.
 
 ## Where the session stands
 
-- Write one file, the plan, at `.claude/plans/feature-<slug>.md` on the main worktree root. Everything else this session touches is a read.
+- Write one file, the plan, at `.canon/plans/feature-<slug>.md` on the main worktree root. Everything else this session touches is a read.
 - Never enter a worktree, never create a branch, and never write a tracked file. A planner that builds has stopped being one, and the row loses the independent read the worker's own session was going to bring to it.
-- Resolve `.claude/plans/`, `.claude/tasks/`, and `.claude/review/` at the main worktree root. Those folders are gitignored, so a copy beside a linked worktree is absent rather than empty.
+- Resolve `.canon/plans/`, `.canon/tasks/`, and `.canon/review/` at the main worktree root. Those folders are gitignored, so a copy beside a linked worktree is absent rather than empty.
 - Plan the row the launch named. Report a second row met while reading rather than planning it, since which rows run is the controller's call.
 
 ## What to read before deciding
@@ -33,9 +33,9 @@ Each item below is something a plan needed and a launch string did not carry.
 - The task file, and its `## Findings` before deciding anything. A row can carry its own disproof under a title that still states the original claim, which is how one trial nearly planned against a premise the file had already recorded as dead.
 - The source files themselves, opened rather than summarized. Never a count quoted from the task file, which was wrong or stale in ten places across four plans.
 - `CLAUDE.md` and `.claude/ARCHITECTURE.md`, for the decision and the alternative it was taken against rather than for the decision alone.
-- The plan of any row this one is sequenced behind, including one already moved to `.claude/plans/archive/`. Reading a shipped plan produced the strongest constraint in the first trial and no brief asked for it.
-- `.claude/tasks/priority.md` for the row's Touches column and its stated blocker. That column is the file set the dispatch disjointness gate already reads.
-- `${CLAUDE_SKILL_DIR}/../../standards/plan.md` for the shape, then `canon records validate plans` and `canon markdown audit <the plan file>` on the file once it is written. Nothing else opens a plan, since `.claude/plans/` is gitignored and the audit's default path set is what git lists.
+- The plan of any row this one is sequenced behind, including one already moved to `.canon/plans/archive/`. Reading a shipped plan produced the strongest constraint in the first trial and no brief asked for it.
+- `.canon/tasks/priority.md` for the row's Touches column and its stated blocker. That column is the file set the dispatch disjointness gate already reads.
+- `${CLAUDE_SKILL_DIR}/../../standards/plan.md` for the shape, then `canon records validate plans` and `canon markdown audit <the plan file>` on the file once it is written. Nothing else opens a plan, since `.canon/plans/` is gitignored and the audit's default path set is what git lists.
 
 ## Read what is in flight rather than inferring it
 
@@ -46,7 +46,7 @@ Each item below is something a plan needed and a launch string did not carry.
 
 ## The board is read-only
 
-- Never write `.claude/tasks/priority.md` or `.claude/tasks/backlog.md`. Both are gitignored, so an overwrite drops a row with no history to recover it from.
+- Never write `.canon/tasks/priority.md` or `.canon/tasks/backlog.md`. Both are gitignored, so an overwrite drops a row with no history to recover it from.
 - Never write the task file either. The plan is the whole output, and a row edited from here changes what the controller reads back as the state of the board.
 - Report what the row got wrong rather than repairing it. A stale count, a moved line, or a path that no longer resolves goes into the plan and into the handback, and the controller decides which of the two carries the correction.
 - Leave the cross-feature call alone. Which rows collide, what merges before what, and whether a row should run at all stay with the controller. `priority.md` shows blockers and file sets and is enough to write a confident merge order off a partial picture, which is the failure this boundary exists to prevent.

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

@@ -36,8 +36,8 @@ Read these in parallel from the project root, skipping any that do not exist:
 - `CLAUDE.md`: project type, conventions, and commands
 - `.claude/REQUIREMENTS.md`: feature scope and non-goals
 - `.claude/ARCHITECTURE.md`: technical design decisions
-- `.claude/tasks/priority.md`: where this feature sits on the board and what each neighboring row waits on. Resolve this one at the main worktree root per Worktrees in `CLAUDE.md`, since the board is gitignored and a linked worktree holds no copy of it
-- `.claude/plans/feature-<slug>.md` for the branch, when present: the intent the PR should satisfy
+- `.canon/tasks/priority.md`: where this feature sits on the board and what each neighboring row waits on. Resolve this one at the main worktree root per Worktrees in `CLAUDE.md`, since the board is gitignored and a linked worktree holds no copy of it
+- `.canon/plans/feature-<slug>.md` for the branch, when present: the intent the PR should satisfy
 
 Coding standards from `.claude/rules/` are auto-loaded by Claude Code.
 
@@ -141,7 +141,7 @@ Use severity: `critical` (blocks merge), `should-fix` (fix before merge), `minor
 
 ## Step 4: post to the PR
 
-Write the comment to `.claude/.tmp/pr-review/body-<number>-<short-sha>.md`, which the rest of this step calls `<body-file>`. The PR number stops two sessions reviewing different pull requests from overwriting each other between the write and the post. The head commit stops a second pass overwriting the first one's body, and leaves the folder a record of which commit each review covered.
+Write the comment to `.canon/tmp/pr-review/body-<number>-<short-sha>.md`, which the rest of this step calls `<body-file>`. The PR number stops two sessions reviewing different pull requests from overwriting each other between the write and the post. The head commit stops a second pass overwriting the first one's body, and leaves the folder a record of which commit each review covered.
 
 Derive both segments from Step 1. Never pick a suffix by hand, and never reuse a name the folder already holds.
 
@@ -228,12 +228,12 @@ The `What is right` section is optional, capped at three bullets, and included o
 
 Close the body with `🤖 Reviewed by Claude Code` on its own line so the review reads as an independent machine pass, not a human sign-off.
 
-Before posting, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the body. The hook skips `.claude/.tmp/`, so this scan is the only gate on the published comment. A finding phrased against an internal phase label is what the label half of the scan catches here.
+Before posting, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the body. The hook skips `.canon/tmp/`, so this scan is the only gate on the published comment. A finding phrased against an internal phase label is what the label half of the scan catches here.
 
 Do not run the command below when `<prior-heading>` from Step 2 reads `## Review closed` and this pass carries nothing owed. That pass replaces the standing comment rather than adding one, under `### A close-out that repeats the standing one` at the end of this step. Posting first and reaching that section afterward leaves two close-outs both naming the new head, which is worse than the pair the guard exists against.
 
 ```bash
-gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>-<short-sha>.md
+gh pr review <number> --comment --body-file .canon/tmp/pr-review/body-<number>-<short-sha>.md
 ```
 
 A pass carrying nothing at all takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No findings. Reviewed against project docs and the board.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.`

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

@@ -120,13 +120,13 @@ 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 `.claude/review/branch/review-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. 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. See Worktrees in `CLAUDE.md`. 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.
 
 If there are no findings, write `✅ No findings.` to the file with a timestamp.
 
-The `.claude/review/` directory is gitignored. Do not stage or commit the file.
+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.
 
@@ -136,7 +136,7 @@ Output only the summary line and the file path. Do not repeat the full report in
 
 ```plaintext
 X critical, Y should-fix, Z minor across N files.
-📝 Wrote .claude/review/branch/review-<slug>.md
+📝 Wrote .canon/review/branch/review-<slug>.md
 ```
 
-If no findings: `✅ No findings. Wrote .claude/review/branch/review-<slug>.md`
+If no findings: `✅ No findings. Wrote .canon/review/branch/review-<slug>.md`

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

@@ -68,7 +68,7 @@ Before proposing an Update, grep the target section for the seed text's keywords
 
 Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
 
-Write the full proposal to `.claude/review/seed-audit-<slug>.md` at the main worktree root. Do not print the proposal inline.
+Write the full proposal to `.canon/review/seed-audit-<slug>.md` at the main worktree root. Do not print the proposal inline.
 
 From a linked worktree the file-editing tools refuse that path, so the proposal 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.
 
@@ -123,7 +123,7 @@ Decision:
 
 Update items show both sides in one `diff` block: removed lines from the project version with `-`, added lines from the seed version with `+`, unchanged context lines without a prefix. Add items show only `+` lines. Customized sections appear in the scope table only, never numbered. A file with no drift still appears in the scope table as `in sync`.
 
-After writing, tell the user `✅ Wrote proposal to .claude/review/seed-audit-<slug>.md`. Ask them to fill in `Decision:` per item, then re-ping or use the chat shortcut.
+After writing, tell the user `✅ Wrote proposal to .canon/review/seed-audit-<slug>.md`. Ask them to fill in `Decision:` per item, then re-ping or use the chat shortcut.
 
 Rewrite the review file in place whenever the proposal changes mid-review. The file stays the source of truth for the current decisions.
 

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

@@ -1,6 +1,6 @@
 ---
 name: claude-tasks
-description: Creates a task file in `.claude/tasks/` with the filename, phase label, and frontmatter the standard requires, and archives a shipped one out of the folder. Use when asked to "add a task", "create a task", "queue this", "put this on the board", "archive that task", or "close out a shipped task". Do NOT use to mark an outcome `[x]` or to archive a plan. That is `claude-docs`.
+description: Creates a task file in `.canon/tasks/` with the filename, phase label, and frontmatter the standard requires, and archives a shipped one out of the folder. Use when asked to "add a task", "create a task", "queue this", "put this on the board", "archive that task", or "close out a shipped task". Do NOT use to mark an outcome `[x]` or to archive a plan. That is `claude-docs`.
 ---
 
 # Claude tasks
@@ -13,9 +13,9 @@ Read `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` before writing any file. It
 
 - Resolve the board at the main worktree root, not `pwd`. Run `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd` outside a git repo. Every read and write below resolves against that root. The board is gitignored scratch shared across worktrees, so a linked worktree writing to its own `pwd` creates a second board nothing else reads.
 - From a linked worktree the file-editing tools refuse that root, so a new task file goes out through `Bash` as a plain single command carrying a heredoc. Archiving already runs through `canon tasks archive`, which resolves the root in-process. Marking an outcome shipped is `claude-docs` and runs through `canon tasks outcome`. See Worktrees in `CLAUDE.md`.
-- If `.claude/tasks/` does not exist at that root, stop: `❌ No .claude/tasks/ board. Run canon claude init to set it up.`
+- If `.canon/tasks/` does not exist at that root, stop: `❌ No .canon/tasks/ board. Run canon claude init to set it up.`
 - Route on the request rather than on a flag. Creating names work that does not exist yet, archiving names a task file already on the board. If the request fits neither, stop: `❌ Ambiguous. Say whether to create a task or archive one.`
-- Never hand-edit `.claude/tasks/index.md`. A hook regenerates it from sibling frontmatter after a write. Do not run the regen command directly, except after a shell write from a linked worktree: the hook matches `Write|Edit|MultiEdit` and nothing fires on `Bash`, so that one case regenerates explicitly with `canon indexes regen --no-stage --root <main-root> <main-root>/.claude/tasks/index.md`.
+- Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter after a write. Do not run the regen command directly, except after a shell write from a linked worktree: the hook matches `Write|Edit|MultiEdit` and nothing fires on `Bash`, so that one case regenerates explicitly with `canon indexes regen --no-stage --root <main-root> <main-root>/.canon/tasks/index.md`.
 
 ## Create
 
@@ -29,15 +29,15 @@ Accept work whose origin is the conversation itself only when the user says so e
 
 ### Step 2: propose the phase label
 
-List the existing filenames in `.claude/tasks/` and read `index.md` for what each holds. Propose the next label from what is already on the board, and say which neighbors it sits between.
+List the existing filenames in `.canon/tasks/` and read `index.md` for what each holds. Propose the next label from what is already on the board, and say which neighbors it sits between.
 
 Do not derive the label from a version file. `${CLAUDE_SKILL_DIR}/../../standards/versioning.md` permits free renumbering, so the board is the only surface that knows what a label currently means. Pad the phase to two digits in the filename, since index entries sort by filename alone and a bare `v9.0` sorts after `v15.0`.
 
 ### Step 3: write the file
 
-Write `.claude/tasks/vXX.Y-<slug>.md` following the format in `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Include a link line only when the file or folder it names exists. A link to a plan nobody has written yet is the broken pointer the archive rules exist to prevent.
+Write `.canon/tasks/vXX.Y-<slug>.md` following the format in `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Include a link line only when the file or folder it names exists. A link to a plan nobody has written yet is the broken pointer the archive rules exist to prevent.
 
-Write `Plan:`, `Groundwork:`, and `Intake:` as markdown links relative to `.claude/tasks/`, as in `Plan: [feature-<slug>](../plans/feature-<slug>.md)`. Leave `Issue:` a bare `#NNN`. A task written in the older bare-path form still parses, so it costs the board a clickable line rather than an archive, but it leaves the board in two shapes for every reader after.
+Write `Plan:`, `Groundwork:`, and `Intake:` as markdown links relative to `.canon/tasks/`, as in `Plan: [feature-<slug>](../plans/feature-<slug>.md)`. Leave `Issue:` a bare `#NNN`. A task written in the older bare-path form still parses, so it costs the board a clickable line rather than an archive, but it leaves the board in two shapes for every reader after.
 
 Never write a `Pull request:` line here. `git-pr` adds it when a pull request opens, and a number guessed at create time points at someone else's work.
 
@@ -45,7 +45,7 @@ Write it immediately. Claude Code's tool permission dialog is the confirmation g
 
 ### Step 4: place it on a surface
 
-A task file with no row is a dropped task, so name the surface it lands on in the same pass that creates it. A task that would plausibly be planned within the next few waves takes a row under `## Needs a plan` in `.claude/tasks/priority.md`, positioned by where it sits against the rows already there, with the reason for that position in its `Waiting on` cell. Anything else takes a line in `.claude/tasks/backlog.md`, which is unordered and where in the file it goes means nothing.
+A task file with no row is a dropped task, so name the surface it lands on in the same pass that creates it. A task that would plausibly be planned within the next few waves takes a row under `## Needs a plan` in `.canon/tasks/priority.md`, positioned by where it sits against the rows already there, with the reason for that position in its `Waiting on` cell. Anything else takes a line in `.canon/tasks/backlog.md`, which is unordered and where in the file it goes means nothing.
 
 The test and both file shapes are in `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. From a linked worktree the file-editing tools refuse the main root, so a row lands through the same `Bash` route the file itself took.
 
@@ -55,9 +55,9 @@ Say which surface it went to and why in the report. The call is a judgment resta
 
 Scan for work that has been decided and would otherwise be forgotten. Three origins carry it, and every run reads all three.
 
-List `.claude/groundwork/` and run `gh issue list --state open` when a remote is configured, then grep the board for each track name and issue number. Report any with no task, one line each.
+List `.canon/groundwork/` and run `gh issue list --state open` when a remote is configured, then grep the board for each track name and issue number. Report any with no task, one line each.
 
-Read the dumps through `canon intake list --json`, which reports items, open, unread, and malformed per folder and owns the parse of the answer contract `${CLAUDE_SKILL_DIR}/../../standards/intake.md` fixes. Then grep both `.claude/tasks/` and `.claude/tasks/archive/` for each folder slug. A dump with no live task is the ordinary shape of one already promoted and shipped, so a check reading the board by itself reports every finished folder as abandoned.
+Read the dumps through `canon intake list --json`, which reports items, open, unread, and malformed per folder and owns the parse of the answer contract `${CLAUDE_SKILL_DIR}/../../standards/intake.md` fixes. Then grep both `.canon/tasks/` and `.canon/tasks/archive/` for each folder slug. A dump with no live task is the ordinary shape of one already promoted and shipped, so a check reading the board by itself reports every finished folder as abandoned.
 
 A dump is the stronger case for this scan rather than the weaker one. A track holds one question and stays visible, while a dump holds dozens of items whose verdicts were reached and then left with nothing carrying them forward.
 
@@ -122,7 +122,7 @@ Leave `TASK-ARCHIVE.md` alone when it is present in the archive folder. It recor
 
 ### Step 4: clear prose naming the task
 
-The command drops the task's row from `.claude/tasks/priority.md` and leaves prose alone. Remove any sentence that still names the archived task or counts the rows that changed, since a stale count reads as board state.
+The command drops the task's row from `.canon/tasks/priority.md` and leaves prose alone. Remove any sentence that still names the archived task or counts the rows that changed, since a stale count reads as board state.
 
 ## Output
 
@@ -131,21 +131,21 @@ Emit the full relative path from the project root for every file written or move
 Create:
 
 ```plaintext
-✅ Created: .claude/tasks/vXX.Y-<slug>.md
+✅ Created: .canon/tasks/vXX.Y-<slug>.md
 
 <label> sits between <neighbor> and <neighbor>.
 <board or backlog, and why it landed there>.
 
 **Origin with no task:**
 
-- `.claude/groundwork/<slug>/`: open, touched <date>
-- `.claude/intake/<slug>/`: every item answered, nothing promoted
+- `.canon/groundwork/<slug>/`: open, touched <date>
+- `.canon/intake/<slug>/`: every item answered, nothing promoted
 - #NNN: <issue title>
 
 **Waiting on you:**
 
-- `.claude/intake/<slug>/`: <n> of <n> items unread
-- `.claude/intake/<slug>/`: <n> items carry no answer slot, so no verb reaches them
+- `.canon/intake/<slug>/`: <n> of <n> items unread
+- `.canon/intake/<slug>/`: <n> items carry no answer slot, so no verb reaches them
 ```
 
 Drop either block when it carries no rows. When both are empty, which is the ordinary result, replace them with one line naming what was read: `Read <n> tracks, <n> dumps, and <n> open issues. Nothing unlinked.`
@@ -153,7 +153,7 @@ Drop either block when it carries no rows. When both are empty, which is the ord
 Archive, reporting the paths the command returned:
 
 ```plaintext
-📦 Archived: .claude/tasks/archive/vXX.Y-<slug>.md
+📦 Archived: .canon/tasks/archive/vXX.Y-<slug>.md
 
 <ordering and index disposition in one line>
 ```

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

@@ -118,7 +118,7 @@ Follow `${CLAUDE_SKILL_DIR}/references/lesson-craft.md` for what makes a lesson
 A lesson is a page carrying a stylesheet and a script, and an editor preview opens it with neither, so a path alone delivers unstyled markup that reads as the lesson. Serve the teach root and give the learner a link they can click:
 
 ```bash
-canon serve .claude/teach --entry <nn>-<topic>/index.html --json
+canon serve .canon/teach --entry <nn>-<topic>/index.html --json
 ```
 
 Start it in the background so the session keeps going, and read `url` off the record rather than composing one. The verb walks past a port already in use, so the port it took is exactly the half a guessed URL gets wrong. Report the refusal and its `reason` when `ok` is false, and report it rather than proceeding silently when the verb does not resolve at all, which is an installed CLI predating it.
@@ -149,12 +149,12 @@ Still owed:    <what the destination expects that the page does not carry yet>
 
 Then stop and let the operator strike, redirect, or confirm each block.
 
-Write nothing to a destination here. One skill owns the durable writes, and two skills editing one file at one step is the failure that rule exists against. Record each confirmed block in `.claude/.tmp/teach-promotion/<slug>.md` at the main worktree root instead, appending when the file exists, with one H2 per destination naming its path, the source page beneath it, and the page body fenced:
+Write nothing to a destination here. One skill owns the durable writes, and two skills editing one file at one step is the failure that rule exists against. Record each confirmed block in `.canon/tmp/teach-promotion/<slug>.md` at the main worktree root instead, appending when the file exists, with one H2 per destination naming its path, the source page beneath it, and the page body fenced:
 
 ````markdown
 ## <destination path>
 
-Source: .claude/teach/<nn>-<topic>/reference/<slug>.md
+Source: .canon/teach/<nn>-<topic>/reference/<slug>.md
 
 ```markdown
 <the page body as it should land, with the source line the destination expects>
@@ -172,10 +172,10 @@ An append is a whole-file operation, so send it as a plain single `Bash` command
 ## Output
 
 ```plaintext
-✅ <opened|resumed> .claude/teach/<nn>-<topic>/
-Lesson:    .claude/teach/<nn>-<topic>/lessons/<nnnn>-<slug>.html
-Reference: .claude/teach/<nn>-<topic>/reference/<slug>.md
-Record:    .claude/teach/<nn>-<topic>/learning-records/<nnnn>-<slug>.md
+✅ <opened|resumed> .canon/teach/<nn>-<topic>/
+Lesson:    .canon/teach/<nn>-<topic>/lessons/<nnnn>-<slug>.html
+Reference: .canon/teach/<nn>-<topic>/reference/<slug>.md
+Record:    .canon/teach/<nn>-<topic>/learning-records/<nnnn>-<slug>.md
 Progress:  <n> of <m> success lines met
 Open:      [<the url the serve verb reported>](<the same url>)
 ```
@@ -189,8 +189,8 @@ Emit every path from the project root, in the form the project's instruction fil
 A promotion pass reports its own shape instead, one line per page the operator confirmed and one naming the handoff:
 
 ```plaintext
-➡️ Promoting: .claude/teach/<nn>-<topic>/reference/<slug>.md → <destination path>
-→ Confirmed pages wait at .claude/.tmp/teach-promotion/<slug>.md. Run /claude-docs from a branch to fold them in.
+➡️ Promoting: .canon/teach/<nn>-<topic>/reference/<slug>.md → <destination path>
+→ Confirmed pages wait at .canon/tmp/teach-promotion/<slug>.md. Run /claude-docs from a branch to fold them in.
 ```
 
 A pass where the operator confirmed nothing writes no handoff file and reports that alone.

package/claude/skills/claude-ui-test/SKILL.md

@@ -59,19 +59,19 @@ If all changes are automatable, skip the manual checklist:
 
 Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
 
-When a manual checklist is produced, write it directly to `.claude/review/ui-checklist-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
+When a manual checklist is produced, write it directly to `.canon/review/ui-checklist-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
 
 From a linked worktree the file-editing tools refuse that path, so the checklist 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.
 
 Skip the file write when all changes are covered by e2e tests and no checklist was produced.
 
-The `.claude/review/` directory is gitignored. Do not stage or commit the file.
+The `.canon/review/` directory is gitignored. Do not stage or commit the file.
 
 ## Output order
 
 1. Write and run e2e tests (report pass/fail)
 2. If a manual checklist was produced, write it to file, then output only the file path in chat:
-   `📝 Wrote .claude/review/ui-checklist-<slug>.md`
+   `📝 Wrote .canon/review/ui-checklist-<slug>.md`
 3. If no checklist was needed: `✅ All changes covered by e2e tests. No manual verification needed.`
 
 Do not repeat the full checklist in chat.

package/claude/skills/claude-ux-audit/SKILL.md

@@ -21,7 +21,7 @@ Read these in parallel from the project root, skipping any that do not exist:
 
 ## Step 2: identify surfaces
 
-List the UI surfaces in the project. A surface is a distinct screen, page, panel, or major component (e.g. sidepanel, popup, settings page, empty state). Group files by surface. Do not audit speculative or unfinished code flagged in `.claude/tasks/` as in-progress.
+List the UI surfaces in the project. A surface is a distinct screen, page, panel, or major component (e.g. sidepanel, popup, settings page, empty state). Group files by surface. Do not audit speculative or unfinished code flagged in `.canon/tasks/` as in-progress.
 
 ## Step 3: audit each surface
 
@@ -59,13 +59,13 @@ If nothing is wrong, use: `✅ No observations.`
 
 Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
 
-Write the full report directly to `.claude/review/ux-audit-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
+Write the full report directly to `.canon/review/ux-audit-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. 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.
 
 If there are no observations, write `✅ No observations.` to the file with a timestamp.
 
-The `.claude/review/` directory is gitignored. Do not stage or commit the file.
+The `.canon/review/` directory is gitignored. Do not stage or commit the file.
 
 ### Chat output
 
@@ -73,7 +73,7 @@ Output only the summary line and the file path. Do not repeat the full report in
 
 ```plaintext
 X observations across N surfaces.
-📝 Wrote .claude/review/ux-audit-<slug>.md
+📝 Wrote .canon/review/ux-audit-<slug>.md
 ```
 
-If no observations: `✅ No observations. Wrote .claude/review/ux-audit-<slug>.md`
+If no observations: `✅ No observations. Wrote .canon/review/ux-audit-<slug>.md`

package/claude/skills/claude-ux-measure/SKILL.md

@@ -106,11 +106,11 @@ Report the reading and stop there. A remedy for a poor verdict is a change with
 
 Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
 
-Write the full reading directly to `.claude/review/ux-measure-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
+Write the full reading directly to `.canon/review/ux-measure-<slug>.md` at the main worktree root, not the current worktree. See Worktrees in `CLAUDE.md`. Create the directory if it does not exist. Always overwrite.
 
 From a linked worktree the file-editing tools refuse that path, so the reading 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.
 
-The `.claude/review/` directory is gitignored. Do not stage or commit the file.
+The `.canon/review/` directory is gitignored. Do not stage or commit the file.
 
 ### Chat output
 
@@ -118,5 +118,5 @@ Output the summary line and the file path. Do not repeat the table in chat.
 
 ```plaintext
 3 metrics measured against <url>. <n> past threshold.
-📝 Wrote .claude/review/ux-measure-<slug>.md
+📝 Wrote .canon/review/ux-measure-<slug>.md
 ```

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

@@ -22,13 +22,13 @@ running and re-invoking it would restart the build.
 
 ## Where the session stands
 
-- Resolve `.claude/plans/`, `.claude/tasks/`, `.claude/review/`, and `.claude/memory/` at the main worktree root, never against the linked worktree this session builds in. Those folders are gitignored, so `git worktree add` never creates them and the copy beside the build is absent rather than empty.
+- Resolve `.canon/plans/`, `.canon/tasks/`, `.canon/review/`, and `.canon/memory/` at the main worktree root, never against the linked worktree this session builds in. Those folders are gitignored, so `git worktree add` never creates them and the copy beside the build is absent rather than empty.
 - Report a plan that fails to resolve as unreadable from here, naming the main-root path. Reporting the task as having no plan is true where this session stands and wrong about the world, and a reader with no second tree to check cannot separate the two.
 - Build the plan the launch named. Do not write a second one when the path fails to resolve, since a row that cites a plan already has one and drafting another produces two plans for one row.
 
 ## The board is read-only
 
-- Never write `.claude/tasks/priority.md` or `.claude/tasks/backlog.md`. The controlling session is their only writer apart from `canon tasks archive`, and both are gitignored, so an overwrite drops a row with no history to recover it from.
+- Never write `.canon/tasks/priority.md` or `.canon/tasks/backlog.md`. The controlling session is their only writer apart from `canon tasks archive`, and both are gitignored, so an overwrite drops a row with no history to recover it from.
 - Report a row this build turns up rather than adding it. Picking a free label means reading every task file and every archive entry, which this session has not done, so a label it invents collides with one already taken.
 - Write the task file this build closes and the plan it ran under. The ban covers the shared board rather than the artifacts of the row in hand.
 

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

@@ -13,7 +13,7 @@ Wrap the `EnterWorktree` entry path with name derivation so the user does not pi
 - If neither command resolves, the session is not in a git repo and no `WorktreeCreate` hook is configured. Stop: `❌ Not a git repository. EnterWorktree needs git or a WorktreeCreate hook.`
 - If the two match and `git rev-parse --show-superproject-working-tree` prints a path, the session is inside a submodule checkout. Stop: `❌ Inside a submodule of <path>. Run this from there instead.`
 
-The submodule guard sits on the matching branch rather than ahead of the first one, and a measurement decided that. Inside a submodule at git 2.43.0 both reads return the same absorbed path under the superproject's `.git/modules/`, so the first guard does not fire and the session proceeds. Every derivation below then reads the submodule as the project: Step 1 resolves the main root to the submodule, the plan lookup reads a `.claude/plans/` the project never wrote, and entry builds `.claude/worktrees/` inside a tree the superproject tracks as a commit. The superproject read is empty in a linked worktree of a submodule and in one of the superproject alike, which is why it separates the two states rather than qualifying the first guard.
+The submodule guard sits on the matching branch rather than ahead of the first one, and a measurement decided that. Inside a submodule at git 2.43.0 both reads return the same absorbed path under the superproject's `.git/modules/`, so the first guard does not fire and the session proceeds. Every derivation below then reads the submodule as the project: Step 1 resolves the main root to the submodule, the plan lookup reads a `.canon/plans/` the project never wrote, and entry builds `.claude/worktrees/` inside a tree the superproject tracks as a commit. The superproject read is empty in a linked worktree of a submodule and in one of the superproject alike, which is why it separates the two states rather than qualifying the first guard.
 
 ## Step 1: resolve the main worktree root
 
@@ -38,8 +38,8 @@ The directory test separates the defect from a genuinely bare repository, which
 Try each source in order. Stop at the first match.
 
 0. **Caller-supplied.** The invocation carried an argument. Take it as the name and infer nothing further. Accept `<name>` or `<type>/<name>`, where a leading segment matching a type in `${CLAUDE_SKILL_DIR}/../../standards/branch.md` sets `<type>` and the rest is `<name>`. A bare `<name>` falls to the default type below.
-1. **Plan matched to current branch.** Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. An empty result falls through to the next source here rather than becoming `latest`, since the slug is one candidate among several. If `<main-root>/.claude/plans/feature-<slug>.md` exists, use `<slug>`.
-2. **Single plan file.** List `<main-root>/.claude/plans/feature-*.md`. If exactly one match, derive `<slug>` from the filename.
+1. **Plan matched to current branch.** Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. An empty result falls through to the next source here rather than becoming `latest`, since the slug is one candidate among several. If `<main-root>/.canon/plans/feature-<slug>.md` exists, use `<slug>`.
+2. **Single plan file.** List `<main-root>/.canon/plans/feature-*.md`. If exactly one match, derive `<slug>` from the filename.
 3. **Multiple plan files, no branch match.** Ask the user which plan. Show the candidate slugs as a numbered list. Do not pick.
 4. **Current branch.** When no plan exists, use the `<slug>` from step 1 if it is not `main` or `master`.
    4b. **Session context.** When on `main` or `master` with no matching plan, read the current conversation to infer a kebab slug from the topic being discussed. Propose it: `Infer: <slug>. Confirm or rename?` Do not enter the worktree until the user confirms or provides a corrected name.

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

@@ -48,12 +48,12 @@ The `pull_request` check the git-pr surface carries reads a pull request's own t
 Map a bug to `--label bug` and a task to `--label enhancement`.
 
 ```bash
-mkdir -p .claude/.tmp/issue
-cat <<'BODY' > .claude/.tmp/issue/body.md
+mkdir -p .canon/tmp/issue
+cat <<'BODY' > .canon/tmp/issue/body.md
 <body following the issue.md sections>
 BODY
-gh issue create --title "<type>: <subject>" --label <bug or enhancement> --body-file .claude/.tmp/issue/body.md
-rm -rf .claude/.tmp/issue
+gh issue create --title "<type>: <subject>" --label <bug or enhancement> --body-file .canon/tmp/issue/body.md
+rm -rf .canon/tmp/issue
 ```
 
 ## After execution

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

@@ -111,8 +111,8 @@ Detect an open pull request on the current head and branch: edit it in place whe
 Labels apply after that branch converges, against a pull request that already exists. `gh pr create --label` refuses a label the remote does not carry and opens no pull request at all, so a mistyped row costs the run rather than the label. One command after the fact also covers the create and the edit path together.
 
 ```bash
-mkdir -p .claude/.tmp/pr
-cat <<'BODY' > .claude/.tmp/pr/body.md
+mkdir -p .canon/tmp/pr
+cat <<'BODY' > .canon/tmp/pr/body.md
 <body content following pr.md template exactly>
 BODY
 pr_labels="<comma-separated labels, empty when the map resolves to nothing>"
@@ -120,16 +120,16 @@ git push -u origin HEAD || exit 1
 base_branch=$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name) || exit 1
 pr_number=$(gh pr list --head "$(git branch --show-current)" --base "$base_branch" --state open --json number --jq '.[0].number // empty')
 if [ -n "$pr_number" ]; then
-  pr_url=$(gh pr edit "$pr_number" --title "<title>" --body-file .claude/.tmp/pr/body.md) || exit 1
+  pr_url=$(gh pr edit "$pr_number" --title "<title>" --body-file .canon/tmp/pr/body.md) || exit 1
 else
-  pr_url=$(gh pr create --title "<title>" --body-file .claude/.tmp/pr/body.md) || exit 1
+  pr_url=$(gh pr create --title "<title>" --body-file .canon/tmp/pr/body.md) || exit 1
   pr_number=${pr_url##*/}
 fi
 if [ -n "$pr_labels" ]; then
   gh pr edit "$pr_number" --add-label "$pr_labels" >/dev/null ||
     printf 'Label apply failed. Create a missing label with: gh label create <name>\n' >&2
 fi
-rm -rf .claude/.tmp/pr
+rm -rf .canon/tmp/pr
 printf 'number=%s\nurl=%s\n' "$pr_number" "$pr_url"
 ```
 
@@ -137,7 +137,7 @@ printf 'number=%s\nurl=%s\n' "$pr_number" "$pr_url"
 
 Write the `number` the final command printed onto the task the branch is closing. Do not resolve it again. A head branch that carried an earlier pull request now has two, and a second `gh pr view` would pick between them by a precedence rule nothing here states. Reading what created or edited the pull request needs no such rule.
 
-The task is the one whose `Plan:` line names the plan this branch implemented. Name that plan by its file, which is `.claude/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`. `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.
 
 ```bash
 canon tasks pull-request <number> --plan feature-<slug> --json