@erclx/canon 5.31.0 → 5.33.0

package/claude/skills/canon-rollout/SKILL.md

@@ -1,140 +0,0 @@
----
-name: canon-rollout
-description: Takes one toolkit change out to every consuming project and brings each to a mergeable pull request. Carries an orchestrator role that enumerates the targets, dispatches a worker into each, reviews every pull request, and routes what each review posts, and a worker role that builds inside one target and answers its review. Use when asked to "roll this out to the targets", "take this change to every project", "run a rollout wave", "update the consuming projects", or when a session was dispatched into a target by a wave. Do NOT use for this repository's own board, which is `role-orchestrator`, and merge nothing.
-disable-model-invocation: true
-metadata:
-  family: upkeep
----
-
-# Canon rollout
-
-This skill runs outward. Every other skill for operating on a target assumes the session already sits inside it, and this one starts in the toolkit and reaches the projects the toolkit installed into.
-
-One wave takes one toolkit change to every target and ends with a pull request per target for a person to merge. Two roles carry three phases over one target list. The orchestrator enumerates, dispatches, reviews, and routes. The worker holds one target from the worktree entry to the merge of the branch it opened.
-
-`role-orchestrator` owns this repository's own board and is a different subject. Read nothing from `.canon/tasks/` here and write nothing to it.
-
-## Take a role before anything else
-
-- The invocation or the launch prompt names the worker role, a target path, or both: worker. Skip to `## The worker role` and run no phase above it.
-- Neither is named: orchestrator. Run the three phases in order.
-
-The role is read off the prompt because nothing else carries it. A test on the working directory answers the same for a worker in a target and an operator who invoked this from one, and reading the role wrong starts a second wave from inside a consuming project.
-
-Do not invoke `canon:role-worker` from either role. That body states the role for a session building one branch under one plan in this repository, and it resolves session scratch against a main worktree root a target does not carry, so a rollout worker reading it hunts for a plan nobody wrote.
-
-## Guards
-
-- `gh` absent from the path: stop. `❌ gh is not installed, so no target's pull request can be read or opened.`
-- `canon targets list` refuses, or reports the index as unknown with no `--sweep` behind it: stop and name the reason. A count of zero taken from an index nothing read is a confident wrong answer.
-- Read a record's own `reason` field rather than a command's exit status. An operator's shell profile may wrap `canon` in a function whose status comes from a trailing command, which reports every refusal as success.
-- Neither role merges anything, at any size and with no proportionality exception. A wave ends by handing the operator a list to merge from, and merging is the one act only they perform.
-
-## The fixed shape every target receives
-
-Every target in every wave takes the same branch and the same title, written from here rather than chosen per session.
-
-- Branch: `chore/agents`, in every target and every wave.
-- Title: `chore(agents): <what changed in that target>`.
-- Body: the sections `${CLAUDE_SKILL_DIR}/../../standards/pr.md` fixes, describing what that target received.
-- Body, one line: name this toolkit as the source of the changed files and where to change the content upstream. A reader in that repository months later has no other route to the fact that these files are toolkit-managed and that a local edit is lost at the next wave.
-- Body, no version number anywhere in it. `${CLAUDE_SKILL_DIR}/../../standards/versioning.md` permits a semver tag only where the pull request cuts a release, and `canon/config/config.json` in the target already records `syncedAt` and a sha256 per synced file. A version in the body is a second copy of a fact the target holds canonically, and it is the copy that goes stale while the pull request sits open.
-
-The title withholds the source and the body supplies it, because the two have different audiences. `agents` says what changed without saying where it came from, which is what a target's own history wants, and the source line is for a reader inside that repository rather than for whoever merges.
-
-One branch name across every target is also what lets the return leg resolve. `canon sessions list --branch chore/agents --repository <clone>` answers about that project rather than the working one, and a branch each session named for itself gives that read nothing to match.
-
-## Phase 1: enumerate and dispatch
-
-### Read the population
-
-1. Pin the wave. Record the commit of this repository that the wave carries and name it in this session's own reports. Name it in no target's body.
-2. Enumerate. Run `canon targets list --json` under `CANON_NON_INTERACTIVE=1`, adding `--sweep <root...>` to reach targets installed before the index existed. Read the `bound` object back before treating any count as the population, since it names the roots walked, the depth, where the walk stopped, and what it could not read. The bound a sweep can never state is the machine, so a target on another one sits outside every answer it gives.
-3. Pick the clone that is current. A row carries every checkout of that project under `paths` and leads with the one a sync ran in, which records where an install happened rather than what the checkout holds today. Fetch each candidate, compare it against the origin's default branch, and dispatch into one that is level. Refuse one that is behind rather than branching from a stale base, since a stale clone reads as still owing a repair its remote already carries.
-
-### Check, then dispatch
-
-4. Check the branch is unclaimed in that target. Run `canon sessions list --branch chore/agents --repository <clone> --json` and read `claimed` off the record.
-   - `claimed: true`: something already holds it. Report what does, `worktree` when it names a path, `sessions` when it carries a row, and `refs` when the branch already exists, then leave that target out of the wave rather than colliding.
-   - `claimed: false` with `sessionsReadable` and `refsReadable` both true: dispatch.
-   - Anything else, a refusal or a record carrying no `claimed` key included: treat the target as unverified rather than clear, name which reading could not be taken, and hand it to the operator to launch by hand. Dispatching on a check that could not be read reproduces the collision the check exists to prevent.
-5. Dispatch one worker per target, one session each.
-
-```bash
-cd <clone> && claude --bg --model <model> -n "rollout-<target>" "Run /canon:canon-rollout in the worker role against the target at <clone>. <what the wave carries>"
-```
-
-`--bg` returns immediately, `-n` sets the name that separates a wave's worker from an operator's own launch in the roster, and `--model` overrides the inheritance that otherwise spends this session's model on every worker. Keep the `rollout-` prefix.
-
-Running the targets in turn is the alternative and it puts every target's diff through one session's context. A wave's spend scales with the target count instead, and nothing caps it, so weigh the count before widening rather than after.
-
-Report each dispatch by naming the target, the clone, the branch, the model, and the session name. Carry the pull request URL into every later report from the moment its worker announces one.
-
-## Phase 2: review every pull request
-
-1. Poll. Run `canon targets pulls --json`, naming the wave's clones as arguments to read those alone. A target comes back as `read` with a `pulls` array or as `refused` with a `reason`, and a refusal is not a target with no work. Reading a failed query as no open work reports a target as done having read nothing.
-2. Review here, in this session. Invoke `canon:review-pr` and redirect every call that body makes, since it resolves a pull request from the repository the session stands in and this session stands in the toolkit. Every call takes a redirect, and the ones that silently answer about the wrong repository are worse than the ones that fail:
-   - `--repo <owner>/<name>` on `gh pr view`, `gh pr diff`, and `gh pr review`, where it is a global flag.
-   - `-C <clone>` on `git fetch origin pull/<n>/head`, `git merge-base`, `git diff`, `git log`, `git show`, and `git grep`.
-   - `GH_REPO=<owner>/<name>` on any `gh api repos/{owner}/{repo}/...` call, which is the close-out route. `gh api` takes no `--repo` flag and fills those placeholders from the working directory or from that variable, so the one call a flag cannot redirect is the one that edits a review in place.
-   - That project's own root file, rules, and context, read from under the clone.
-
-   A missed redirect reports rather than fails. A pass that redirects the `gh` half and leaves a `git` call alone reads this repository's history against a target's diff and reports a delta, which is a finding nobody can trace back to the call that produced it.
-
-   This session wrote none of these diffs, so reviewing them costs nothing in independence.
-
-3. Dispatch a reviewer into the target when a diff is too large for this session to hold. That is the fallback rather than the default. Dispatching one per target was measured and what it saved was reading four diffs, not reading four sets of findings, and that second half reaches this session either way, since routing a finding back means composing the brief from it.
-4. Read the heading each pass posted. `canon targets pulls` reports `review` as `open`, `closed`, or `null` when no pass has landed, and reports `reviewReadable` as `false` when the query failed, which leaves `review` covering nothing.
-
-## Phase 3: route every finding and close each target
-
-1. Address every finding whatever its severity. A minor is a finding, and a reviewer calling one non-blocking does not close the pass that raised it.
-2. Resolve who holds the branch before dispatching anybody. Run `canon sessions list --branch chore/agents --repository <clone> --json` and read the count rather than the first row.
-   - A live session holds it: send that session the findings and name `canon:review-address` for it to run, which is step 7 of `## The worker role` and the step that session already stands at. Never name this skill in that message. This body carries `disable-model-invocation: true`, which blocks the `Skill` tool rather than only suppressing an auto-trigger, and a session acting on an inbound message reaches a skill that way and no other, so a message naming this one halts the address leg with the branch built and the findings unread. A launch prompt is the one route to a flagged body, which is why the dispatch above names this skill and this message must not. Never assume the worker is gone, since a fresh addresser sent over a live one either refuses on the worktree lock or cuts a second worktree on the same branch.
-   - No live session holds it: dispatch a fresh worker into that clone and brief it with the findings, since it holds none of the reasoning behind the diff.
-   - More than one row: report the ambiguity and stop rather than picking among candidates.
-3. Re-review when the answer lands, scoped to the commits added since. A worker's reply never closes a target, since a fix can introduce findings of its own in the prose it adds.
-4. A target leaves the wave when a pass posts `## Review closed` and not before.
-5. Run until every target closes. No count bounds the loop. What guards it is this session reviewing every round itself, so it holds what each pass found and can see a target failing to converge, where a dispatched reviewer reads one pass and knows nothing of the one before it. A worker introducing a finding per fix has nothing mechanical stopping it, which is accepted rather than overlooked.
-
-## The worker role
-
-One session, one target, from the worktree entry to the merge of the branch it opened. It diagnoses, implements, opens the pull request, and answers what the review posts. It reviews nothing and it merges nothing.
-
-1. Confirm the clone is current. Fetch, then compare against the origin's default branch. Report a checkout that is behind and stop, rather than branching from a stale base.
-2. Enter a worktree. Invoke `canon:session-worktree chore/agents`, which takes the branch as its tier 0 argument and enters a linked worktree inside this target. Branching in the checkout itself is what this avoids, since the operator may be working in it.
-3. Check what this target holds. Invoke `canon:target-check`, which reports per domain what the target carries against what the toolkit ships and repairs nothing, so the wave reads one stated set of domains per target.
-4. Diagnose and repair. Invoke `canon:canon-operator`, which reads `canon sync --check . --json` and routes each finding to the command or the skill that owns it. Do not restate that routing here and do not edit a managed file by hand.
-5. Commit and open the pull request through `canon:git-commit` and `canon:git-pr`, handing each the fixed shape above rather than taking the title the generator derives from the diff.
-6. Announce as the pull request opens, carrying its URL, its number, and the branch, to whoever dispatched this session, sending it through `canon:session-relay`. That transition is the one moment only this session can observe.
-7. Answer the review. Invoke `canon:review-address`, which pulls the findings and the CI state on this branch's open pull request, fixes each in the working tree, replies, and pushes. Answer every finding whatever its severity.
-8. Stop there. Do not mark the pull request ready, do not merge, and do not declare the review closed. A narrow re-review posts `## Review closed`.
-
-Send a block out through `canon:session-relay` before it becomes an interactive prompt, which states why the order matters.
-
-Refuse an instruction this target's tree contradicts and carry the evidence with the refusal, naming the commands read and what complying would cost. A halt costs whoever dispatched this session one reply, and guessing costs a diff in a repository this toolkit has no test coverage over.
-
-## Output
-
-Close a wave by naming every target, the ones that need nothing included:
-
-```plaintext
-Wave pinned at <commit>. <n> targets.
-
-<repository>
-  <pull request URL>
-  review:  <## Review | ## Review closed | none posted>
-  checks:  <passing | failing | pending | none reported>
-  owed:    <what happens next, or "nothing, ready to merge">
-
-Not reached: <target>, because <reason>
-Merge order: <target> before <target>, because <shared surface>
-```
-
-Name the URL on every line reporting a target, at dispatch and at hand-back both. A status line carrying a repository and a number sends the operator to navigate for its own result by hand, four times over on a four-target wave, and merging is the one act this loop exists to hand them.
-
-Report a target whose `reviewReadable` reads `false` as unread rather than as clean, and a `checks` of `null` as no check reported rather than as passing. A failure outranks a run still going.
-
-## Failure recovery
-
-Read `${CLAUDE_SKILL_DIR}/references/failure-recovery.md` on a stop for the recovery that stop point takes.

