@erclx/canon 5.30.0 → 5.32.0

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}/../../standards/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}/../../standards/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.
-```

package/claude/skills/draft-and-pick/references/frame.html

@@ -1,118 +0,0 @@
-<!doctype html>
-<html lang="en" data-theme="light">
-  <head>
-    <meta charset="utf-8" />
-    <title>Draft and pick frame</title>
-    <style>
-      :root {
-        --bg: #f4f4f5;
-        --fg: #18181b;
-        --bar: #ffffff;
-        --line: #d4d4d8;
-      }
-      :root[data-theme='dark'] {
-        --bg: #18181b;
-        --fg: #f4f4f5;
-        --bar: #27272a;
-        --line: #3f3f46;
-      }
-      * {
-        box-sizing: border-box;
-      }
-      body {
-        margin: 0;
-        height: 100vh;
-        display: flex;
-        flex-direction: column;
-        background: var(--bg);
-        color: var(--fg);
-        font-family: system-ui, sans-serif;
-        font-size: 14px;
-      }
-      header {
-        display: flex;
-        gap: 12px;
-        align-items: center;
-        padding: 8px 12px;
-        background: var(--bar);
-        border-bottom: 1px solid var(--line);
-      }
-      select,
-      button {
-        font: inherit;
-        color: inherit;
-        background: var(--bg);
-        border: 1px solid var(--line);
-        border-radius: 4px;
-        padding: 4px 8px;
-      }
-      main {
-        flex: 1;
-        overflow: auto;
-        display: flex;
-        justify-content: center;
-        padding: 12px;
-      }
-      iframe {
-        width: 100%;
-        height: 100%;
-        border: 1px solid var(--line);
-        background: #fff;
-      }
-    </style>
-  </head>
-  <body>
-    <header>
-      <label
-        >Page
-        <select id="picker"></select
-      ></label>
-      <button id="theme" type="button">Theme: light</button>
-      <span>F12 device toolbar to resize</span>
-    </header>
-    <main><iframe id="page" title="Candidate page"></iframe></main>
-    <!-- The skill replaces the token below with one JSON object: {"themeKey": "<key the arms read>", "rounds": [{"label": "...", "pages": [{"label": "...", "src": "<path relative to this file>"}]}]} -->
-    <script type="application/json" id="frame-data">
-      __FRAME_DATA__
-    </script>
-    <script>
-      const data = JSON.parse(document.getElementById('frame-data').textContent)
-      const picker = document.getElementById('picker')
-      const themeButton = document.getElementById('theme')
-      const frame = document.getElementById('page')
-      let theme = 'light'
-
-      for (const round of data.rounds) {
-        for (const page of round.pages) {
-          const option = document.createElement('option')
-          option.value = page.src
-          option.textContent = round.label + ' · ' + page.label
-          picker.append(option)
-        }
-      }
-
-      // A page that stores its own theme and reads it back on load overwrites the
-      // attribute alone, so write the stored key as well as the attribute.
-      function applyTheme() {
-        document.documentElement.dataset.theme = theme
-        themeButton.textContent = 'Theme: ' + theme
-        try {
-          const win = frame.contentWindow
-          win.document.documentElement.setAttribute('data-theme', theme)
-          win.localStorage.setItem(data.themeKey, theme)
-        } catch {}
-      }
-
-      picker.addEventListener('change', () => {
-        frame.src = picker.value
-      })
-      themeButton.addEventListener('click', () => {
-        theme = theme === 'light' ? 'dark' : 'light'
-        applyTheme()
-      })
-      frame.addEventListener('load', applyTheme)
-
-      if (picker.options.length > 0) frame.src = picker.value
-    </script>
-  </body>
-</html>

package/claude/skills/draft-doc/references/wireframes.md

@@ -1,48 +0,0 @@
----
-title: Wireframes kind
-description: The root check, tree-walk guard, tier detection, transcription and role-intent modes, and regen folder for a brand-new wireframe surface, read by draft-doc once the request resolves to the wireframes kind
----
-
-# Wireframes kind
-
-`draft-doc` reads this file when the request resolves to a surface under `canon/wireframes/`. An existing surface is edited directly, since no skill owns a full rewrite of one.
-
-This kind stays independent of `context-fold`'s wireframe coverage sweep, which writes only a bare `TODO` stub for a surface a diff touched and reports drift against one a wireframe already covers. Neither the stub nor the drift check is a draft, and this kind never reads or writes through that mechanism.
-
-## Root
-
-A project the surface move has not reached keeps its wireframes folder under `.claude/` rather than `canon/`. Walk and write at whichever root already carries the folder, and create it under `canon/` only when neither does, since a new `canon/` folder would hide every surface the old one holds. `<wireframes-root>` below names the root this check settled.
-
-## Guards
-
-- Derive a kebab-case slug from the surface. Walk the whole `<wireframes-root>` tree, including a surface nested inside a grouped subfolder, rather than checking the top level alone. A match at any depth means the surface already has a file. Stop: `❌ <path> already covers this surface. Edit it directly; this skill only drafts a surface with no file yet.`
-
-## Placement
-
-- Check every title and description in `<wireframes-root>/index.md` against the surface, and stop the same way on a match.
-- Place the file at `<wireframes-root>/<slug>.md`, or inside a grouped subfolder only when the surface belongs beside siblings that already share one.
-
-## Tier detection
-
-- Read `canon/DESIGN.md` and every existing wireframe file for a tier signal: an Excalidraw or Figma reference, or a marker naming one of them.
-- Always draft the regions-and-states shape regardless of what is detected, since that is the only shape any shipped mechanism produces. Report a higher tier rather than attempting a companion render for it.
-- Default silently to tier 0 when nothing is detected.
-
-## Draft
-
-- Decide the mode before drafting. When the surface names an already-built component or file, open that source and draft in transcription mode, citing the render function, the stylesheet rule, or the built file each region and label traces to, per the standard's Transcription-wireframes section.
-- Draft in role-intent mode otherwise: label each region by its role, never by a class name or a token value.
-- Draft `title` and `description` frontmatter, then a lead paragraph naming what the surface is for and what it covers, then `## Regions` as a bullet list naming every region and where it sits relative to the others.
-- Draw an ASCII `plaintext` fence with `←` role annotations only when the layout is not built yet. Skip the fence in transcription mode, which already cites the built source instead.
-- Draft `## States` as a table listing every state a visitor can reach, what reaches it, what it shows in words, and its evidence folder, reading `not captured` in the evidence cell until a capture lands.
-- Follow with `## Copy`, `## Behavior`, and `## Not on this surface`, against the standard's template.
-- Give a layout that changes across a breakpoint or state its own entry in the regions list, named by what triggers it, never for a spacing difference alone.
-- Leave out algorithms, event-handler code, framework prop or class names outside transcription mode, and anything else the standard sends to a context entry instead.
-
-## Preview
-
-Add `**Detected tier:** <tier-0 | tier-1 | tier-2 | none detected>` and the mode, and confirm both with the path, since each is a judgment call.
-
-## Write
-
-Run `canon markdown audit` against the prose outside the fenced block. Regenerate `<wireframes-root>`, so the surface appears in its `index.md` at once.

