@erclx/canon 5.31.0 → 5.33.0

package/claude/skills/restate-plainly/REQUIREMENT.md

@@ -1,41 +0,0 @@
----
-name: restate-plainly
-description: Why a plain restatement is asked for by name, and where its boundary sits against the skill that drafts and the command that measures
----
-
-# Restate plainly requirement
-
-## Gap
-
-Without this skill, a reader who cannot follow a dense answer has to ask for it again in ordinary words, and the second answer is drafted by the same session that produced the first. Nothing tells that session which half of its own text carried the decision, so the rewrite shortens the passage and keeps the abstraction that made it hard to read.
-
-The corpus around it covers the neighboring jobs and not this one. `write-human` governs a passage being drafted or revised and arrives on a markdown edit, so it never sees an answer in chat and never reaches a document nobody is editing. `canon markdown audit` reports sentence spread and repeated openings against a stated range, which measures how a passage moves and says nothing about whether a reader can act on it.
-
-A restatement also fails in a way a rewrite does not. A run that compresses by dropping what supports a claim leaves a reader who acts on the plain version and meets a different answer in the source, and that failure is invisible in the restatement itself.
-
-## Must
-
-- Take a named markdown path or the preceding answer, resolving the path first, since a reader pointing at a file has already said which one they mean
-- Keep every point that changes a decision and cut what only supports one, which is the split that separates a restatement from a summary
-- Preserve a hedge the source carries, since dropping it manufactures a certainty
-- Cite the carrier of the rhythm and density rules rather than restating them, because a second copy drifts with nothing comparing the two
-- Fire on an explicit request and refuse the model's own judgment about its own output
-
-## Must not
-
-- Write a file. A restatement is read once to reach a decision, and a file makes a record nobody opens twice.
-- Add a fact, number, or name the source does not carry
-- Restate the voice, rhythm, or density rules, which live in the skill this body cites
-- Claim the restatement is verified. Nothing checks whether a plain version kept the deciding half, so the sandbox arm asserts what the run did rather than that the output is good.
-
-## Guards
-
-- A named path that does not resolve stops the run rather than falling back to the preceding answer, since the two inputs are different requests
-- A request with no path and nothing preceding it stops rather than restating the request itself
-
-## Out of scope
-
-- Drafting or revising a passage, which is `write-human` on a markdown edit
-- Measuring cadence in finished output, which `canon markdown audit` reports from package data
-- Rewriting a document into a file, which is a proposal against the source rather than a restatement of it
-- The banned characters, which `markdown.md` states and the audit gates

package/claude/skills/restate-plainly/SKILL.md

@@ -1,41 +0,0 @@
----
-name: restate-plainly
-description: Restates a dense answer or a named markdown document in plain language, cutting jargon and keeping only what changes a decision. Use when asked to "restate that in plain language", "say that plainly", "what does this actually mean", "cut the jargon", "give me the plain version", or "restate this document". Do NOT use to draft or revise prose, which is `write-human`, and do NOT fire on the model's own judgment that its own output was dense.
-metadata:
-  family: answer
----
-
-# Restate plainly
-
-Return the plain version of something already written. The reader asked because they stopped to decode rather than to decide, so the restatement earns its place by getting them to the decision.
-
-## What to restate
-
-- Restate the file when the request names a markdown path, and the preceding answer in the conversation when it names none. A named path wins over an answer sitting in the same turn.
-- Stop when the request names a path that does not resolve: `❌ No file at <path>. Name a path that exists, or ask for the preceding answer instead.`
-- Stop when nothing precedes the request and no path is named: `❌ Nothing to restate. Name a markdown path, or ask right after the answer you want in plain words.`
-- Refuse a request to restate output on the model's own initiative. A person asks for this by name.
-
-## What survives
-
-- Keep every point that changes a decision, and cut every point that only supports one. A reader who acts on the restatement and is surprised by the original has been given the wrong half.
-- Name the thing the source names. Replace a term of art with its plain equivalent, and keep the term where the reader has to search for it later.
-- Say what is uncertain where the source hedges, and say it plainly. Dropping a hedge invents a certainty the source does not carry.
-- Introduce no fact, number, or name the source lacks. A restatement changes wording and never claims.
-- Report the reasoning, not the metaphor. An abstraction standing in for a mechanism is what made the source dense.
-
-## How it reads
-
-Load the `write-human` skill before writing the restatement. Compression is where a plain version turns into a list of verbless fragments, and that skill states the rhythm and density rules this one does not copy.
-
-## Output
-
-Answer in chat. Write no file, since a restatement is read once to reach a decision.
-
-Lead with the plain version in prose. Close with one line naming what was cut and why, so the reader can go back for it:
-
-```plaintext
-Cut: <what left, and why it changes no decision>
-```
-
-Name the source path on its own line when the restatement came from a file.

