@erclx/canon 5.54.0 → 5.56.0

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

@@ -74,10 +74,17 @@ Classify the groups before generating commands, since the mode decides each bran
 
 Append the line for the run's mode to the preview.
 
-| Mode        | Line                                                                                                                                                                                                          |
-| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Stacked     | `🔁 Sequential squash-merge loop. Squash-merge each PR bottom-up with --delete-branch. After each merge, signal me so I can restack the next branch onto main before you merge it.`                           |
-| Independent | `🔁 Squash-merge secondaries first, primary last. The primary keeps every cherry-picked commit, so merging it first lands every secondary's content on main and leaves the secondary PRs empty after rebase.` |
+Stacked mode appends this line:
+
+```plaintext
+🔁 Sequential squash-merge loop. Squash-merge each PR bottom-up with --delete-branch. After each merge, signal me so I can restack the next branch onto main before you merge it.
+```
+
+Independent mode appends this line:
+
+```plaintext
+🔁 Squash-merge secondaries first, primary last. The primary keeps every cherry-picked commit, so merging it first lands every secondary's content on main and leaves the secondary PRs empty after rebase.
+```
 
 After outputting the preview, execute the final commands immediately. Claude Code's tool permission dialog is the confirmation gate. Do not wait for user input.
 

package/claude/skills/markdown-craft/SKILL.md

@@ -14,7 +14,7 @@ Read the references below before a substantial markdown edit. Every rule in them
 
 Run `canon markdown audit <path>` after the edit, and fix every ban and density finding it reports before moving on. Rewrite the sentence carrying a ban hit rather than swapping the token for a near-synonym, and fix a density finding by its shape rather than trimming characters.
 
-A table finding reports without failing the run. Fix it the way `tables.md` gives for its limit.
+A table cell past its cap and a list after a table gate where density does, and the row count and the wide token report without failing the run. Fix each the way `tables.md` gives for its limit.
 
 ## Routes
 

package/claude/skills/markdown-craft/references/markdown.md

@@ -77,7 +77,7 @@ A bold section marker holding its line alone breaks a run the way a heading does
 
 ## Density
 
-Six limits keep a file scannable on sight, each a fact `canon markdown audit` measures that fails the push where the surface's gate is on. A table takes four more, in `tables.md` beside this file. Open an H3 with a lead sentence or a table, then a few bullets or a short paragraph, since monotone text is the defect whether all prose or all bullets.
+Six limits keep a file scannable on sight, each a fact `canon markdown audit` measures that fails the push where the surface's gate is on. A table takes four more in `tables.md`, two of them gating. Open an H3 with a lead sentence or a table, then a few bullets or a short paragraph, since monotone text is the defect.
 
 | Rule                | Limit                                             |
 | ------------------- | ------------------------------------------------- |
@@ -95,7 +95,7 @@ Rules, a requirements or design record, a changelog, examples, and `.canon/` rec
 A paragraph is read straight through and a bullet is scanned, so the paragraph limit sits above the bullet one. Four sentences to a paragraph stays advice rather than a limit.
 
 - A paragraph's length folds in the lines that wrap it. A paragraph inside a list item counts toward its bullet, never as a paragraph or toward a run.
-- A bullet's length counts its continuation lines and excludes any bullet nested under it
+- A bullet's length counts its continuation lines and excludes any bullet nested under it, and a nested bullet is measured on its own
 - A heading, list, table, fence, or bold section marker ends a run of paragraphs
 - A blank line, a continuation, and a nested item do not break a run of bullets, and a paragraph or a heading does
 - A run whose every item opens with a bold label or a link is exempt from the run limit, since each item names its own subject. A task box is not a link, so a checklist counts as plain.

package/claude/skills/markdown-craft/references/tables.md

@@ -5,18 +5,20 @@ description: The four limits a markdown table takes, being cell length, row coun
 
 # Table limits
 
-None of the density limits in `markdown.md` reads inside a table, so content too long for a bullet tends to move into a cell. Four table limits close that gap. `canon markdown audit` measures them on the paths density covers, outside fences, and reports each one without failing a push for now.
+None of the density limits in `markdown.md` reads inside a table, so content too long for a bullet tends to move into a cell. Four table limits close that gap. `canon markdown audit` measures them on the paths density covers, outside fences.
+
+Cell length and a list after a table fail a push where density gates. Rows and a wide token report without failing one.
 
 ## Limits
 
 Each limit is a count or a shape a scan settles, read the way a renderer draws the table. An escaped pipe stays inside its cell, and pipe lines with no delimiter row are not a table.
 