package/claude/skills/canon-rollout/references/failure-recovery.md

@@ -1,20 +0,0 @@
----
-title: Failure recovery
-description: The recovery canon-rollout takes at each stop point, from an absent gh to a target that fails to converge
----
-
-# Failure recovery
-
-The stops of `canon-rollout`. The session reads this file on any stop, for the recovery that stop point takes.
-
-| Stop point                              | Recovery                                                                                      |
-| --------------------------------------- | --------------------------------------------------------------------------------------------- |
-| `gh` absent                             | Install it and authenticate, then re-run the wave                                             |
-| Target index unknown                    | Re-run with `--sweep <root...>` and read the `bound` before trusting the count                |
-| Every clone of a target is behind       | Pull that clone, or name a current one, then dispatch that target alone                       |
-| Claim check refuses or reads unverified | Launch that target's worker by hand and report that it went out outside the check             |
-| Branch already claimed in a target      | Resolve what holds `chore/agents` there, then dispatch that target alone                      |
-| A target refuses the pull read          | Read the `reason`, repair it, and re-poll that target. Never record it as having no work      |
-| Diff too large to review here           | Dispatch a reviewer into that clone and route its findings back through Phase 3               |
-| Two sessions hold one branch            | Report both and stop. Sending findings to either puts two sessions on one ref                 |
-| A target fails to converge              | Stop that target's loop, report the rounds it took and what each pass found, and hand it over |