package/claude/skills/review-branch/REQUIREMENT.md

@@ -1,40 +0,0 @@
----
-name: review-branch
-description: What local review is for, the gaps it closes, and why it reports without fixing
----
-
-# Review branch requirement
-
-## Gap
-
-Without this skill, a branch ships on the confidence of the session that wrote it. Review happens in chat and evaporates, so the ship step has no receipt to gate on. What review does happen mixes style opinion with real defects at one severity, and a reader cannot tell which blocks the merge. Worst, a diff that resolves empty against a stale base reports a clean branch instead of admitting the skill could not see the work.
-
-## Must
-
-- Read the project's own context before the diff, so a decision already settled is not reported as a defect
-- Resolve the base ref once, preferring the remote over local `main`, and reuse it in the guard and the read
-- Say when the baseline is unusable and name the narrowed scope, rather than letting a clean summary read as a clean branch
-- Flag only what will cause incorrect behavior or break a documented rule
-- Apply `canon:review-craft`'s axes and evidence bar, rendered output included, rather than carrying an axis list of its own
-- Grade every finding, since the caller gates on the counts rather than on the prose
-- Write the report to disk under a branch-derived slug, so what the ship step reads outlives the session
-
-## Must not
-
-- Fix, rewrite, or suggest a refactor outside a finding. Reporting is the whole job.
-- Flag style, linter territory, or anything resting on unverified state. A false positive erodes trust in the pass.
-- Substitute the whole tree for a missing baseline
-- Repeat the full report in chat. The file is the report and a chat copy of it goes stale immediately.
-- Stage or commit the receipt, which is gitignored scratch
-- Auto-trigger on a vague signal. Require an explicit request or a pipeline invocation.
-
-## Guards
-
-- The staged set, the branch set, and the working set are all empty: stop with a pass
-- Baseline unusable: continue on the uncommitted set and lead the report with the warning
-
-## Out of scope
-
-- Reviewing an open pull request, which `review-pr` owns. The split is by vantage: this one reviews local work for the session that wrote it and writes to disk.
-- Deciding whether the findings block the ship. This skill grades and the caller gates.
-- Fixing anything it found, which `review-address` owns once the work is on a pull request

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