package/claude/skills/index-lookup/REQUIREMENT.md

@@ -1,35 +0,0 @@
----
-name: index-lookup
-description: Why a topic search over the tracked index catalog needs its own skill, and why a folder outside `list`'s walk gets a named pointer instead of a search hit
----
-
-# Index lookup requirement
-
-## Gap
-
-Without this skill, `canon indexes list --json` exists as a verb with nobody wrapping it into a topic-search request. A session either greps the tree by hand, which misses everything the catalog already states in `title` and `description` rather than in file contents, or answers from whichever folder it happened to open, which reports a topic as undocumented when the topic only sits outside the walked corpus: a gitignored indexed folder such as `.canon/tasks/` or `.canon/memory/`, or a README-based record catalog such as `.canon/groundwork/`, neither of which `list` ever reaches.
-
-## Must
-
-- Run `canon indexes list --json` and match the topic against every entry's `title`, `description`, and `path`
-- Check whether the project carries a gitignored indexed folder or a README-based record catalog outside `list`'s walk before naming any of them, since a folder absent from the project names nothing
-- Report zero hits inside the walked corpus as zero hits, never as "not documented," since a folder outside the walk can still hold the answer
-
-## Must not
-
-- Search file contents. A miss against `title`, `description`, and `path` is the whole answer, and grepping the tree is a different request.
-- Extend `canon indexes list` to read a `README.md` catalog or to bypass the gitignore filter. Both are accepted trade-offs the verb already carries, and widening either is a CLI change, not a skill-body change.
-- Regenerate an index on its own initiative. Reporting a stale-looking entry is this skill's job, and writing the fix belongs to `canon indexes regen`.
-- Fire from a request to browse a file whose path is already known, or to search source code, both of which this skill answers nothing for
-- Assume this skill's own invocation frequency needs no check. The reminder hook names it beside `canon indexes list --json`, and a session recognizing a topic-lookup request can trigger it by description, but whether anything reaches for it beyond an operator typing its name has no answer at creation time, so a review pass some months in should read that back rather than take it on faith.
-
-## Guards
-
-- `canon indexes list` does not resolve on an older install. Report that rather than falling back to a manual walk, since a hand-rolled walk here restates the CLI logic this skill exists to call.
-- A folder failing frontmatter validation drops out of `entries` and its message lands in `errors`, per the verb's own per-folder isolation. Report the error alongside the match rather than treating it as a reason to stop.
-
-## Out of scope
-
-- Regenerating or scaffolding an index, which `canon indexes regen` and the `target-setup` skill's `indexes` phase own
-- Reading a folder's contents once a hit names it, which is an ordinary file read rather than part of the lookup
-- Chaining this skill into the `target-setup` skill's `indexes` phase as a verification step. Left independent: that phase already validates through `canon indexes regen --dry-run`, and a second skill call inside a bootstrap flow duplicates a check that already runs.