-| Rule             | Limit                                                 |
-| ---------------- | ----------------------------------------------------- |
-| Cell length      | 120 visible characters, counting a link by its label  |
-| Rows             | 8 body rows, not counting the header                  |
-| List after table | A list is never the next block after a table          |
-| Wide token       | No code span in a cell holds a run past 30 characters |
+| Rule             | Limit                                                 | Effect       |
+| ---------------- | ----------------------------------------------------- | ------------ |
+| Cell length      | 120 visible characters, counting a link by its label  | Gates        |
+| Rows             | 8 body rows, not counting the header                  | Reports only |
+| List after table | A list is never the next block after a table          | Gates        |
+| Wide token       | No code span in a cell holds a run past 30 characters | Reports only |
 
 A paragraph or a heading between a table and a list clears the third limit, and a blank line alone does not.
 

package/claude/skills/plan-feature/SKILL.md

@@ -163,6 +163,8 @@ Pick the `Next:` line from the roster check `${CLAUDE_SKILL_DIR}/../task-board/S
 | **Not found**, and this session's name starts with `worker-` or `planner-` | `Hand <task> to a worker`, naming no session, since none is live and the operator dispatches by hand |
 | **Not found otherwise**, or the read fails                                 | `/session-worktree`                                                                                  |
 
+Three rules apply to the `Next:` choice:
+
 - With a live orchestrator and no planner role held, send the plan path to it through `canon:session-relay`, resolved from its `sessionId`
 - A session holding `canon:role-planner` already owes that announcement through its own channel, so it sends none
 - Say which row fired in one clause, since a line with no stated reason is one the next reader re-derives.

package/claude/skills/plan-feature/references/plan.md

@@ -81,6 +81,8 @@ The document opens with `# Feature: <short title>` and one paragraph stating wha
 | `## Questions`         | numbered open decisions, each with a suggestion and an answer slot          | Always                                            |
 | `## Sources`           | the outside sources a decision rests on, each with its quoted passage       | When a decision rests on an outside source        |
 
+Four rules govern how a section is written:
+
 - Write each section as the H2 the table gives, so a reader scans the plan by its outline
 - A section written as a bold label, the spelling before this one, is still that section to every parser. Leave an existing plan's spelling alone.
 - Write `None identified.` under a required section with nothing to report rather than dropping the marker. A dropped section and an unconsidered one read identically.

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

@@ -90,13 +90,15 @@ Once the fixes are commits, re-run step 5's staleness test against the new head.
 
 Write a summary reply to `.canon/tmp/pr/reply/reply-<number>.md`, keyed on the PR number so two sessions addressing different pull requests never overwrite each other. Load `write-human` for voice, follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`, and keep each mapping to one line.
 
-| Part     | Content                                                                                                                                        |
-| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| Heading  | `## Review response`, distinct from human threads and subordinate to the review's own `## Review`                                              |
-| Summary  | One sentence. After a step 5 rebase, say so and name files resolved by hand and those the regen rebuilt, since the next review is a full pass. |
-| Findings | One line per finding under 200 characters, naming its outcome and the commit that carries it, in the shape below                               |
-| Docs     | Any `.claude/` docs refreshed as a result of the fixes                                                                                         |
-| Close    | `🤖 Addressed by Claude Code` on its own line, so the reply reads as a machine pass rather than a human sign-off                               |
+| Part     | Content                                                                                                          |
+| -------- | ---------------------------------------------------------------------------------------------------------------- |
+| Heading  | `## Review response`, distinct from human threads and subordinate to the review's own `## Review`                |
+| Summary  | One sentence, plus the rebase note below                                                                         |
+| Findings | One line per finding under 200 characters, naming its outcome and the commit that carries it, in the shape below |
+| Docs     | Any `.claude/` docs refreshed as a result of the fixes                                                           |
+| Close    | `🤖 Addressed by Claude Code` on its own line, so the reply reads as a machine pass rather than a human sign-off |
+
+After a step 5 rebase, the summary says so and names the files resolved by hand and those the regen rebuilt, since the next review is a full pass.
 
 ```markdown
 - **<severity>**, `<file>` line <n>: fixed in `<sha>`. <What now holds, in one sentence.>

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

@@ -87,15 +87,13 @@ Three scope checks follow the walk:
 
 ## Excuses and rebuttals
 
-| Excuse                                                      | Rebuttal                                                                                                                        |
-| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
-| The tests pass, so the change works                         | Read what the diff did to the tests first. A test skipped, deleted, or stripped of its assertions passes by proving nothing.    |
-| The hunk reads clean, so the review is done                 | The hunk is where the author looked. A consumer, a doc a section away, and the commit that added a removed guard are not in it. |
-| The checker passes on the branch                            | Read the checker's config and the inline suppressions in the diff. A path excluded from the run passes by not being read.       |
-| It was split into smaller functions, so it is simpler       | Count the concepts a reader holds before and after. Moved complexity reads as simpler only to the person who moved it.          |
-| Nothing calls it, so deleting it is safe                    | Read why it was added. Code nobody calls today can still be guarding a path nobody exercised in the change.                     |
-| The description says it is faster                           | A claimed speedup with no measurement, or one run each side, is asserted. Ask for runs that beat the noise.                     |
-| The change only touches styles, so the screenshots can wait | A stylesheet diff says what changed and only the image says what a user sees. Open them, or say none exist.                     |
+- **The tests pass, so the change works.** Read what the diff did to the tests first. A test skipped, deleted, or stripped of its assertions passes by proving nothing.
+- **The hunk reads clean, so the review is done.** The hunk is where the author looked. A consumer, a doc a section away, and the commit that added a removed guard are not in it.
+- **The checker passes on the branch.** Read the checker's config and the inline suppressions in the diff. A path excluded from the run passes by not being read.
+- **It was split into smaller functions, so it is simpler.** Count the concepts a reader holds before and after. Moved complexity reads as simpler only to the person who moved it.
+- **Nothing calls it, so deleting it is safe.** Read why it was added. Code nobody calls today can still be guarding a path nobody exercised in the change.
+- **The description says it is faster.** A claimed speedup with no measurement, or one run each side, is asserted. Ask for runs that beat the noise.
+- **The change only touches styles, so the screenshots can wait.** A stylesheet diff says what changed and only the image says what a user sees. Open them, or say none exist.
 
 ## Red flags
 

package/claude/skills/review-craft/references/adopted.md

@@ -13,14 +13,16 @@ The `addyosmani/agent-skills` citations below all pin commit `addyosmani/agent-s
 
 ### Design and scope
 