@@ -1,137 +0,0 @@
----
-name: review-branch
-description: Reviews all changes since main for bugs, edge cases, and logic flaws. Reads CLAUDE.md, REQUIREMENTS.md, and ARCHITECTURE.md for context, then applies a structured review to the full diff and outputs a findings report. Coding standards from `.claude/rules/` are auto-loaded by Claude Code. Use when asked to review changes, run a code review, or check the current branch. Do NOT auto-trigger on vague signals like "looks good" or "can you check this". Require an explicit review request or an autoship invocation.
-metadata:
-  family: check
----
-
-# Review branch
-
-## Guards
-
-- Resolve the base ref first, per Diff baseline below. If `git diff <base>` and the untracked listing are both empty, stop: `✅ No changes to review.` Those two are the sets Step 2 reads, and the range already carries the staged and the unstaged work the guard used to test on its own. A guard reading bare local `main` stops the skill on `main` before it ever reaches Step 2.
-
-## Diff baseline
-
-Resolve the base ref once and reuse it in the guard and in Step 2:
-
-```bash
-git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null
-```
-
-Prefer `origin/main` over local `main`. On `main` itself the local ref resolves to HEAD, so every committed change drops out of the set and the skill reports a clean branch rather than admitting it cannot see the work.
-
-The baseline is unusable in one case: no merge base resolves against either ref. Substitute `HEAD` and lead the report with `⚠ Baseline unusable. Reviewed the uncommitted set only.`, so a clean summary is never read as a clean branch. That substitution costs the committed half, because `git diff HEAD` reaches the staged and the unstaged work and nothing behind it.
-
-The base equalling HEAD is a usable baseline rather than the second case it used to be. It means nothing is committed ahead of the base, which is the ordinary shape on `main` and on a feature branch before its first commit, and `git diff <base>` degenerates there to `git diff HEAD` and reads the branch whole. Warning on it would tell a reader their review was partial when it had covered everything.
-
-## Step 1: read context
-
-Read these in parallel from the project root, skipping any that do not exist:
-
-- `CLAUDE.md`: project type, conventions, and commands
-- `canon/REQUIREMENTS.md`: feature scope and non-goals
-- `canon/ARCHITECTURE.md`: technical design decisions
-
-Coding standards from `.claude/rules/` are auto-loaded by Claude Code. Always-on rules apply every session. Path-scoped rules apply to files matching their `paths:` glob.
-
-## Step 2: get the diff and changed files
-
-Resolve the base ref per Diff baseline above, then run these in parallel from the project root:
-
-```bash
-git diff <base>
-```
-
-```bash
-git diff --name-only <base>
-```
-
-```bash
-git ls-files --others --exclude-standard
-```
-
-Use `git diff <base>` as the diff scope. It compares the base against the working tree, so the committed, staged, and unstaged halves arrive in one range and no selection between them is made. Take the file list as the name-only output plus the untracked listing, which covers a file git has never tracked and therefore no diff can reach.
-
-When the baseline is unusable, substitute `HEAD` for `<base>` in both diff commands. Never substitute the whole tree for a missing baseline.
-
-## Step 3: read changed files
-
-Read each file from the changed file list. Skip deleted files. Run reads in parallel.
-
-## Step 4: review and persist
-
-Invoke `canon:review-craft` before reading the diff for findings, whatever the diff's size. It carries what to look for and the evidence bar, rendered output included, and this step carries no axis list of its own to fall back on. Report it rather than proceeding silently when the skill does not resolve.
-
-Review the full diff and changed file contents for:
-
-1. Every axis `canon:review-craft` states, held to its evidence bar
-2. Violations of rules from `.claude/rules/` that apply to the changed files
-3. When the diff touches a file this project ships to a target holding none of its own history: a repository-relative path, a phase label naming a gitignored board, a same-repository pull request or commit reference, or a layout, stack, or config-path claim true of this checkout but stated as if it were general
-
-Use `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`, and the auto-loaded `.claude/rules/` as project context to inform what is intentional vs problematic. Do not fix, rewrite, or suggest refactors outside the scope of a finding.
-
-### High-signal filter
-
-Flag only issues that will definitely cause incorrect behavior or break a documented rule. Skip:
-
-- Code style or quality concerns
-- Subjective suggestions
-- Linter territory
-- Issues that depend on unverified state
-
-A comment that makes a false claim about the code is a correctness finding, not a style one. Flag it past the exclusions above and let the severity ladder rank it.
-
-If uncertain, do not flag. False positives erode trust.
-
-### Severity
-
-- **critical**: blocks the feature. Broken in production if shipped.
-- **should-fix**: fix in same session while context is fresh. Not a blocker.
-- **minor**: not worth fixing now. Include for visibility.
-
-### Report format
-
-Start with a summary line. Group findings by file. Within each file, list findings sorted by severity (critical first, then should-fix, then minor). Omit files with no findings.
-
-```markdown
-X critical, Y should-fix, Z minor across N files.
-
-File: path/to/file.ext
-
-- **critical**: finding
-- **should-fix**: finding
-- **minor**: finding
-
-File: path/to/other.ext
-
-- **critical**: finding
-- **minor**: finding
-```
-
-If nothing is wrong, use: `✅ No findings.`
-
-### Persist
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
-
-Write the full report directly to `.canon/review/branch-<slug>.md` at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does. Create the directory if it does not exist. Always overwrite.
-
-The report is a main-root write, so it goes out as a heredoc, routed the way `session-worktree` states.
-
-If there are no findings, write `✅ No findings.` to the file with a timestamp.
-
-The `.canon/review/` directory is gitignored. Do not stage or commit the file.
-
-The report is disposable. It outlives the ship chain that reads it, and `context-fold` sweeps it once the branch it names is gone, because the durable record of what a review found is the comment `review-pr` posts on the pull request. A review run on a branch that never opens one leaves nothing behind once that branch is gone, so fold anything worth keeping into the pull request body or a task finding while the report is still on disk.
-
-### Chat output
-
-Output only the summary line and the file path. Do not repeat the full report in chat.
-
-```plaintext
-X critical, Y should-fix, Z minor across N files.
-📝 Wrote .canon/review/branch-<slug>.md
-```
-
-If no findings: `✅ No findings. Wrote .canon/review/branch-<slug>.md`

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