package/claude/skills/index-lookup/SKILL.md

@@ -1,44 +0,0 @@
----
-name: index-lookup
-description: Answers a topic search over every tracked index.md catalog in the project by running `canon indexes list --json` and matching the topic against each entry's title, description, and path, then reports the hits or names why there are none. Names the gitignored task and memory catalogs and the groundwork and intake record folders as pointers outside its walked corpus, so it never claims a topic is undocumented when the topic only sits there. Use when asked "where is X documented", "is there a page about X", "search the docs for X", "find the index entry for X", or "what covers X". Do NOT use to grep source code, browse a file whose path is already known, or regenerate an index, which is `canon indexes regen`.
-metadata:
-  family: answer
----
-
-# Index lookup
-
-Answers a topic search over the project's tracked `index.md` catalogs, not a text search over file contents. Matches a topic string against every entry's `title`, `description`, and `path`, drawn from wherever `canon indexes list --json` walks.
-
-## Steps
-
-1. Resolve the project root with `git rev-parse --show-toplevel`, falling back to the working directory when the read fails.
-2. Run `canon indexes list --json` from that root.
-3. Read `errors` first. A folder failing frontmatter validation drops out of `entries` and lands its message in `errors` instead, per the verb's own per-folder isolation, so report an error alongside the match rather than reading it as a reason to stop.
-4. Match the topic case-insensitively as a substring against each entry's `title`, `description`, and `path`. Report every match. A lookup with no ranking is honest about what it found, and a single best guess is not.
-5. Check whether the project carries a gitignored indexed folder or a README-based record catalog outside `list`'s walk: `.canon/tasks/`, `.canon/memory/`, `.canon/groundwork/`, `.canon/intake/`. Test each for existence and at least one file inside it before naming it. A folder absent from this project names nothing.
-6. Report the hits, plus a pointer to any outside-the-walk folder found present, per Output below.
-
-## Rules
-
-- Report zero hits as zero hits, never as "not documented." The topic can sit inside a folder step 5 found and named, so an empty walked corpus is a fact about the search, not about the project.
-- Never search file contents. A miss against `title`, `description`, and `path` is the whole answer, and a request that needs a text search calls for grepping the tree instead.
-- Never regenerate or edit an index. Report an entry that reads as stale rather than running `canon indexes regen` on this skill's own initiative.
-- Report an absent `canon indexes list` subcommand rather than falling back to a manual walk. It ships with the CLI, so a project on an older install meets a missing verb, and a hand-rolled walk here restates the CLI logic this skill exists to call instead.
-
-## Output
-
-```plaintext
-Index lookup: "<topic>"
-
-Hits:
-- <path>: <title> — <description>
-
-Outside the walked corpus (check by hand):
-- <folder>: <one-line reason it sits outside list's walk>
-```
-
-Replace the "Hits" block with `No catalog entry matched "<topic>".` when nothing matched. Omit "Outside the walked corpus" when the project carries none of the five folders from step 5, or when every one it carries is empty.
-
-## Reference
-
-Run `canon docs indexes` for the `canon indexes list` flags, exit codes, and JSON shape. It resolves from the toolkit rather than from the target's own tree.

package/claude/skills/markdown-propose/REQUIREMENT.md