package/claude/skills/context-fold/references/anchor-sweep.md

@@ -1,58 +0,0 @@
----
-title: Architecture anchor staleness sweep
-description: How an anchored decision's cited paths are collected, the finding the diff fires, and the report line
----
-
-# Architecture anchor staleness sweep
-
-Mechanics for Step 5 of `context-fold`. The body owns the skip conditions, the report-only constraint, and the standard citation, and this file owns what the sweep does once the diff touches a path an anchored decision cites.
-
-## Anchored entries
-
-Read `canon/ARCHITECTURE.md` and take the H3 entries under `## Key technical decisions`. An entry is anchored when its reasoning closes on the marker the standard fixes:
-
-```plaintext
-Measured at <short-sha> on <YYYY-MM-DD>.
-```
-
-Skip every entry without one. An unanchored entry either predates the rule or cites no measured number, and the standard calls both correct, so the sweep has nothing to say about either.
-
-For each anchored entry, collect the backticked code paths its reasoning cites. Same read the diagram sweep runs over an explanation, against a paragraph instead of a diagram.
-
-Most of these name a folder rather than a file, because the number an entry anchors is usually a count over a tree. Match accordingly:
-
-- A citation naming a file matches when the diff carries that file, wherever it sits. A file at the repository root such as `CLAUDE.md` is a file citation like any other.
-- A folder citation, which is one ending in a slash, matches when the diff carries any path under it.
-- A folder citation of a single segment matches nothing and is skipped.
-
-The third rule reaches folders alone, which is what keeps it off `CLAUDE.md`. Breadth is the whole reason it exists, and a root file has none: it names one path the diff either carries or does not.
-
-What it does stop is a citation of `.claude/` matching every branch. `src/`, `scripts/`, and `.claude/` each name a tree a project organizes most of its work under, so a prefix match on one fires constantly and rebuilds the ignored warning this sweep exists to avoid. Measured against this repository's record, the skip drops 13 of the 26 folder citations and keeps the ones carrying a signal, among them `src/tooling/`, `.claude/rules/`, and `governance/rules/`.
-
-A decision whose folder citations are all a single segment, and which cites no file, therefore never fires. That is the correct outcome rather than a gap: a count over a whole tree moves on nearly every branch, so flagging it every time tells a reader that time has passed and nothing else.
-
-## The finding
-
-Report an entry when the diff touches one of its cited paths, however it was touched. A delete, a rename, and an edit inside the file all move a count of what sits under that path, and the entry's number was read before any of them landed. The diagram sweep narrows to deletes because a diagram survives a body edit, and a number does not.
-
-The anchor's own SHA settles nothing here. A branch is compared against its merge base rather than against the commit the anchor names, so an entry anchored at a commit this branch already contains is still due a read once the branch moves what it counted.
-
-Report an entry once however many of its cited paths the diff carries. Name the first as the evidence and leave the rest, since the reader opens the entry either way and a line per path buries the entry it is about.
-
-What this misses is a claim whose number moved with no matching citation in the diff, whether because the branch never touched the tree it counts or because the entry cites nothing narrower than one segment. That is the recall this trades for precision, and the alternative is re-running an arbitrary measurement read out of prose, which no sweep does reliably.
-
-## What the sweep never does
-
-- Write into the entry. The anchor is a sentence rather than a frontmatter field, so the marker and the claim share one paragraph and an edit reaching one reaches the other.
-- Refresh an anchor. Re-reading the number is the act the marker records, so a date written by a pass that measured nothing is the false confidence the marker exists to prevent.
-- Flag an unanchored entry. The standard scopes the rule forward, and an entry written before it is dated by blame rather than by a read.
-
-The session amending a decision writes its anchor, which Step 3 already requires. Step 3 holds the writer, and the two never meet. Anchoring fires when this run amends a decision, and this sweep fires when the diff moves a path under one, so a single step covering both would gate the anchor obligation on a signal that has nothing to do with it.
-
-## Output
-
-Output one line per finding:
-
-`⚠ Anchor stale: "<decision name>" cites <path>, which this branch changed. Re-measure and refresh the anchor.`
-
-If no anchored entry cites a changed path, skip silently. A record carrying no anchored entry produces no output on any branch, which is every project until a decision is written or amended under the rule.