@@ -1,45 +0,0 @@
----
-name: seed-sync
-description: Scope boundary for section-granular seed reconciliation against the bulk install and sync commands
----
-
-# Seed sync requirement
-
-## Gap
-
-Without this skill, a project that edited a seed has no way to take an upstream change without losing something. No `canon` command touches a seed at all, so the only route is a hand copy that overwrites the file and takes the edits with it, unrecorded. Nothing can deliver one upstream section into a file the project has customized, which is the case a grown project is always in.
-
-A whole-file diff does not close it either. It cannot separate a section the user rewrote on purpose from a section the toolkit moved on without them, so the choice reaches the user as accept everything or lose everything, and the safe answer is always to skip.
-
-Naming the bulk command carries a failure of its own. This skill decides which files the bulk sync should take and then hands that command over without stating what it does to them, and the boundary line below names the reference holding that answer where no session reads it. Claude Code loads the skill entry alone, so a sibling named here reaches nobody.
-
-Two failures belong to the audit rather than to the diff. A decision taken in chat dies with the session, so an audit half applied cannot be resumed and the second run starts over. And a file the toolkit generates rather than ships, such as an index rebuilt from sibling frontmatter, is absent from every source catalog by design, so a naive comparison reports it as a local addition and invites the user to reconcile something nothing owns.
-
-## Must
-
-- Read seed content from the CLI rather than holding a copy, so the audit and the install cannot disagree
-- Diff per section, treating the preamble as a section of its own
-- Separate a customized section from a stale one by reading the attribution the drift report records, not by how the section looks, and default the customized one to no action
-- Fall back to appearance only when attribution is unavailable, and mark every verdict reached that way as unverified
-- Leave a file the report proves untouched to the bulk sync that owns it, rather than auditing what carries no edits
-- Route to the overwrite contract from the body, at the point the bulk command is named, since the boundary below is read by an author and never by a session
-- Persist the proposal and every decision to a review file that stays the source of truth across re-pings
-- Apply one section at a time, never by rewriting a file
-
-## Must not
-
-- Propose removing a section present only in the target. Those are the customizations the skill exists to preserve.
-- Write a target file before a decision is recorded against the item
-- Read an empty decision slot as consent
-
-## Guards
-
-- No `canon` on PATH, or no `.claude/` directory at the project root, stops before any read
-
-## Out of scope
-
-- Bulk install and sync of a whole domain, which `canon <domain> install` and `canon <domain> sync` own and `canon-cli` documents. Reach for this skill when the target holds edits worth keeping, and for those commands when it does not.
-- Golden configs, which overwrite by design and carry no section structure to diff
-- Governance rules: `canon gov sync`
-- First-time scaffold of a project that has installed nothing yet: `target-setup`
-- Public `README.md` and `docs/` prose: `docs-sync`

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