@@ -1,47 +0,0 @@
----
-name: markdown-propose
-description: Why a markdown rewrite is proposed per file and answered before anything applies, rather than edited live or argued in chat
----
-
-# Markdown propose requirement
-
-## Gap
-
-Rewriting a passage in a governing document today means editing it live or arguing in chat, and two surfaces sit near this moment without covering it. `canon markdown audit` measures bans and structural checkpoints from package data.
-
-`review-branch` reports findings on a diff someone already wrote. Neither drafts a replacement, carries an answer slot, or waits.
-
-A review delivered in chat gets applied from memory across files nobody reopened, and nothing records which changes the operator approved. A change nobody agreed to either lands unreviewed, because the session acting on a chat review cannot tell an approved line from an inferred one, or never gets written down at all, because a finding with no draft behind it hands the rewrite back to whoever reads it next.
-
-A second failure compounds the first. A claim copied across several files is corrected in the one a session happened to open, and the copies elsewhere now read as freshly reviewed while still disagreeing, since nothing reconciles a restatement against the source it was drawn from.
-
-## Must
-
-- Take the concern and the surface as inputs and run one procedure against them, so a second concern reuses this skill rather than forking it
-- Grep the named surface for the concern before proposing, so a defect's site count is measured rather than assumed
-- Draft the replacement text, not only the finding
-- Carry three labelled variants on a change whose replacement was invented, and one on a change that corrects text to a recorded fact
-- Write one proposal file per source file under `.canon/proposals/<nn>-<slug>/` and stop, leaving `You:` empty on every change
-- Apply only a change carrying an answer, one file at a time, and re-grep its anchor before applying it
-- Report what each file leaves alone, so a proposal cannot be read as finding everything wanting
-
-## Must not
-
-- Edit a source file during the Propose phase
-- Apply an unanswered change, or a subset of a file's answered changes while leaving the rest for later
-- Fill a `You:` slot, or infer a disposition from an empty one
-- Name a specific concern in this skill's own procedure. A concern belongs in the invocation, and hardcoding one narrows the skill to the day it was written.
-- Assume the skill earns its place because the gap is real. Whether anything invokes it beyond the operator typing its name has no answer at creation time, and is a review criterion to read against a later usage census rather than a gate this file can pass on its own.
-
-## Guards
-
-- No concern named and none derivable: stop rather than inferring one
-- No surface named and none derivable: stop rather than screening the whole tree
-- The concern resolves to one file: stop and say a single-file change needs no proposal folder
-
-## Out of scope
-
-- Reporting a violation with no drafted replacement, which `canon markdown audit` already owns
-- Reviewing a diff someone already wrote, which `review-branch` owns
-- Filing a raw brain dump as findings, which `plan-intake` owns
-- Reviewing `.canon/memory/` and proposing promote-or-retire actions per entry, which `memory-review` owns on a different subject with a different answer contract

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