-**The design procedure.** The nine ordered steps under the design axis draw on four sources, each restated without a language, a framework, or a transport so the walk holds on any stack.
+**The design procedure.** The nine ordered steps under the design axis draw on four sources, each restated without a language, a framework, or a transport so the walk holds on any stack. Each source below carries the step it backs.
 
-| Source                                                                                                                                                                               | Step it backs                                                                               |
-| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
-| Ousterhout's deep modules, information hiding, and pass-through methods, [A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php)                        | Asking what each unit hides, and flagging a unit that passes its arguments straight through |
-| Parnas's criterion that a boundary hides a decision likely to change, [On the Criteria To Be Used in Decomposing Systems into Modules](https://dl.acm.org/doi/10.1145/361598.361623) | The opening step, naming the next likely change and counting what it touches                |
-| Beck's design rules as Fowler records them, especially no duplication and fewest elements, [BeckDesignRules](https://martinfowler.com/bliki/BeckDesignRules.html)                    | The one-place step, and matching each pattern to a problem the code has today               |
-| Google's reviewer guide on design, complexity, and over-engineering, [What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)    | The frame for the whole walk, and the reason a speculative abstraction is a finding         |
+- Ousterhout's deep modules, information hiding, and pass-through methods, [A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php)
+  - Backs asking what each unit hides, and flagging a unit that passes its arguments straight through
+- Parnas's criterion that a boundary hides a decision likely to change, [On the Criteria To Be Used in Decomposing Systems into Modules](https://dl.acm.org/doi/10.1145/361598.361623)
+  - Backs the opening step, naming the next likely change and counting what it touches
+- Beck's design rules as Fowler records them, especially no duplication and fewest elements, [BeckDesignRules](https://martinfowler.com/bliki/BeckDesignRules.html)
+  - Backs the one-place step, and matching each pattern to a problem the code has today
+- Google's reviewer guide on design, complexity, and over-engineering, [What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)
+  - Backs the frame for the whole walk, and the reason a speculative abstraction is a finding
 
 The procedure stays in the body rather than a reference, since every review reads the design axis and a reference would cost a read on every run.
 
@@ -55,7 +57,7 @@ From `skills/security-and-hardening/SKILL.md`, the threat model first and the de
 
 ### Closing sections
 