@@ -1,158 +0,0 @@
----
-name: seed-sync
-description: Audits a project's installed Claude seed docs against the toolkit's current seed source and proposes per-section edits without overwriting customizations. Use when asked to "sync seeds", "update my seeds", "check seed drift", "did the toolkit seeds change", or when reconciling `CLAUDE.md` and `.claude/` preambles after an upstream toolkit update.
-metadata:
-  family: upkeep
----
-
-# Seed sync
-
-Surfaces drift between the toolkit's current seed docs and what was installed in this project, then proposes targeted edits. The CLI emits seed content. This skill diffs, reasons, and writes the proposal to a review file. It does not write target files until the user confirms.
-
-## Guards
-
-- If the `canon` CLI is not on PATH, stop: `❌ canon CLI not found. Install the toolkit first.`
-- If no `.claude/` directory exists at the project root, stop: `❌ No .claude/ directory found. Run canon claude init first.`
-
-## Step 1: read toolkit sources and the drift report
-
-Run both in parallel from the project root:
-
-```bash
-canon claude seeds list --json 2>/dev/null
-canon sync --check . --json 2>/dev/null
-```
-
-Seeds emit an array of `{name, source, target, content}`, where `target` is the path relative to the project root where the file installs.
-
-Seeds are the whole subject. No standard installs into a project, so there is no installed copy to audit and nothing to reconcile against the corpus. A standard a session needs is read with `canon standards <name>`, which resolves against the copy inside the package.
-
-### Narrow the set by attribution
-
-The report is what separates a file the project edited from one the toolkit moved on without it. Read `seeds.entries` for seed paths.
-
-Keep every seed regardless of state. `CLAUDE.md` is the file a project edits most, and its `drifted` verdict is the case this skill exists for.
-
-Read the `canon-cli` skill before naming a sync command in the output. It states which surfaces a sync overwrites, merges, or writes once.
-
-Fall back to the appearance heuristic in step 3 when the report cannot attribute, which is `historyUnavailable` set on the relevant section or the command failing outright. Say so in the summary block, because a fallback audit reports guesses rather than facts.
-
-## Step 2: read installed copies
-
-For each entry in the merged list, read the file at its `target` path from the project root. Run reads in parallel.
-
-Mark missing files for **Add** treatment. Skip non-text seeds (`.json`) for section diffing. Record a one-line note in the scope table that the user can compare manually.
-
-When detecting target-only files for `local-only` flagging, skip files the toolkit's own walkers regenerate from sibling frontmatter (today: any `index.md` produced by `canon indexes regen`). They are absent from source catalogs by design, so flagging them as `local-only` is a false positive.
-
-Note on `settings.json`: the seed now ships only the PostToolUse hook block. If a target project's `.claude/settings.json` carries `attribution` or `permissions` keys, those are stale: the user-level `~/.claude/settings.json` (installed via `canon claude setup`) owns them now. Flag those keys in the scope table for removal rather than diffing them as content drift.
-
-## Step 3: diff per section
-
-For each seed file present in both sides, parse the body into a preamble (everything between H1 and the first H2) plus one part per `##` header, then compare part by part. Treat the preamble as a single unit with the same verdicts as a section. Use `(preamble)` as its label in the proposal.
-
-- **Identical:** ignore.
-- **Toolkit-only section** (present in source, absent in target): candidate to **Add**. Number it whatever the file's own verdict is. The verdict rules below govern a section present in both, and a section the project never had cannot be the customization a `drifted` file is being credited with. A pass that reads the file-level verdict first proposes nothing on a target missing eleven sections, which is the shape this bullet exists to catch.
-  - A deliberate removal reads the same as one that never arrived, and no decline is carried between runs, so a section the user skips is proposed again on the next branch. Say so beside the item rather than letting a reader meet it a third time wondering. The way to settle it for good is to keep the heading and write the project's own content under it, which moves the section onto the drifted path below, where the customization rule protects it and stops numbering it.
-- **Target-only section** (present in target, absent in source): preserve, never propose removal. These are user customizations.
-- **Drifted section** (present in both, content differs): candidate to **Update**.
-  - Read the file's verdict from the report rather than judging it by eye. `drifted` means the content matches no version the toolkit ever published, so the project wrote it: call it **Customized**, default to skip, record in the scope table only, never numbered.
-  - `stale` at the file level means the toolkit moved and the project did not, so any section differing inside it is **Stale**. Default action: propose update.
-  - Only when the report could not attribute the file, judge by appearance: a version carrying extra bullets, project-specific paths, or filled-in placeholders reads as **Customized**, and one reading like the original toolkit text reads as **Stale**. Mark every verdict reached this way as unverified in the proposal.
-
-The user judges intent. The skill makes the judgment legible.
-
-### Absorbed-already check
-
-Before proposing an Update, grep the target section for the seed text's keywords. If the rule is already implied by an adjacent bullet in the target version, drop the proposal and record the section as `in sync` in the scope table.
-
-## Step 4: write the proposal to the review file
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
-
-Write the full proposal to `.canon/review/seed-audit-<slug>.md` at the main worktree root. Do not print the proposal inline.
-
-The proposal is a main-root write, so it goes out as a heredoc, routed the way `session-worktree` states.
-
-Structure: a summary block at the top, a legend, a scope table, then one H2 per numbered item. Number items across all files so the user can reference them by number. Fuse the status, action, and target into each H2. Every item starts as 📝 pending.
-
-````markdown
-# Seed audit: <slug>
-
-**Pending:** <all numbers>
-
-Legend: ✅ applied · ⏭ skipped · 📝 pending
-
-How to respond: fill in `Decision:` per item (`apply` or `skip`), then ping. Chat shortcut: `all`, `none`, or a list of numbers.
-
-## Scope
-
-Mark target-only files (present in target, absent in source) as `local-only` and leave them untouched.
-
-| Source | File       | Status     | Note                         |
-| ------ | ---------- | ---------- | ---------------------------- |
-| seed   | `<target>` | diffed     | <counts>                     |
-| seed   | `<target>` | in sync    |                              |
-| seed   | `<target>` | skipped    | non-text, compare manually   |
-| seed   | `<target>` | customized | <section> skipped by default |
-| seed   | `<target>` | local-only | not in toolkit, preserved    |
-
-## 1. 📝 Update → `<target-path>` / <section>
-
-Why: <one-line reason>
-
-``​`diff
-
-- <project line removed>
-  <unchanged context line>
-
-* <seed line added>
-  ​```
-
-Decision:
-
-## 2. 📝 Add → `<target-path>` / <section>
-
-Why: <one-line reason>
-
-``​`diff
-
-- <seed section body, each line prefixed with +>
-  ​```
-
-Decision:
-````
-
-Update items show both sides in one `diff` block: removed lines from the project version with `-`, added lines from the seed version with `+`, unchanged context lines without a prefix. Add items show only `+` lines. Customized sections appear in the scope table only, never numbered. A file with no drift still appears in the scope table as `in sync`.
-
-After writing, tell the user `✅ Wrote proposal to .canon/review/seed-audit-<slug>.md`. Ask them to fill in `Decision:` per item, then re-ping or use the chat shortcut.
-
-Rewrite the review file in place whenever the proposal changes mid-review. The file stays the source of truth for the current decisions.
-
-## Step 5: apply
-
-Re-read the review file as source of truth. For each item, parse `Decision:`:
-
-- `apply` (or affirmative): run the `Edit`, flip emoji to ✅.
-- `skip`: leave the target section as-is, flip emoji to ⏭.
-- `defer` or empty: leave 📝 pending, no action.
-- Contains `?` or unrecognized verb: leave 📝 pending, no action.
-
-Chat shortcut: the user replies with `all`, `none`, a comma-separated list of numbers, or `skip <nums>`. Write the matching verb into the `Decision:` slot of every item the reply names, `apply` for `all` or a bare list and `skip` for a `skip` reply, then run the parse above against the file. A reply of `none` writes nothing. A slot the reply does not name keeps its own value, so the receipt stays the source of truth and an empty slot still means take no action.
-
-Apply edits one at a time via `Edit`, replacing one section at a time. Never rewrite a whole file. Claude Code's tool permission dialog is the confirmation gate per edit.
-
-As each item resolves, update its status in the review file: flip the H2 emoji from 📝 to ✅ for applied or ⏭ for skipped. Refresh the summary block counts at the top. Do not delete the review file. It stays as a receipt until the next `seed-sync` run overwrites it or the user clears it.
-
-## After completion
-
-Output one line per action taken:
-
-- `✅ Updated: <target-path> / <section>`
-- `⏭ Skipped: <target-path> / <section>`
-
-End with a one-line bucket summary: `✅ Applied: <nums> | ⏭ Skipped: <nums> | 📝 Pending: <nums>`. Omit empty buckets. If anything is pending, remind the user they can fill in a `Decision:` and re-ping, or commit a skip with `skip <nums>` in chat.
-
-If the user accepted nothing, output:
-
-`✅ No changes applied.`

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