package/claude/skills/context-fold/references/promoted-pages.md

@@ -1,29 +0,0 @@
----
-title: Fold promoted pages
-description: How context-fold Step 8 lands each page a teach promotion handoff carries, deletes the handoff, and reports what it landed or left unfolded
----
-
-# Fold promoted pages
-
-Step 8 of `context-fold`. The session reads this file when a teach promotion handoff exists.
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`, falling back to `latest` on an empty result, and read `.canon/tmp/handoff/teach-promotion/<slug>.md` at the main worktree root. `teach-workspace` writes it, one H2 per destination naming the path, with a source line under the heading and the page body in a fenced block below that. Read the body out of the fence rather than off the heading level, since a reference page carries headings of its own and only the fence separates them from the next destination. Skip this step silently when the file is absent, which is every run where nothing was promoted.
-
-Each block is a page an operator already confirmed a destination for, so this step lands it rather than judging it again. Write to the destination the heading names, at `pwd` rather than at the main root, since every destination here is a tracked file that commits with the branch:
-
-- A wiki page and a public doc arrive as a whole file. Write it as the block gives it, and stop with the block unfolded when the destination path already holds a file, since overwriting a page someone else wrote is not a fold.
-- A context entry is merged into rather than created. Fold the body into the sections it belongs under, the same way the routed facts above are folded, and never add an entry the catalog does not already carry.
-
-Then delete the handoff file so a later run does not fold it twice, and regenerate the index of any folder that carries one.
-
-Output one line per page landed:
-
-`✅ Promoted: <destination path>`
-
-Add a line naming the handoff when one was consumed:
-
-`🧹 Folded: .canon/tmp/handoff/teach-promotion/<slug>.md`
-
-Report a block left unfolded rather than dropping it:
-
-`⚠ Skipped: <destination path> already exists. Merge by hand.`

package/claude/skills/context-fold/references/receipt-sweep.md

@@ -1,43 +0,0 @@
----
-title: Sweep consumed receipts
-description: How context-fold Step 9 sweeps branch review reports whose branch is gone and fully decided memory receipts, and what it keeps and reports
----
-
-# Sweep consumed receipts
-
-Step 9 of `context-fold`, reached in order on every run.
-
-Sweep the review and memory receipts this session consumed. Resolve all paths at the main worktree root, not the current worktree, the way `session-worktree` does.
-
-Every delete below is a plain `rm`, one per call, routed the way `session-worktree` states.
-
-Plans are not swept here. A plan is settled by the merge rather than by an outcome this run marked, and `canon tasks archive` moves it with the task the `post-merge` hook archives. Sweeping it from this step read a closure Step 3 had written moments earlier and moved a plan the branch was still building from.
-
-## Reviews
-
-Leave the current branch's review receipt where it is. `auto-ship` Step 6 keeps minor findings in `.canon/review/branch-<slug>.md` and its closing block hands the reader that path, so deleting it here removes the file the chain that invoked this skill is still citing. Seven runs recorded that collision across two days before a sandbox fixture asserted the receipt and could pass only on a run the chain stopped early.
-
-The body that writes a receipt owns its lifetime. This skill sweeps on behalf of whatever called it and has no way to read whether a file is still in use, where the chain that wrote this one cites it in its own output and knows. What reaps it is the branch sweep below, one branch later, once the branch it names is gone.
-
-Sweep the branch reports this session never opened. List `.canon/review/branch-*.md`, run the slug transform in `${CLAUDE_SKILL_DIR}/../../standards/slug.md` over every name `git branch --format='%(refname:short)'` prints, and delete a report whose slug matches none of them. Take the names from that format rather than from `git branch --list`, which marks the current branch with `* ` and a branch checked out in another worktree with `+ `, so a transform reading the marked lines as written turns a live branch into a slug nothing matches and sweeps a report a sibling worktree is still working from. A branch report is read once, by the session addressing it, and the durable record of what a review found is the comment `review-pr` posts on the pull request, so a report outliving its branch is holding nothing. Skipping this leaves them accumulating for the life of the checkout, since a slug is unique per feature and no later branch ever looks for one.
-
-What that removes is a local-only review on a branch deleted before it opened a pull request. `review-branch` says so where a reader meets the report, and the sweep runs anyway rather than keeping every report against the one case, since nothing else ever clears them.
-
-Memory receipts sweep board-wide rather than by slug. Scan every `.canon/memory/review/memory-review-*.md`, not only the one matching this slug. `memory-review` writes its receipt after this skill has run in every ship chain, so a sweep keyed on the current slug looks for a file that does not exist yet, and no later branch looks for it either because a slug is unique per feature. Scanning the folder is what makes the sweep fire at all.
-
-For each receipt, count the H2 items still pending. An item is pending when its H2 carries 📝, or when its H2 carries no status emoji and its `Decision:` slot holds nothing `memory-review` Apply would act on or skip, since a receipt written by hand or by an older binary may lack the marker, and Apply's parse leaves every other slot value undecided:
-
-- No pending item: fold it per the collection rule in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`, then delete the receipt.
-- Any pending item: leave it and report the count. Pending items are decision state, and a branch shipping is not an operator deciding them.
-
-That standard owns what a fold writes and which entry types take one. `memory-review` collects a receipt on the same rule, so neither body restates it.
-
-Do not sweep `ux-audit-*.md` or `ux-measure-*.md` (standalone deliverables). Those sit at `.canon/review/` itself rather than under a producer folder, so the two globs above never reach them.
-
-Output one line per file swept:
-
-- `🧹 Deleted: <path>, branch gone` for a branch report whose branch no longer exists
-- `🧹 Deleted: <path>, folded <n> skips` for a swept memory receipt
-- `⏭ Kept: <path>, <n> items pending` for a memory receipt still holding decisions
-
-If nothing qualifies, skip this step silently.