-The excuses, red flags, and closing checklist follow the shape every practice skill in this toolkit carries, from [`docs/skill-anatomy.md`](https://github.com/addyosmani/agent-skills/blob/2686b620fc1fed2e8f60c704839c766b8594c6b6/docs/skill-anatomy.md). Each excuse row rebuts a reason a review stops at the hunk, such as passing tests against a test the diff skipped.
+The excuses, red flags, and closing checklist follow the shape every practice skill in this toolkit carries, from [`docs/skill-anatomy.md`](https://github.com/addyosmani/agent-skills/blob/2686b620fc1fed2e8f60c704839c766b8594c6b6/docs/skill-anatomy.md). Each excuse rebuts a reason a review stops at the hunk, such as passing tests against a test the diff skipped.
 
 ## Declined
 

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

@@ -33,6 +33,8 @@ Both headings anchor as a section distinct from human threads. The full set is e
 | Evidence | `## Evidence`                                                | `canon pr evidence`, through `pr-evidence` from `git-pr` and `git-followup` |
 | UI       | `## UI review`, `## UI review closed`                        | `review-ui`, posted as a review beside this one and read by nothing here    |
 
+Three notes qualify the table.
+
 - The reply headings in order answer a finding, report a stale branch resolved without one, and carry a finding a worker produced after a close-out
 - `## Evidence` answers no comment on the thread, so the poll leaves it out of the unclassified count rather than reading it as a reply owing a re-review
 - A comment under any other heading reaches the poll as unclassified rather than as silence, so an invented ninth heading is a gap the next run reports

package/claude/skills/review-pr/references/key-changes.md

@@ -13,12 +13,14 @@ Test what `## Key changes` claims against the diff it describes, with `canon pr
 
 Branch on the record rather than on the exit code, which a shell function wrapping `canon` can flatten to zero. Each field the record carries takes its own reading.
 
-| Field        | Reading                                                                                                                             |
-| ------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
-| `unmet`      | a `should-fix` finding under the `**PR body**` block the stale box takes, one per path, quoting the `preview` bullet and the `head` |
-| `unnamed`    | read for yourself and raise nothing off the count                                                                                   |
-| `unresolved` | reported nowhere, since it was judged in neither direction                                                                          |
-| `incidental` | reported nowhere, since it owes no bullet                                                                                           |
+| Field        | Reading                                                                                |
+| ------------ | -------------------------------------------------------------------------------------- |
+| `unmet`      | a `should-fix` finding under the `**PR body**` block the stale box takes, one per path |
+| `unnamed`    | read for yourself and raise nothing off the count                                      |
+| `unresolved` | reported nowhere, since it was judged in neither direction                             |
+| `incidental` | reported nowhere, since it owes no bullet                                              |
+
+Each `unmet` finding quotes the `preview` bullet and the `head`.
 
 ### Before filing an unmet path
 

package/claude/skills/review-ui/references/driving.md

@@ -45,14 +45,16 @@ A taste box takes the shot twice, once per theme, naming the theme in the file a
 
 ## The four verdicts
 
-Each box takes exactly one.
-
-| Verdict             | When                                                    | Evidence it carries                                                                                                                                                    |
-| ------------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| pass or fail, read  | The result is a fact the page reports                   | The value read, quoted, such as `scrollWidth 436 against clientWidth 320`                                                                                              |
-| pass or fail, frame | The result has a stated criterion only an image settles | The matching evidence stem or the pushed frame's link, inline under the failed box's heading, and what the frame shows, in words                                       |
-| needs eyes          | The box ends in `(taste)`                               | The dark and the light shot as a pair, each the matching evidence stem or a pushed frame's link, and what the frames showed, with nothing about whether it looks right |
-| not driven          | The state could not be reached                          | The reason, such as an unreachable address, a `(local only)` box on a hosted preview, or a target the snapshot does not hold                                           |
+Each box takes exactly one, keyed here by the state it answers.
+
+- **pass or fail, read.** The result is a fact the page reports.
+  - The evidence is the value read, quoted, such as `scrollWidth 436 against clientWidth 320`.
+- **pass or fail, frame.** The result has a stated criterion only an image settles.
+  - The evidence is the matching evidence stem or the pushed frame's link, inline under the failed box's heading, and what the frame shows, in words.
+- **needs eyes.** The box ends in `(taste)`.
+  - The evidence is the dark and the light shot as a pair, each the matching evidence stem or a pushed frame's link, and what the frames showed, with nothing about whether it looks right.
+- **not driven.** The state could not be reached.
+  - The evidence is the reason, such as an unreachable address, a `(local only)` box on a hosted preview, or a target the snapshot does not hold.
 
 A fail names what was expected beside what was read. A not driven never reads as a fail, since it says the pass could not look rather than that the page is wrong. Its reason says whether the cause sits on the page or off it, since only a cause on the page opens the heading Step 7 picks.
 

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

@@ -9,10 +9,12 @@ Re-test every parked row as orchestrator. A blocker cell is a measurement taken
 
 Two triggers start this pass, and they differ in scope rather than in procedure.
 
-| Trigger                                                                                           | Scope                                                                                                                                |
-| ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| `orchestrator-sweep.md` sends the rows `canon tasks validate` listed untested                     | Those rows alone, since a merge changes the tree under every parked row and the validator already re-took the two kinds it settles   |
-| An idle session, with nothing merged, workers building, and no pull request awaiting a first pass | Every parked row, since no event narrowed them, plus every `backlog.md` row, which carries no blocker cell for the validator to name |
+- **Sweep.** `orchestrator-sweep.md` sends the rows `canon tasks validate` listed untested.
+  - Scope: those rows alone, since a merge changes the tree under every parked row and the validator already re-took the two kinds it settles
+- **Idle.** The session has nothing merged, workers building, and no pull request awaiting a first pass.
+  - Scope: every parked row, since no event narrowed them, plus every `backlog.md` row, which carries no blocker cell for the validator to name
+
+Three points hold for both triggers.
 
 - Neither trigger is a scheduler. `orchestrator-poll.md` owns the one recurring trigger, and a second loop firing into a static board is the always-on failure it warns about.
 - The sweep asks which parked row to promote next, taking the blocker cell as read, and this pass asks whether the cell is still true

package/claude/skills/role-orchestrator/references/orchestrator-refill.md

@@ -25,10 +25,14 @@ The third trigger reaches a window the first two cannot. A session with three wo
    - Run `task-complete` to archive one the hook left in place
    - A task whose outcomes are standing policy never closes, so hand it to a worker to encode the policy where it is enforced, then cut the outcomes with the reason and archive once that branch merges
    - Encoding it from this session would write a tracked file, which `## Boundaries` in the skill body forbids
-   - An outcome marked `- [ ] Operator check: <outcome>` never blocks the archive. The hook prints no record, so read the archived file's `Operator check:` lines into the report's `Operator checks:` line and leave them unticked.
-   - A merged task whose only open outcomes another repository owes, or that an operator owns and nobody marked, never archives, since `canon tasks archive` refuses `open-outcomes`. Strike each one on the task file as `- ~~<outcome>~~ <reason>`, with the reason on the same line, then archive. The task files are gitignored scratch, so this session may edit them.
+   - An outcome marked `- [ ] Operator check: <outcome>` never blocks the archive, so leave it unticked
+   - The hook prints no record, so read the archived file's `Operator check:` lines into the report's `Operator checks:` line
+   - A merged task whose only open outcomes another repository owes, or that an operator owns and nobody marked, never archives, since `canon tasks archive` refuses `open-outcomes`
+   - Strike each one on the task file as `- ~~<outcome>~~ <reason>` with the reason on the same line, then archive. The task files are gitignored scratch, so this session may edit them.
    - Strike only an outcome the operator or another repository owes. An open outcome this repository owes stays on the board, and the task stays with it.
-   - Send a struck outcome that another repository owes to that repository's orchestrator through `session-relay`, which resolves the address, and let the receiver file it with `task-board` on its own board. `task-board` here would file it on this board. Name it in the report for the operator when no such session is live.
+   - Send a struck outcome that another repository owes to that repository's orchestrator through `session-relay`, which resolves the address
+   - Let the receiver file it with `task-board` on its own board, since `task-board` here would file it on this board
+   - Name it in the report for the operator when no such session is live
    - List every struck outcome in the report's `Struck:` line, so the work is carried by a named owner rather than lost to the strike
 4. Read `.canon/tasks/priority.md` and count the `## Up next` rows whose `Waiting on` has cleared, since a blocked row is no reserve. `## Run now` is what is running, so keep one in reserve beyond it.
 5. Promote from the top of `## Needs a plan`, where the last sweep recorded what to plan next.
@@ -69,6 +73,8 @@ Write `.canon/tasks/priority.md` through the `canon tasks` verbs alone, each rea
 | A row up or down inside its group         | `canon tasks move <stem> --before <stem>`                  |
 | What a row waits on, or why it sits there | `canon tasks block <stem> "<reason>"`                      |
 
+The points below govern writing the board through those verbs.
+
 - `place` removes the task's backlog line in the same call, so a row never sits on both surfaces or on neither
 - Demoting a row to `backlog.md` has no verb yet. Add the backlog line first, then delete the row with the file-editing tool, which errors on a non-match.
 - Put the reason a row sits where it does in its Waiting on cell through `block`, since a row promoted with the cell left alone carries an order the next sweep cannot check

package/claude/skills/role-reviewer/SKILL.md

@@ -19,11 +19,11 @@ This body states the role, the reads, the boundaries, and the channel, and start
 
 The session writes its comment and nothing tracked. Each kind of reviewer writes only these:
 
-| Reviewer | May write                                                                                                                                                      |
-| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Code     | The comment through `review-pr` and the body file it names under `.canon/tmp/pr/review/`                                                                       |
-| UI       | The comment `review-ui` posts, its body file, and the browser's snapshots and frames under `.canon/tmp/pr/review-ui/`, plus `canon pr tick` on boxes it passed |
-| Either   | The draft flag, through `canon pr lift` and no other way                                                                                                       |
+- **Code:** the comment through `review-pr` and the body file it names under `.canon/tmp/pr/review/`
+- **UI:** the comment `review-ui` posts, its body file, and the browser's snapshots and frames under `.canon/tmp/pr/review-ui/`, plus `canon pr tick` on boxes it passed
+- **Either:** the draft flag, through `canon pr lift` and no other way
+
+The rules below close off everything else.
 
 - A tracked file, a branch, a worktree, a board file, and a commit all sit outside what this session may touch
 - Never enter a worktree or check the branch out. The pass reads a change, and a checkout is the first step toward editing it.

package/claude/skills/search-craft/SKILL.md

@@ -54,13 +54,11 @@ Read `${CLAUDE_SKILL_DIR}/references/adopted.md` only when extending this guidan
 
 ## Excuses and rebuttals
 
-| Excuse                                   | Rebuttal                                                                                                                                    |
-| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
-| The model already knows the good sites   | It does, and it does not use that knowledge unprompted. Left to rank, a search puts guides written to rank above a field's reference pages. |
-| One search was enough                    | One search gives nothing to check a wrong fact against. The scoped search is what catches the open summary's error.                         |
-| The open results look authoritative      | Ranking rewards pages written to rank, so advocates and thin guides sit beside the field's own record and tilt the summary.                 |
-| I scoped it, so every result is in scope | The domain filter is not strict, so a scoped search can return results from outside its list.                                               |
-| The summary already answers it           | A summary paraphrases. Fetch the page when two summaries disagree, since that is where the error sits.                                      |
+- **The model already knows the good sites.** It does, and it does not use that knowledge unprompted. Left to rank, a search puts guides written to rank above a field's reference pages.
+- **One search was enough.** One search gives nothing to check a wrong fact against. The scoped search is what catches the open summary's error.
+- **The open results look authoritative.** Ranking rewards pages written to rank, so advocates and thin guides sit beside the field's own record and tilt the summary.
+- **I scoped it, so every result is in scope.** The domain filter is not strict, so a scoped search can return results from outside its list.
+- **The summary already answers it.** A summary paraphrases. Fetch the page when two summaries disagree, since that is where the error sits.
 
 ## Red flags
 

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

@@ -73,6 +73,8 @@ Resolve `<type>` here too, since Step 3 previews it and Step 5 renames onto it,
 | A plan, through tier 1 or tier 2             | The `type` field of `canon tasks plan-branch <plan> --json` |
 | A branch, a bare user name, or anything else | `feat`                                                      |
 
+The points below govern how the type is read.
+
 - The verb is the reading because a type read off a plan's sections is a judgment two sessions can grade differently, and the verb answers the same for both
 - Branch on the record rather than on the exit code, which a shell function wrapping `canon` can flatten to zero
 - Take `feat` and say the verb did not answer where it refuses, the record has no `type`, or the binary has no `plan-branch`

package/claude/skills/session-worktree/references/main-root-writes.md

@@ -22,6 +22,8 @@ Each kind of write takes one route, and none of them is a stream editor.
 | Change inside a file | A `canon` verb resolving the main root in-process, such as `canon tasks outcome` or `canon tasks pull-request` |
 | Delete or move       | One plain `rm` or `mv` per call rather than chained                                                            |
 
+Three habits keep those routes from being refused or silently wrong.
+
 - Send `mkdir -p` for a missing folder as its own command first, since a `&&` compound is refused for complexity
 - Where no verb covers an edit, read the whole file and write it back whole through the heredoc route
 - Never reach for a stream editor, which rewrites the line it anchored to and exits zero on a non-match

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

@@ -23,7 +23,9 @@ No fixes without root-cause investigation first. If phase 1 is incomplete, no fi
    - State. Run the case alone and again after the others, and look for shared caches, globals, and fixtures one case leaks into the next.
    - None of these. Add logging at the suspect and record the conditions of each occurrence, which hands off to the no-root-cause section below rather than to a fix.
 3. Check what changed. Run `git diff` and `git log --oneline -10` from the project root to see recent changes.
-   - For a regression with a known good commit, bisect rather than reading the log by eye: `git bisect start HEAD <good commit>`, then `git bisect run <the project's focused test command>` where a test reproduces the failure. Run `git bisect reset` once it names the commit, since bisect leaves the checkout on an old one.
+   - For a regression with a known good commit, bisect rather than reading the log by eye, with `git bisect start HEAD <good commit>`
+   - Where a test reproduces the failure, run `git bisect run <the project's focused test command>`
+   - Run `git bisect reset` once it names the commit, since bisect leaves the checkout on an old one
 4. For multi-component systems, add instrumentation at each component boundary and run once to see which layer fails before investigating further.
 5. Trace bad values backward to their source. Fix at the origin, not the symptom.
 
@@ -69,14 +71,12 @@ Most "no root cause" conclusions are incomplete investigations. Exhaust phase 1
 
 ## Excuses and rebuttals
 
-| Excuse                                        | Rebuttal                                                                                                                                    |
-| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
-| "I know what the bug is, so I'll just fix it" | Then reproducing it costs a minute. When the reading is wrong, the fix moves the symptom and reports success over a cause still in place.   |
-| "Quick fix for now, investigate later"        | Later never reads the code again. The quick fix becomes the record of what the bug was, and it names the wrong place.                       |
-| "It's probably flaky, rerun it"               | A rerun that passes says the failure is intermittent, not that it is gone. Take the timing, environment, or state branch in phase 1.        |
-| "It works on my machine"                      | That is the environment branch's first data point. Diff versions, config, and data against where it fails rather than closing on it.        |
-| "The error says to run this, so I'll run it"  | The error is data about the failure. Whatever wrote it is the thing that is broken, so surface the step to the user rather than running it. |
-| "I'll verify manually instead of a test"      | A manual check leaves nothing behind. The failing test is what shows the fix reached the cause, and what catches the bug's return.          |
+- **"I know what the bug is, so I'll just fix it."** Then reproducing it costs a minute. When the reading is wrong, the fix moves the symptom and reports success over a cause still in place.
+- **"Quick fix for now, investigate later."** Later never reads the code again. The quick fix becomes the record of what the bug was, and it names the wrong place.
+- **"It's probably flaky, rerun it."** A rerun that passes says the failure is intermittent, not that it is gone. Take the timing, environment, or state branch in phase 1.
+- **"It works on my machine."** That is the environment branch's first data point. Diff versions, config, and data against where it fails rather than closing on it.
+- **"The error says to run this, so I'll run it."** The error is data about the failure. Whatever wrote it is the thing that is broken, so surface the step to the user rather than running it.
+- **"I'll verify manually instead of a test."** A manual check leaves nothing behind. The failing test is what shows the fix reached the cause, and what catches the bug's return.
 
 ## Red flags
 

package/claude/skills/systematic-debugging/references/adopted.md

@@ -20,7 +20,7 @@ External sources were read and filtered rather than imported. This file is the r
 
 The excuses, red flags, and closing checklist follow the shape every practice skill in this toolkit carries, from `addyosmani/agent-skills@2686b620`, [`docs/skill-anatomy.md`](https://github.com/addyosmani/agent-skills/blob/2686b620fc1fed2e8f60c704839c766b8594c6b6/docs/skill-anatomy.md).
 
-Each excuse row rebuts a reason a session gives to skip the investigation rather than an objection nobody raised. Three come from the source's own rationalizations table and the rest from this skill's earlier red flags.
+Each excuse rebuts a reason a session gives to skip the investigation rather than an objection nobody raised. Three come from the source's own rationalizations table and the rest from this skill's earlier red flags.
 
 ### Default shelf
 

package/claude/skills/target-check/SKILL.md

@@ -17,7 +17,7 @@ Six domains carry the report. Five answer from a verb that already exists and th
 - No `.claude/` directory at the working root: stop. `❌ No .claude/ here, so nothing is installed to check. Run canon init first.`
 - A `claude/skills/` folder at the root, no leading dot: stop. `❌ This is the toolkit itself rather than a target. Ask the orchestrator for a worker per repository to take a change out to the targets.`
   - A target receives skills at `.claude/skills/` and authors none, so the spelling without the dot separates the source from what it installs into
-- Run every command under `CANON_NON_INTERACTIVE=1` and prompt at no point, since every caller is a dispatched worker with nobody to answer
+- Prompt at no point, since every caller is a dispatched worker with nobody to answer. A call with no terminal on stdin already runs headless, so no command takes a prefix.
 - Branch on each record's own fields rather than on an exit status. A shell function wrapping `canon` can report every refusal as success.
 
 ## Step 1: read the reports
@@ -25,25 +25,23 @@ Six domains carry the report. Five answer from a verb that already exists and th
 Run these from the target root, in parallel:
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon sync --check . --json
-CANON_NON_INTERACTIVE=1 canon context audit --json
+canon sync --check . --json
+canon context audit --json
 ```
 
 The first answers five domains from one read, being `skew`, `domains`, `seeds`, `tooling`, and the layout fields `unmigrated`, `superseded`, `unmovedSurfaces`, and `reverse`. The second deepens a domain that first read only counts.
 
-Then run `CANON_NON_INTERACTIVE=1 canon records validate <kind> --json` once per record folder the target carries, taking `<kind>` from what is present under the record root rather than from a list held here.
+Then run `canon records validate <kind> --json` once per record folder the target carries, taking `<kind>` from what is present under the record root rather than from a list held here.
 
 ### The tooling read takes a stack, always
 
 The tooling comparison runs last, because it needs a value the first read returns. Take `<stack>` from the first name in the report's `tooling.chain`, which records the stack nearest the target, and pass it:
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon tooling sync --check <stack>
+canon tooling sync --check <stack>
 ```
 
-Refuse the domain and report it unread when `chain` names nothing, rather than running the command bare. A bare call reaches the stack prompt, which the non-interactive variable resolves to the catalog's first option instead of refusing.
-
-Every target would then be compared against whichever stack sorts first, on every run, and the drift reported would be an artifact of the wrong comparison rather than anything the target did.
+Refuse the domain and report it unread when `chain` names nothing, rather than running the command bare. A bare call reaches the stack prompt, which refuses a headless caller, so it would report nothing about the domain.
 
 ### Domains come from the report
 

package/claude/skills/target-check/references/domains.md

@@ -72,10 +72,7 @@ Read the `tooling` block off the report first, because the comparison command ne
 
 ### The comparison
 
-On a measured report, take `<stack>` from the first name in `chain` and run `canon tooling sync --check <stack>`. Never run it bare.
-
-- Omitting the stack reaches a prompt the non-interactive variable resolves to the catalog's first entry rather than refusing
-- That compares the target against a stack it does not use and reports the difference as drift
+On a measured report, take `<stack>` from the first name in `chain` and run `canon tooling sync --check <stack>`. Never run it bare, since omitting the stack reaches a prompt that refuses a headless caller and compares nothing.
 
 ### Verdicts
 

package/claude/skills/target-setup/SKILL.md

@@ -33,9 +33,9 @@ rather than a step within it, so the full chain never runs it separately.
 
 ## Non-interactive path
 
-Every phase runs under `CANON_NON_INTERACTIVE=1` with no TTY. Three phases
-otherwise pause, and each takes an argument that answers its prompt ahead of
-time:
+Every phase runs headless with no prefix, since a call with no terminal on
+stdin is already headless. Three phases otherwise pause, and each takes an
+argument that answers its prompt ahead of time:
 
 | Phase               | Pauses to                                  | Answered ahead by                                          | With neither and no TTY                               |
 | ------------------- | ------------------------------------------ | ---------------------------------------------------------- | ----------------------------------------------------- |
@@ -91,7 +91,7 @@ target project's current directory. Do not cd into the toolkit source tree. The
 Step 1: `canon init` installs base tooling, claude seeds, and governance rules.
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon init \
+canon init \
   --stack <stack> \
   --add <rules> \
   <target>
@@ -106,7 +106,7 @@ Step 2: `canon tooling sync <tooling-stack> --write` installs stack deps, script
 - A fresh target has nothing to lose, so pass `--write` directly rather than reading a report first
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon tooling sync <tooling-stack> <target> --write
+canon tooling sync <tooling-stack> <target> --write
 ```
 
 ### Monorepo with multiple language roots
@@ -114,8 +114,8 @@ CANON_NON_INTERACTIVE=1 canon tooling sync <tooling-stack> <target> --write
 Run `canon init` once at the repo root so `base` (husky, oxfmt, commitlint, CI) lands once, then sync each subtree with `--skip base`. Take the subtree commands from the preview's per-root rows rather than picking folders by hand.
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon tooling sync vite-react ./frontend --skip base --write
-CANON_NON_INTERACTIVE=1 canon tooling sync python ./backend --skip base --write
+canon tooling sync vite-react ./frontend --skip base --write
+canon tooling sync python ./backend --skip base --write
 ```
 
 - Without `--skip base`, each subtree re-drops husky, and git honors only one `core.hooksPath`, so the extra hook dirs silently break
@@ -139,7 +139,7 @@ Resolve exactly as the detect reference states, confirm the proposed extras
 there, then run:
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon gov install <stack> --add <extras> <target>
+canon gov install <stack> --add <extras> <target>
 ```
 
 Report the rule count installed, the target path, and any rules that failed to

package/claude/skills/target-update/SKILL.md

@@ -24,7 +24,7 @@ Stop with the line beside each state.
 
 Then hold two rules for every verb this body runs.
 
-- Run it under `CANON_NON_INTERACTIVE=1` from the target root
+- Run it from the target root with no prefix, since a call with no terminal on stdin already runs headless
 - Branch on its record's fields rather than its exit, which a shell function wrapping `canon` can flatten
 
 ## Step 1: bring the binary and plugin forward
@@ -38,12 +38,12 @@ Both write to the machine rather than the target, and the preview needs the verb
 Run these in parallel from the target root:
 
 ```bash
-CANON_NON_INTERACTIVE=1 canon changelog --json
-CANON_NON_INTERACTIVE=1 canon migrate status --json
-CANON_NON_INTERACTIVE=1 canon sync --check . --json
+canon changelog --json
+canon migrate status --json
+canon sync --check . --json
 ```
 
-Then take `<stack>` from the first name in the report's `tooling.chain` and run `canon tooling diff <stack> . --json`. Never run it bare, since the stack prompt resolves to the catalog's first entry under the non-interactive variable. Report tooling unmeasured when `tooling.measured` is false or `chain` names nothing.
+Then take `<stack>` from the first name in the report's `tooling.chain` and run `canon tooling diff <stack> . --json`. Never run it bare, since the stack prompt refuses a headless caller. Report tooling unmeasured when `tooling.measured` is false or `chain` names nothing.
 
 ### When a read refuses
 

package/claude/skills/task-board/SKILL.md

@@ -74,10 +74,8 @@ Write `.canon/tasks/vXX.Y-<slug>.md` under the claimed label, reading the file f
 
 A task file with no row is a dropped task, so name its surface in the same pass that creates it. The test and both file shapes are in `${CLAUDE_SKILL_DIR}/references/board.md`.
 
-| Task                                        | Surface                                                                                                                                   |
-| ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
-| Plausibly planned within the next few waves | A row under `## Needs a plan` in `.canon/tasks/priority.md`, through `canon tasks place <stem> --group needs-a-plan --waiting "<reason>"` |
-| Anything else                               | A line in `.canon/tasks/backlog.md`, which is unordered                                                                                   |
+- A task plausibly planned within the next few waves takes a row under `## Needs a plan` in `.canon/tasks/priority.md`, through `canon tasks place <stem> --group needs-a-plan --waiting "<reason>"`.
+- Any other task takes a line in `.canon/tasks/backlog.md`, which is unordered.
 
 Position the row against its siblings with `--before <stem>` or `--after <stem>`, and state what it ranks against in the reason.