@@ -1,38 +0,0 @@
----
-name: sketch-design
-description: Why a greenfield design value needs a render behind it before it reaches DESIGN.md, and where the reference loop stops short of writing that file itself
----
-
-# Sketch design requirement
-
-## Gap
-
-Without this skill, a session asked to match a look an operator has in mind either invents token values from a personality paragraph alone, which is what `design-extract`'s greenfield path already does and states plainly as a proposal rather than a fact, or builds a one-off render-and-pick comparison by hand for each request, restating `draft-and-pick`'s candidate page, hand-off, and pick mechanics from scratch with nothing comparing the copy to the shipped one. Neither path lets an operator point at a reference image or a live page and have the values that follow trace back to what was actually looked at and picked.
-
-## Must
-
-- Take at least two operator-supplied references, each a path to an image on disk or a URL to render, and gather them through this skill's own Step 1 prompt rather than a caller-supplied argument
-- Render every URL reference before drafting, and report a capture refusal naming an unrecognized source as a version gap rather than a broken reference
-- Follow `draft-and-pick`'s candidate page, render, hand-off, structured pick, and archival capture mechanics rather than restating them
-- Trace the picked reference's color, type, and spacing by reading its render, and carry the operator's own stated reason for the pick forward as written
-- Write the handoff one field per line, grouped under the section names `standards/design.md` already fixes for `canon/DESIGN.md`, so `design-extract` can read it mechanically
-- Resolve the handoff file and the archival capture against the main worktree root, never against a linked worktree this run happens to be building in
-
-## Must not
-
-- Write to `canon/DESIGN.md`. Tracing values into the handoff is this skill's whole output. Filling the design document from them is `design-extract`'s Step 2, kept as the one place that file is written.
-- Take the pick on the operator's behalf. That call is theirs on every arm that is defensible, the same boundary `draft-and-pick` states for itself.
-- Restate `draft-and-pick`'s render, hand-off, pick, or loop mechanics, or `canon capture`'s render mechanics
-- Assume this skill's own invocation frequency needs no check. `design-extract` Step 1 points to it as the first move on the greenfield path, and an operator can also type its name directly, so whether anything else reaches for it has an answer only after a review pass reads usage back, rather than at creation time.
-
-## Guards
-
-- `canon` not on PATH: stop, since the render loop and the capture calls both need it
-- Fires on a direct request or on `design-extract`'s own pointer, never on the model's own read that a project could use a design direction
-
-## Out of scope
-
-- `design-extract` reads the handoff this skill writes and fills `canon/DESIGN.md` from it. That fill, and the seed template it starts from, stay entirely that skill's own.
-- `draft-and-pick` owns the render, hand-off, pick, and loop mechanics this skill invokes rather than reimplements
-- `canon capture` and `canon serve` own the render and the address mechanics
-- Auditing an implemented UI against its tokens, which `ux-audit` owns

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