package/claude/skills/context-fold/references/wireframe-sweep.md

@@ -1,45 +0,0 @@
----
-title: Wireframe coverage sweep
-description: Slug derivation from a UI-affecting path, the contradicted and uncovered findings, the surface stub, and the report lines
----
-
-# Wireframe coverage sweep
-
-Mechanics for Step 4 of `context-fold`. The body owns the skip conditions and the UI-path filter, and this file owns what the sweep does once a UI-affecting path survives that filter.
-
-## Deriving a candidate slug
-
-For each UI-affecting path, derive a candidate surface slug from the file's basename and parent folder (e.g. `web/src/features/mock/MockDemoStrip.tsx` → `mock-demo-strip` or `mock`). Cross-reference against every surface file in `canon/wireframes/`, including one nested inside a grouped surface's own subfolder (`canon/wireframes/<group>/<surface>.md`), by walking the tree rather than globbing the top level alone.
-
-## Findings
-
-**Contradicted sections.** When a surface file exists for a path in the diff and the diff renames or removes a literal string that appears in the wireframe prose (e.g. provider name, button label, copy string), output a one-line report entry and stop. Do not auto-rewrite prose. Operator resolves.
-
-**Uncovered surfaces.** When a UI-affecting path has no matching surface file by slug, write `canon/wireframes/<slug>.md` with this stub:
-
-```markdown
----
-title: <Slug as title case>
-description: TODO: describe the surface.
----
-
-# <Slug as title case>
-
-TODO: describe when and where this surface appears.
-
-## Behavior
-
-- TODO
-```
-
-Skip the write when the slug would collide with an existing file, flat or nested (different surface, same slug). Surface the collision in the report instead.
-
-## Output
-
-Output one line per finding:
-
-- `⚠ Wireframe drift in canon/wireframes/<surface>.md: <contradicted string>`
-- `📝 Stubbed: canon/wireframes/<surface>.md`
-- `⚠ Slug collision: <slug> matches existing <existing-surface>.md, review and rename`
-
-If the sweep finds nothing, skip silently.