@@ -1,122 +0,0 @@
----
-name: markdown-propose
-description: Reviews a named markdown surface against a named concern, drafts a per-file proposal under `.canon/proposals/<nn>-<slug>/` carrying a diff and a reason for each change, and stops without editing a source file. Takes the concern and the surface as inputs, such as a claim stated stronger than the record, a fact gone stale, two files disagreeing, or a passage duplicated without derivation. A later invocation applies what the operator answered. Use when asked to "propose a change to CLAUDE.md", "draft a rewrite of this standard", "propose fixes to this doc", "draft alternatives for this passage", or "apply the answered proposals". Do NOT use to report without drafting a replacement (`canon markdown audit`), to review a diff already made (`review-branch`), or to file a raw brain dump as findings (`plan-intake`).
-metadata:
-  family: check
----
-
-# Markdown propose
-
-Reviews what a markdown surface says against a named concern and proposes what it should say instead. Writes proposals and stops. The operator answers per change, and a later invocation applies the answered set.
-
-The value is the gate. A rewrite delivered in chat gets applied from memory across files nobody reopened, and nothing records what was approved.
-
-## Guards
-
-- No concern named and none derivable from the conversation. Stop: `❌ No concern to screen for. Name what looks wrong, or the surface to review.`
-- No surface named and none derivable. Stop: `❌ No surface to review. Name the files, or the folder, to screen.`
-- The concern resolves to one file only. Stop and say so: a single-file change needs no proposal folder.
-- A named file cannot be read. Stop and name it. Do not screen what resolved and report a partial result.
-
-## Phase detection
-
-Two phases share this body, picked by whether a proposal folder already exists for the request's slug.
-
-Derive `<slug>` from the concern and the surface, kebab-case, naming the subject rather than the activity. List `.canon/proposals/` at the main worktree root and match the topic against the slug half of each `<nn>-<slug>` folder already there before deriving a fresh one, the same way `plan-intake` matches its own folder. Never match against `.claude/` itself.
-
-With no match, a fresh folder takes the next ordinal in `.canon/proposals/`'s own sequence: list the folders present, take the highest `<nn>`, and increment it, starting at `01` when none exist. That sequence is independent of the one `intake` and `groundwork` share, so a proposals folder never reads or claims from theirs.
-
-- No matching folder, or the operator names a concern and a surface: **Propose**.
-- A matching folder exists and the operator says apply, ship, or commit the answers: **Apply**.
-
-All `.canon/proposals/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
-
-## Write scope
-
-Write only inside `.canon/proposals/<nn>-<slug>/`. A source file, a standard, a rule, and a plan all live outside that folder, so this one rule forbids every one of them during the Propose phase. The Apply phase is the one exception, and only for a change carrying a `You:` answer.
-
-## Concerns
-
-The concern is an input, not a flow toggle. The passes below are one procedure and the concern decides what pass 1 looks for.
-
-| Concern       | What it looks like                                                   |
-| ------------- | -------------------------------------------------------------------- |
-| Inflation     | a claim stated stronger than the record supports                     |
-| Staleness     | a fact correct when written and wrong now, usually a date or a count |
-| Contradiction | two files, or two sections, asserting incompatible things            |
-| Duplication   | one passage copied across files with no derivation, drifting apart   |
-
-The operator may name a concern outside this table. Run the same procedure against it.
-
-## Propose phase
-
-Read `${CLAUDE_SKILL_DIR}/references/format.md` before writing anything. Do not work the proposal format from memory.
-
-### 1. Find the sites
-
-Grep the named surface for the concern and its near-variants. A defect rarely repeats verbatim, so search the habit rather than the string.
-
-Count hits per file before reading them. A file with one hit and a file with eight are different problems.
-
-### 2. Find what it should say
-
-Read whatever the operator names as the authoritative source for the concern. Absent one, grep the rest of the tree for a passage already stating the corrected form, since a correct version often already exists somewhere the defect has not reached.
-
-Report a file that contradicts itself. A file holding both the defect and its corrected form is the strongest finding available, because the replacement is already drafted somewhere in the tree and needs no invention.
-
-### 3. Judge per line, not per match
-
-A matched string means different things in different registers. A word describing a mechanism is a fact about how something works. The same word describing reach is a claim about who relies on it. Sweeping both because they share a string is what makes the next pass harder to trust.
-
-### 4. Write the proposals
-
-One file per source file under `.canon/proposals/<nn>-<slug>/`, per `${CLAUDE_SKILL_DIR}/references/format.md`.
-
-Draft the replacement text. A proposal reporting a problem without a replacement hands the work back rather than doing it.
-
-Carry an `Open:` on any change whose replacement was written rather than corrected, and give it three variants per the format reference. Correcting an overstatement to the recorded fact has one answer. Inventing a paragraph has no right answer, and one draft asks the operator to veto instead of to choose, which costs a round every time the intent lands wrong.
-
-Separate the two kinds before drafting. A change that deletes a claim the record does not support is cheap and rarely argued. A change that writes new prose is where the effort belongs.
-
-Close each file with what it leaves alone, and say why those lines survived.
-
-### 5. Report
-
-Name the count, the files, and the single highest-value change. Point at the folder and stop.
-
-Do not edit a source file. Do not fill a `You:` slot.
-
-Propose in dependency order and state it in `00-overview.md` when the surface spans more than two files. A file other files quote is settled first, otherwise the same wording gets decided twice.
-
-## Apply phase
-
-Read `${CLAUDE_SKILL_DIR}/references/format.md` before applying anything, if this session has not already read it this pass.
-
-Follow the Applying section there: one file at a time in settle order, every answered change in that file and nothing unanswered, re-grepping each anchor before applying it, sweeping the other named surfaces for the same claim before committing, and moving an applied change into `applied.md`.
-
-Report the counts once the pass stops: files committed, changes applied, changes still carrying an empty `You:`. Leave the folder in place. Neither phase deletes it.
-
-## Output
-
-Chat output is the report. This skill persists only the proposal folder itself.
-
-```plaintext
-📂 Opened .canon/proposals/<nn>-<slug>/
-
-**Screened:** <N> files, <N> changes proposed, <N> carrying three variants
-
-**Highest value:** <the single strongest change, one line>
-
-Next: answer the `You:` slots in the files under .canon/proposals/<nn>-<slug>/,
-then re-invoke this skill to apply what you answered.
-```
-
-Use `📂 Resumed` in place of `📂 Opened` on a resume pass. The Apply phase reports instead:
-
-```plaintext
-✅ Applied .canon/proposals/<nn>-<slug>/
-
-**Committed:** <N> files, <N> changes
-
-**Still open:** <N> changes with an empty `You:`
-```