@@ -1,94 +0,0 @@
----
-name: sketch-design
-description: Runs a reference-and-pick loop against operator-supplied images and URLs, then writes the picked reference's traced color, type, and spacing values to a handoff file `design-extract` reads. Use when asked to "sketch a design direction", "compare these reference sites", "pick a look before we build DESIGN.md", "show me a few design directions", or as the first move on `design-extract`'s greenfield path when nothing has been rendered yet. Do NOT use when a value is already anchored to running code or a stylesheet, which is `design-extract`'s source path, or to draft the design system document itself, which stays `design-extract`'s job.
-metadata:
-  family: setup
----
-
-# Sketch design
-
-`design-extract`'s greenfield path proposes color, type, and spacing from a personality paragraph alone, with no render behind any value. This skill puts operator-supplied references in front of a render instead, so the values `design-extract` fills are traced to a picked reference rather than invented from prose.
-
-## Guards
-
-- If `canon` is not on PATH, stop: `❌ canon CLI not found.`
-- Draft no comparison for a reference set the operator has not supplied. This skill fires on a direct request or on `design-extract` pointing at it, never on the model's own read that a project could use one.
-
-## Step 1: gather the references and render what needs it
-
-Ask the operator, in this step's own prompt, for the references to compare: a path to an image already on disk for each one already rendered somewhere, and a full URL for each live page to render. Take at least two.
-
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Step 1 items 2 through 5 to name the decision and derive `<dest>`, with the decision fixed rather than derived: "which of these references the project's design should draw from." Arm 0 is the current state when `canon/DESIGN.md` already carries filled Color, Typography, or Spacing cells. Arms start at 1 otherwise, since a greenfield project asking for this loop has nothing shipped yet to anchor a baseline arm against.
-
-Render every URL reference before drafting, one call per reference since each targets its own file:
-
-```bash
-canon capture <url> --selector body --out <dest>/refs/arm-<id>.png
-```
-
-`--selector body` is the right choice here, unlike inside `draft-and-pick`'s own arms: the page belongs to someone else, so nothing on it is a wrapper this skill can name, and a full-page render is what a reference comparison needs. An operator-supplied image needs no render. Reference it directly from `<dest>/refs/` by copying it there under the same `arm-<id>` naming, so every arm resolves through one path shape regardless of source.
-
-`canon capture <url>` reaches a target only once a release ships the URL-source capability. Report a refusal naming an unrecognized source as that gap rather than a broken reference, and name upgrading the installed `canon` as the repair.
-
-## Step 2: author the candidate set as one page
-
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Step 2, with one substitution: each arm is an `<img>` of the file `<dest>/refs/arm-<id>.png` produced in Step 1, not markup drafted from scratch. Wrap each in the shared class that skill's Step 2 fixes, label it with its id and its cost, and inline everything else the page needs, per that step's rules.
-
-## Step 3: render, hand off, and take the pick
-
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Steps 3 and 4 unchanged: render the combined page, hand over the address, and put the choice to the operator through the structured question surface. Take whatever reason the operator's answer already states, whether through the surface's own free-text escape or in the surrounding turn, as the reason Step 5 records. The surface takes the pick and the reason in one turn when the operator gives both together, rather than needing a second one.
-
-## Step 4: loop, when the operator asks for a change
-
-The arms here are fixed references rather than drafted markup, so nothing about a picked arm's own content can be revised. A loop here narrows the set instead: drop an arm the operator rules out, or add a new reference by returning to Step 1 for it alone. Return to Step 2 with the adjusted set and repeat Step 3. Stop when the operator says the pick is right, the same rule `draft-and-pick` Step 5 states, never when the set stops changing.
-
-## Step 5: trace and write the handoff
-
-1. Carry forward the reason Step 3's pick already stated, as written rather than paraphrased. Ask the operator to state, in their own words, why the picked reference won only when the pick arrived with no reason attached.
-2. Read the picked arm's render at `<dest>/refs/arm-<id>.png` and trace its color, type, and spacing by looking, the same reading a person does against a screenshot. Name a role only where the reference actually shows it. Leave one out rather than guessing.
-3. Write `.canon/picks/<slug>/design-handoff.md`, resolved against the main worktree root rather than the linked worktree this run may be building in, since shared session scratch always resolves there. One field per line, grouped under the section names `${CLAUDE_SKILL_DIR}/../../standards/design.md` fixes, so `design-extract` reads it mechanically:
-
-   ```markdown
-   # Design handoff
-
-   Picked: arm-<id> (<label>)
-   Reason: <the operator's own sentence from item 1>
-
-   ## Color
-
-   - <role>: <hex>
-
-   ## Typography
-
-   - <role>: <family>, <size>
-
-   ## Spacing
-
-   - base unit: <value>
-
-   ## Borders
-
-   - <role>: <radius>, <width>
-   ```
-
-   Write only the sections and roles the trace actually names. A role or a whole section with nothing traced is left out rather than written empty, since `design-extract` Step 2 treats an absent line as untraced and an empty one as a claim about the source.
-
-4. Batch-capture the final round's arm files, the same directory-batch convention `draft-and-pick` Step 6 uses: `canon capture <dest>/arms --selector <wrapper-class> --out .canon/picks/<slug>/`, naming Step 2's chosen class, so every arm considered, not only the winner, survives past the pick as a revert record.
-5. Delete `<dest>` and everything in it, now that the handoff and the arms both sit at the durable path above. Report the path as still standing when the delete is refused, rather than closing on a report the tree contradicts.
-
-## Response format
-
-```plaintext
-📝 Wrote .canon/picks/<slug>/design-handoff.md
-📝 Wrote .canon/picks/<slug>/arm-<id>.png (and every other arm considered)
-
-Picked arm-<id>: <label>. Run /canon:design-extract to fill canon/DESIGN.md from the trace.
-```
-
-## What this delegates
-
-Cite these rather than restating them. A step reimplemented here rots against the skill that owns it.
-
-- `draft-and-pick` owns the candidate page, the render and hand-off, the structured pick, and the archival capture convention, cited above
-- `design-extract` reads the handoff file this skill writes and fills `canon/DESIGN.md` from it. This skill never writes that file itself.
-- `canon capture` owns the render mechanics, including the URL source and its font refusal