package/claude/skills/create-standard/REQUIREMENT.md

@@ -1,33 +0,0 @@
----
-name: create-standard
-description: Why a standard needs its shape read from the meta-standard before anything is drafted, and why the follow-up depends on who owns the folder it landed in
----
-
-# Create standard requirement
-
-## Gap
-
-Without this skill, a standard is written from memory of what other standards look like. It arrives without the scope section that says what the file does not govern, so the next author cannot tell whether a rule belongs to it or to a sibling, and two standards end up claiming the same subject with no way to settle which one wins.
-
-The second write surface is the second failure. A standard put under `.claude/standards/` looks like a correct file and reaches no resolver, since nothing installs the corpus into a project and no repository generates a copy there. One write surface removes the choice: `standards/` is what the resolver reads first and what every author writes to, in the toolkit and in a project alike.
-
-A standard written and left there is the third. The index entry and the context table are both generated or maintained downstream of the write, so a file that ships without them is catalogued nowhere and reached only by whoever already knew the path.
-
-## Must
-
-- Read the meta-standard before drafting, since the shape is what makes the file arguable against a sibling
-- Write to `standards/`, creating it when absent, since it is the one root the resolver reads and the only surface either kind of author has
-- Confirm the slug and the full body with the user before writing
-- Emit the written path in full, so the terminal can resolve it
-- State what the write implies for whoever owns the folder, since a toolkit standard needs the index regenerated and a project-local one needs copying to the toolkit to ship
-
-## Must not
-
-- Work the standard's shape or frontmatter from memory
-- Write into `.claude/standards/`, which no repository generates and no resolver reads
-
-## Out of scope
-
-- Editing a standard that already exists
-- A path-scoped coding rule, which `create-rule` owns
-- Reading a standard the toolkit ships, which `canon standards <name>` owns

package/claude/skills/create-standard/SKILL.md

@@ -1,31 +0,0 @@
----
-name: create-standard
-description: Creates a new standard file in `standards/`. Use when asked to "create a standard", add a standard, or write a new authoring convention. Do NOT use to edit an existing standard.
-metadata:
-  family: generate
----
-
-# Create standard
-
-Creates one standard file. Read these files in parallel:
-
-- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting for all generated text
-- The `write-human` skill: voice, rhythm, and sentence construction for all generated text
-- `${CLAUDE_SKILL_DIR}/../../standards/standard.md`: the meta-standard for shape, frontmatter, and structure
-
-## Steps
-
-1. Draft the content from the user's description. The meta-standard governs frontmatter, headings, and structure.
-2. Confirm the slug and full content with the user before writing
-3. Write the file to `standards/<slug>.md`, creating the folder when it is absent
-
-`standards/` is the one write surface. It is the toolkit's authoring source in this repository and a project's own folder anywhere else, and both are the root `canon standards <name>` resolves against first. No corpus installs into a project, so there is no second surface to pick between and no guard on a folder the skill can create itself.
-
-## After writing
-
-Emit the full path on its own line.
-
-- In the toolkit: this is the authoring source. Remind the user to run `bun run check` to regenerate the consumed copy under `.claude/`. That pass also regenerates the `standards/index.md` entry, and the user adds a row to the standards table in `canon/context/standards/overview.md`. <!-- canon-allow-reference: audience-branched, only a toolkit-repo reader reaches this line and that reader can open the path -->
-- In a project: the file is project-local and no toolkit command touches it. Remind the user to copy it to the toolkit repo, under `standards/<slug>.md`, if it should ship to every project.
-
-Separate the two by whether the folder already held toolkit-authored standards before this write, since a project authoring its own uses the same path.

package/claude/skills/design-extract/REQUIREMENT.md

@@ -1,42 +0,0 @@
----
-name: design-extract
-description: Why a design system is drafted from what the tree already holds, and how a proposed value is kept distinguishable from a sourced one
----
-
-# Design extract requirement
-
-## Gap
-
-Without this skill, a session asked for a design system either invents token values with nothing behind them or refuses because the project ships no stylesheet. It writes over a `canon/DESIGN.md` someone already filled. It fills every cell so the file looks complete, which leaves a reader unable to tell a hex sampled from the CLI apart from one the session made up, and a proposal nobody flagged gets built on. A trailing tag column added to mark that uncertainty breaks the render parser instead.
-
-The greenfield case is the one that fails quietly. A project with no UI code still has a personality paragraph and a stated platform, so values can be proposed against a signal rather than pulled from a default palette. A session that does not know this reports there is nothing to extract.
-
-## Must
-
-- Pick the source or greenfield path from what the project tree holds, never from a flag or an argument
-- Announce which path ran, since the two produce different-looking output from one skill
-- Fetch the seed template and keep every heading and table header intact, because the render parser reads them
-- Mark any cell not traced to a source value inline inside the cell value, and take the uncertainty into the sentence when the section is prose
-- Anchor every greenfield proposal to a personality or requirements signal rather than to a default
-- Render the preview and report its path, so the proposals get looked at before they are committed
-
-## Must not
-
-- Overwrite a `canon/DESIGN.md` that already carries content beyond the seed
-- Guess a value on the source path when no signal exists. Leave the cell blank instead.
-- Invent a non-goal. A proposed motion line is correct when nothing rules motion out.
-- Put the verify tag in a trailing column, which breaks the row
-- Rewrite the transcribed personality paragraph, which is the one section that is not a proposal
-
-## Guards
-
-- `canon/DESIGN.md` already populated: stop rather than mutating it
-- `canon` not on PATH: stop, since the seed template and the render both need it
-- Greenfield path with no `canon/REQUIREMENTS.md` or no `## Personality` section: stop, because there is nothing to propose against. Evaluate this only after Step 1 picks the path.
-
-## Out of scope
-
-- Mutating an existing design system, which is a direct edit of the file rather than a skill
-- Producing the HTML and CSS preview, which `canon design render` owns
-- Auditing the implemented UI against the tokens, which `ux-audit` owns
-- Architecture and flow diagrams, which `draft-figure` owns

package/claude/skills/design-extract/SKILL.md

@@ -1,108 +0,0 @@
----
-name: design-extract
-description: Drafts `canon/DESIGN.md` from a project's existing prose and shell UI surfaces, or proposes token values from `REQUIREMENTS.md` and a `## Personality` section when no UI code exists yet. Use when asked to "extract the design system", "draft DESIGN.md", "bootstrap design tokens", "capture the visual system", "propose a design system", "bootstrap DESIGN.md from scratch", "draft tokens for a greenfield project", or "replace Claude Design onboarding". Do NOT use to mutate an existing `canon/DESIGN.md`.
-metadata:
-  family: setup
----
-
-# Design extract
-
-## Guards
-
-- If `canon/DESIGN.md` already exists and has content beyond the seed template, stop: `❌ canon/DESIGN.md already populated. Edit directly or archive the existing file first.`
-- If `canon` is not on PATH, stop: `❌ canon CLI not found.`
-
-Step 1 carries two more stops that apply to one path only. Do not evaluate them before the path is picked.
-
-## Step 1: pick the path from what the project already has
-
-Check the project root for UI surfaces: `src/ui.ts`, `src/ui.tsx`, `src/components/**`, `scripts/lib/ui.sh`, and any `*.css`, `tailwind.config.*`, or `theme.*`.
-
-- Any match takes the source path. Existing code defines the system, so every filled cell traces to a value already in the tree.
-- No match takes the greenfield path. Nothing anchors a value there unless a picked reference does, so name `sketch-design` as the first move: a picked reference anchors a cell where a paragraph alone cannot. A direct run of this skill still falls through to the proposal-from-personality rules in Step 4, tag included, so this skill stays runnable on its own with nothing rendered yet.
-
-The project decides this, never a user flag or an argument. Announce which path ran in one line before Step 2, since the two produce different-looking output from the same skill.
-
-The greenfield path needs a personality paragraph to propose against, and stops without one. The source path needs neither file and skips both stops.
-
-- If `canon/REQUIREMENTS.md` is missing, stop: `❌ canon/REQUIREMENTS.md not found. Write requirements before proposing a design system.`
-- If `canon/REQUIREMENTS.md` has no `## Personality` section, stop: `❌ canon/REQUIREMENTS.md missing ## Personality section. Add a paragraph describing voice and tone before running this skill.`
-
-## Step 2: read source signals in parallel
-
-Read these on both paths, skipping any that do not exist:
-
-- `CLAUDE.md`: voice and personality
-- `canon/REQUIREMENTS.md`: the `## Personality` paragraph, worldview, non-goals
-- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: word, punctuation, and formatting constraints
-- The `write-human` skill: tone and sentence construction constraints
-
-On the source path, also read the UI surfaces matched in Step 1 plus `canon docs output-shape` and `canon docs index`, for output shape or framing rules already documented in the toolkit's own reference. Skip either that fails to resolve, since a project keeping its framing rules elsewhere is read there instead.
-
-On the greenfield path, also read `canon/ARCHITECTURE.md` for platform, tech stack, and surface type. Do not scan `src/`, stylesheets, or UI modules. Step 1 already established they hold nothing.
-
-On the greenfield path, also check `.canon/picks/*/design-handoff.md` for a file the `sketch-design` skill wrote, taking the most recently modified match when more than one exists. Read it when found. Its presence is what Step 4 traces cells from instead of proposing them.
-
-Run these reads in parallel. Do not speculatively recurse into every directory.
-
-## Step 3: fetch the seed template
-
-Run this from the project root:
-
-```bash
-canon claude seeds list --json | jq -r '.[] | select(.path == "canon/DESIGN.md") | .content'
-```
-
-Use the returned content as the target shape. Keep every section heading and every table header intact. The `canon design render` parser depends on them.
-
-## Step 4: fill the template
-
-Walk each section once. Follow `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md` for punctuation throughout: no em dashes, no semicolons. Use commas or separate sentences instead. Load the `write-human` skill for word choice, which keeps marketing words out.
-
-Mark any cell not traced to a source value by appending ` ? verify` inside the cell value, never as a trailing column. The cell stays inside the table shape: `| #ffffff ? verify |`. A trailing `| ? verify` after the row breaks the parser. A prose section takes its uncertainty inline instead, for example `Proposed 150ms ease-out, not yet confirmed.`, because a trailing tag on a sentence renders raw in the preview.
-
-On the source path, the tag marks the exception. On the greenfield path it marks nearly every cell, since the values are speculative until code or a designer anchors them.
-
-### Source path
-
-- **Personality**: one paragraph. Transcribe what `CLAUDE.md` and `canon/REQUIREMENTS.md` say about voice, tone, and visual feeling. Do not invent rules the source does not state. If nothing matches, write a one-sentence placeholder ending in `? verify`.
-- **Color**: one row per role. Source hex values from the CLI UI files or stylesheets. If a role has no source signal, leave `Value` blank rather than guessing.
-- **Typography**: one row per role. Source families and sizes from stylesheet or theme config. Leave cells blank when no signal exists.
-- **Spacing**: fill the base unit and multipliers from stylesheet tokens or obvious repeated values in the UI code.
-- **Borders**: one row per role. Source from stylesheet or CSS variables.
-- **Motion** and **Iconography**: one line each. Default to `No animation.` and `No custom icons.` when no evidence exists.
-
-### Greenfield path
-
-Anchor every proposal to a signal, never to a default. "Calm and dense" pins muted grays and tight spacing. A requirements non-goal of "no motion" makes Motion read `No animation.` with no tag. A CLI-only surface leans Typography monospaced and keeps Borders minimal.
-
-- **Traced cells**: when Step 2 matched a `design-handoff.md` file, fill only the fields it actually states, no tag, the same traced-versus-proposed distinction the source path draws for a stylesheet value.
-- The handoff carries hex and family and size, never Weight, Line height, or a color's Intent. Those cells, every field of a role the handoff never names, and Motion and Iconography regardless, still follow the proposal rules below, tag included.
-- **Personality**: transcribe the `## Personality` paragraph from `canon/REQUIREMENTS.md` verbatim. This is the one section that is not a proposal. No tag.
-- **Color**: one row per role. Rewrite the Intent cell in personality language, for example `near-white page canvas` instead of the seed default `page canvas`. Propose hex values matching the personality. Dense and calm gives low saturation and high text contrast. Playful gives saturated accents. Every Intent and Value cell gets `? verify`.
-- **Typography**: one row per role. Propose families fitting the platform, system UI for web, monospaced for CLI tools, serif for editorial, and a harmonious scale. Every cell gets `? verify`.
-- **Spacing**: propose a base unit matching density intent. Dense gives a 4px base, roomy gives 8px. Keep the Multiplier column as the seed ships it, no tag. Only the Value column gets `? verify`.
-- **Borders**: propose radius and width per role. Sharp and technical gives a small radius, soft gives a larger one. Every Radius and Width cell gets `? verify`.
-- **Motion**: one line. Write `No animation.` when the requirements forbid motion. Otherwise phrase the uncertainty inline.
-- **Iconography**: one line. Propose style and source library matching personality, phrasing the uncertainty inline.
-
-Do not invent non-goals. A proposed motion line is fine when neither the personality paragraph nor the requirements rule motion out.
-
-## Step 5: write and render
-
-Write the filled template to `canon/DESIGN.md` from the project root. Then run:
-
-```bash
-canon design render
-```
-
-The command writes an HTML plus CSS preview to `.canon/tmp/render/design/`. Output the path in chat so the user can open it.
-
-## Response format
-
-```plaintext
-📝 Wrote canon/DESIGN.md
-📝 Wrote .canon/tmp/render/design/index.html
-
-Ran the <source|greenfield> path. N cells marked `? verify`. Open the preview and confirm before committing.
-```