@erclx/canon 5.31.0 → 5.33.0

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

@@ -1,52 +0,0 @@
----
-name: memory-review
-description: What memory review is for, the gaps it closes, and why every action waits on approval
----
-
-# Memory review requirement
-
-## Gap
-
-Without this skill, the memory folder grows and never drains. Entries pile up restating rules a durable surface already carries, nothing decides which memory has earned a place in one, and a rule that does get promoted arrives verbatim in a file whose voice it does not match. The folder then reads as a second source of truth that no surface points at.
-
-A pen too large to review whole is the same gap wearing a different shape. Routing at capture takes the domain facts and whatever the ownership test leaves stays, in whatever mix of types that is, so the folder reaches a size no single pass can read: every entry plus every promotion target runs to hundreds of thousands of tokens before one entry is classified. A review that cannot run drains nothing however often someone asks for it, so the pass takes a bounded batch in the order the stale verb reports and reads targets per entry. An entry leaving the pen is archived rather than deleted, because a folder git does not hold gives a wrong bulk call no undo.
-
-## Must
-
-- Treat the folder as a holding pen, so every entry in scope leaves it as a promotion, a handoff, or an archive, or stays only as a kept entry stamped with the date it was reviewed
-- Take one bounded batch per pass in the order `canon records stale memory` reports, and stop rather than falling back to a full sweep when that verb is absent
-- Stamp `reviewed` on every entry a pass keeps or skips, so the next batch moves on to entries nobody has read
-- Archive an entry out of the pen rather than deleting it, since nothing recovers a file from a gitignored folder
-- Hand a fact a context entry owns to `context-fold` through the routing file, rather than editing the entry here
-- Verify the rule is not already stated or implied in the target before proposing a promotion, by reading the target rather than trusting the memory's claim about it
-- Rewrite a rule into the destination's voice instead of moving it unchanged
-- Write the proposal to a receipt on disk and take no action until the user decides per item
-- Route every decision channel through the receipt, writing a decision given in chat into its item's slot before the parse reads the file, so a channel the skill advertises drains the pen rather than passing over it
-- Keep a promotion on its own commit, since a change to how the agent operates should not ride inside a feature a reviewer is vetting for something else
-- Collect a receipt as soon as its last item resolves, rather than waiting for an operator to ask, since a collection nobody triggers is a folder that only grows
-- Fold each declined item into its memory entry before the receipt goes, because a promoted item survives in its target and in git while a decline is recorded nowhere else
-- Record that decline by rewriting the entry rather than appending to it, so the file states one current claim
-- Confine the pass that runs after application to the one receipt it tested, so tidying up removes a file whose decisions are known to be resolved and leaves every untested receipt alone
-
-## Must not
-
-- Apply anything the user has not approved by item
-- Author a toolkit rule inline. A toolkit rule under `internal/rules/` or `governance/rules/` has an owner and a scaffolding path, `internal-governance`, and a rule written here bypasses it. A project rule under `.claude/rules/project/` is project-owned and takes an `Edit` appending to an existing file, or a handoff to `create-rule` when none fits.
-- Mutate tracked files from the main worktree
-- Answer a question raised in a decision slot while applying. Discussion and application are separate passes so an approval is never inferred from a reply.
-- Delete a memory entry at all. Every exit from the pen is a move into the archive.
-- Move an entry out of the pen outside the approved-per-item pass. The folder is gitignored with no history behind it, so a removal any other phase makes leaves no record of what it took.
-- Edit a context entry, or hand-edit the generated memory index
-
-## Guards
-
-- No memory folder at the main root: stop
-- The folder holds only its index: stop with a pass, not an error
-- Apply invoked from the main worktree: stop and name the worktree command
-- Cleanup invoked with no receipt on disk: stop with a pass, not an error
-
-## Out of scope
-
-- Writing memories, which `memory-capture` owns
-- Judging whether an entry should have been captured. That is a gate at capture time, and re-deciding it here would delete evidence the capture rule is wrong.
-- Editing the governance rules a handoff points at

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

@@ -1,129 +0,0 @@
----
-name: memory-review
-description: Reviews `.canon/memory/` and proposes per-entry actions (promote to an always-loaded rule, move into a skill body, route to a context entry, hand off to governance, or retire as stale). Also runs the discuss, challenge, apply, and cleanup phases on an existing review file. Use when asked to "review memory", "discuss memory questions", "challenge the promotes", "apply memory decisions", "cleanup memory review", "promote memory", or "consolidate memories". Do NOT auto-apply. Output a grouped proposal and wait for block-by-block approval.
-metadata:
-  family: ship
----
-
-# Memory review
-
-This skill drives the full memory review lifecycle in five phases. Pick the phase from what the user said and whether a review receipt already exists at `<main-root>/.canon/memory/review/memory-review-*.md`.
-
-What an entry looks like and why a retired one is moved rather than deleted are fixed by `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Read it before rewriting an entry, since a promotion rewrites the rule and a rewrite has to leave the entry conforming.
-
-| User intent                                                            | Phase     | Mutates                      |
-| ---------------------------------------------------------------------- | --------- | ---------------------------- |
-| "review memory", "promote memory", "sweep stale memories" (no receipt) | Propose   | review file only             |
-| "challenge the promotes" (receipt exists)                              | Challenge | review file only             |
-| "discuss", "respond to questions"                                      | Discuss   | review file only             |
-| "apply decisions", "commit", "ship the review"                         | Apply     | tracked files + memory files |
-| "cleanup", "delete the receipt"                                        | Cleanup   | one receipt + its skips      |
-
-If the user re-pings the skill with no new phrase and a receipt exists, default to Discuss when any `Decision:` contains `?`, otherwise Apply.
-
-## Guards
-
-- All `.canon/memory/` reads, edits, and archive moves resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
-- If no `.canon/memory/` directory exists at the main worktree root, stop: `❌ No .canon/memory/ directory found.`
-- If `.canon/memory/` contains no top-level `*.md` entries other than `index.md`, stop: `✅ No memory entries to review.` The pen holds two subfolders now, `review/` and `archive/`, and neither is a memory entry, so this count and every entry read below stay at the top level and never recurse into either.
-- Cleanup is exempt from the two stops above. It works on receipts in `.canon/review/`, and a drained pen is the normal state once Apply has run, so a pen-shaped stop would strand the receipt it exists to delete.
-- Resolve the main root via `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd`. All review and memory reads anchor here.
-- Every main-root write below goes out as a heredoc, routed the way `session-worktree` states. The receipt and a memory entry are both short and this session has read them whole, so a rewrite replaces the file with a heredoc rather than editing a line inside it. Promotion targets are tracked files at `pwd` and keep taking `Edit`.
-
-## Propose phase
-
-Propose is the entry point for a standalone run. The ship skills stop at capture and never invoke it.
-
-### Scope
-
-- **Batch:** run `canon records stale memory --json` and take the first 25 entries whose `due` is true, in the order the record lists them. When fewer than 25 are due, take all of them and say so. Never pad a batch with an entry that is not due.
-- **Named set:** when the user names entries, a list, or a slug, that set is the scope and overrides the verb's order. Propose nothing outside it.
-
-A whole pen does not fit one pass. Every entry plus every promotion target reads as several hundred thousand tokens on a grown project, so a full sweep fails before it classifies anything. The batch is bounded by the receipt the operator approves, which stays short enough for one pass at 25 items.
-
-Branch on the record rather than on the exit, which a shell function wrapping `canon` can flatten to zero. When the installed binary carries no `records stale` subcommand, or the record comes back with `ok: false`, stop: `❌ canon records stale is missing or refused. Update the canon CLI, since a review without it falls back to a full sweep that cannot run.` Never fall back to reading the whole pen.
-
-### Step 1: read the memory folder
-
-Read in parallel from the project root:
-
-- `.canon/memory/index.md`: the generated index, which is what lets a batch entry find a duplicate outside the batch
-- each entry in the batch, by name, never its `review/` or `archive/` subfolders: individual entries with frontmatter (`title`, `description`, `category`, and `reviewed` when a past pass kept it)
-
-### Step 2: search promotion targets per entry
-
-Do not read every target up front. For each entry in the batch, grep the target set below for the entry's subject, taking two or three keywords from its title and rule, and read the files that hit. Read `canon/context/index.md` once for the **Promote to a context entry** route. Skip any file or folder that does not exist.
-
-- `CLAUDE.md`: project behavior rules and Content ownership section, still a read target for the absorbed-already check even though it takes no new promotion
-- every `SKILL.md` under `.claude/skills/`: domain-scoped internal skill bodies
-- every `SKILL.md` under `claude/skills/`: plugin skill bodies
-- every `*.md` under `${CLAUDE_SKILL_DIR}/../../standards/`: authoring references
-- every `*.md` under `governance/rules/` in the toolkit repo, or `.claude/rules/` in a target project: coding-standards rules
-- every `*.md` under `internal/rules/` in the toolkit repo, or `.claude/rules/project/` in a target project: always-loaded rules a promote lands in
-
-A target the grep missed turns a promote into a retire, and only the operator's pass catches that. Name the targets each item searched in its receipt entry so the miss is visible there.
-
-### Step 3: classify each entry
-
-`.canon/memory/` is a holding pen. Default every entry to promote or retire on review. Keep is the exception, reserved for an entry still true that no surface owns, such as active task overlap or a user-type memory with no in-repo target.
-
-An entry's `unresolved` list in the stale record names paths it cites that the tree no longer holds. Weigh it as evidence for **Retire**, or for a rewrite when the rule survives the move, and never read it as the verdict alone. A rule can outlive the file it happened to name.
-
-`memory-capture` routes a project fact naming a domain with a context entry to that entry, so a pen filled since routing shipped is mostly feedback: rules about how to work, which no context entry owns. Propose against what the pen holds rather than expecting the older mix. An entry carried from before routing may still name a domain that has a context entry, and that entry's action is **Promote to a context entry**, which hands it to `context-fold` the same way capture does rather than editing the entry here.
-
-For each in-scope entry (see Scope), pick one action:
-
-- **Promote to an always-loaded rule**: the rule is cross-domain behavior or a design principle applied across the whole project, passing the tier test in `canon/context/context-model/overview.md` (applies every session regardless of what is being edited). Do not author a toolkit rule file inline.
-  - In the toolkit repo, hand off to `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own `internal/rules/` (this repo only, never ships) and the audience group under `governance/rules/` the rule serves (ships to every target that group reaches).
-  - In a target project, append the rule to an existing file under `.claude/rules/project/` with `Edit`, since a project rule is project-owned and sync never overwrites it, or hand off to the `create-rule` skill when no existing file fits.
-- **Promote to a skill body**: the rule fires only when editing a specific path-scoped domain. Name the target skill.
-- **Promote to a standards file**: the rule is an authoring reference that belongs in the project's own standards folder as `<domain>.md`.
-- **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `canon/context/index.md`. Append it to `.canon/tmp/handoff/memory-routing/<slug>.md` at the main worktree root, in the format `memory-capture` writes, and tell the user to run `/context-fold` from a branch. Do not edit the context entry here. A project-identity or command fact takes this action when a context entry owns the subject, such as a development entry for commands, and **Retire** otherwise, naming a hand edit to `CLAUDE.md` as the reason. Memory review does not write the root file itself.
-- **Hand off to governance**: the rule is coding-standards class (typescript, testing, naming, error-handling, performance, logging, concurrency, planning), never a cross-domain behavior rule. Do not author the rule file inline. Never edit the synced `.claude/rules/` copies of toolkit rules, because `canon gov sync` overwrites them. Stop at handoff. This and **Promote to an always-loaded rule** never both claim one entry: class names the topic (coding-standards routes here), firing axis names the rest (applies-every-session routes to the rule promote).
-  - In the toolkit repo, point the user at `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own the source-of-truth rules under `governance/rules/`.
-  - In a target project, point the user at the `create-rule` skill, which scaffolds a project-local rule under `.claude/rules/`.
-- **Retire**: the rule is stale, already absorbed into a durable surface, too vague to phrase as a rule, or a one-time incident narrative. Apply moves the file to `.canon/memory/archive/` rather than deleting it.
-- **Keep**: the rule is still true and no durable surface owns it. The entry stays in the pen, and Apply stamps `reviewed` so the verb does not queue it again until the window lapses.
-
-Retire is an archive, not a deletion, which `${CLAUDE_SKILL_DIR}/../../standards/memory.md` states as the rule and this skill executes. The archive is worth less than a plan's, since a promoted entry survives in its destination and a stale one is discarded on purpose, which is why the move is cheap rather than free.
-
-When two or more memories collapse into one rule on the same target, propose them as a single merged edit under the matching promote category. The consolidate case is a variant of promote, not a separate action.
-
-#### Absorbed-already check
-
-Before proposing promote, grep the target surface for the rule's keywords. If the rule is already stated there, the action is **Retire**, not promote. Do not rely on memory-file claims that a rule is documented elsewhere. Verify.
-
-The check covers implication, not only keyword match. If an adjacent bullet in the target section already implies the rule, merge into that bullet rather than append a second.
-
-#### Crispness check
-
-Rules that resist crisp one-line phrasing default to **Retire** over promote. Never promote a memory unchanged. Rewrite to match the destination surface's tone. Use single-directive rule-bullet phrasing for an always-loaded rule and imperative phrasing for skill bodies.
-
-### 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/memory/review/memory-review-<slug>.md` at the main worktree root. Do not print it inline. Read `${CLAUDE_SKILL_DIR}/references/receipt-format.md` for the file structure, the item template, and how each action type varies the body. The four later phases rewrite items inside an existing receipt rather than authoring one, so none of them opens it.
-
-A phase changing items reads the receipt, applies every change for that phase, and writes the whole file back in one command. Batching is what keeps a per-item rewrite from costing a full read each time, and it is the only route from a linked worktree, where the guard above rules out editing a line in place.
-
-Tell the user `✅ Wrote proposal to .canon/memory/review/memory-review-<slug>.md`. Ask them to fill in `Decision:` per item, then re-ping with "discuss" for question rounds or "apply" to commit.
-
-Rewrite the review file in place whenever the proposal changes mid-review. The file stays the source of truth for the current decisions.
-
-## Challenge, Discuss, Apply, and Cleanup phases
-
-Each later phase runs on its own invocation against a receipt Propose already wrote, picked by the table above. Read `${CLAUDE_SKILL_DIR}/references/later-phases.md` on reaching any of them, for the phase's trigger, what it may mutate, its procedure, and the line it ends on. Challenge and Discuss rewrite the review file only, Apply stops on the main worktree, and Cleanup removes one receipt.
-
-## After completion
-
-Output one line per action taken in the most recent phase:
-
-- `✅ Promoted: .canon/memory/<memory-file> → <target>`
-- `✅ Handed off: .canon/memory/<memory-file> → governance`
-- `📦 Retired: .canon/memory/<memory-file> → .canon/memory/archive/`
-- `🗑  Swept: .canon/review/<review-file>, folded <n> skips`
-- `📌 Kept: .canon/memory/<memory-file>, reviewed <date>`
-- `⏭ Kept: .canon/review/<review-file>, <n> items pending`
-
-If the user accepted nothing, output: `✅ No changes applied.`

package/claude/skills/memory-review/references/later-phases.md

@@ -1,118 +0,0 @@
----
-title: Memory review later phases
-description: The Challenge, Discuss, Apply, and Cleanup phases of memory-review, each run on its own invocation against a receipt the Propose phase already wrote
----
-
-# Memory review later phases
-
-The phases of `memory-review` after Propose. The session reads this file when the phase table in the skill picks Challenge, Discuss, Apply, or Cleanup, and reads only the section for that phase. The skill's Guards still hold for every phase here.
-
-## Contents
-
-- [Challenge phase](#challenge-phase)
-- [Discuss phase](#discuss-phase)
-- [Apply phase](#apply-phase)
-- [Cleanup phase](#cleanup-phase)
-
-## Challenge phase
-
-Trigger: user says "challenge the promotes", "challenge before apply", or asks for a high-bar pass. Run before Apply. No mutations to memory files or promotion targets. Review file only.
-
-1. Read the latest `.canon/memory/review/memory-review-*.md` at the main root.
-2. For each promote item, apply three tests:
-   - **Absorbed**: grep the target surface for the rule's keywords. If already stated or implied, flip to retire.
-   - **Delta**: if the rule is a nice-to-have next to existing bullets, flip to retire.
-   - **Generality**: if the rule fires only on one literal trigger phrase, rewrite broader or flip to retire.
-3. Rewrite the review file in place with the updated actions and a one-line reason under each flip.
-
-## Discuss phase
-
-Trigger: user says "discuss", "respond to questions", or any `Decision:` value contains `?` or an unrecognized verb. No mutations to memory files or targets. Review file only. Multi-round.
-
-1. Read the latest `.canon/memory/review/memory-review-*.md` at the main root.
-2. For each item whose `Decision:` contains `?` or any unrecognized verb (anything other than `apply`, `skip`, `defer`):
-   - Write a `Take:` line under `Decision:`, separated by exactly one blank line. If a `Take:` line already exists, overwrite it.
-   - Format: pick + one-line reason. Max 2 sentences. Decision-help style. State the recommendation (`apply` / `skip` / `retire` / specific alternative) first, then the reason. Do not enumerate tradeoffs unless one changes the call.
-   - Leave the H2 emoji as 📝 pending.
-3. Skip items whose `Decision:` is `apply`, `skip`, `defer`, or empty.
-4. End with: `💬 Discussed: <nums> | ⏩ Skipped (committed or empty): <nums>`. Remind the user to refine `Decision:` lines and re-ping with "discuss" for another round, or "apply" when ready to commit.
-
-Do not act on any item. Do not archive memory files. Do not edit promotion targets. Discuss only.
-
-## Apply phase
-
-Trigger: user says "apply", "commit", "ship the review", or re-pings with no question items remaining. Mutates tracked promotion targets and moves memory files into the archive.
-
-Before applying any item, check the worktree state:
-
-```bash
-[ "$(git rev-parse --git-dir 2>/dev/null)" = "$(git rev-parse --git-common-dir 2>/dev/null)" ] && echo "MAIN" || echo "LINKED"
-```
-
-If the result is `MAIN`, stop and tell the user: `❌ Apply phase mutates tracked files. Run /session-worktree first.` Discuss and Challenge phases only touch `.canon/review/` scratch and run from anywhere.
-
-Before applying a promote to an always-loaded rule in the toolkit repo, load `internal-governance`, which owns `internal/rules/` and `governance/rules/` and is the only route that may author into either. In a target project, hand off to `create-rule` with no load, since `internal-governance` is a toolkit-internal skill under `.claude/skills/` that a target project never has. An `Edit` appending to an existing file under `.claude/rules/project/` needs no load either.
-
-Promotions are a separate concern from any feature in flight. Keep the promoted edits on their own commit. Do not fold an always-loaded-rule or skill-body change into a feature's commits, because a feature reviewer should not have to vet a change to how the agent operates.
-
-For each item, parse the `Decision:` line:
-
-- `apply` (or affirmative): run the proposed action, flip emoji to ✅.
-- `skip`: leave the memory in place, stamp it reviewed as below, flip emoji to ⏭.
-- `defer` or empty: leave 📝 pending, take no action.
-- Contains `?` or unrecognized verb: leave 📝 pending, take no action. Do not respond. Discussion is the Discuss phase's job.
-
-Free-form text after the verb is a reason. Capture it in the receipt but do not let it change the action. When committing an item, strip any empty `Take:` line so the receipt stays clean. `Take:` lines with content stay as discussion history.
-
-Action by action type:
-
-- **Promote**: use `Edit` to insert the rewritten rule into the target surface, then archive the memory file. A promote to an always-loaded rule in the toolkit repo never reaches this line: it stops as a handoff to `internal-governance`, the same as **Hand off** below, and archives only on the user's explicit confirmation.
-- **Promote to a context entry**: append the fact to `.canon/tmp/handoff/memory-routing/<slug>.md` at the main worktree root, then archive the memory file. `context-fold` folds it in on its next run from a branch, which is what keeps one skill writing context entries.
-- **Hand off**: do not edit governance. Archive the memory file only if the user confirmed the handoff explicitly. Otherwise leave it in place.
-- **Retire**: archive the memory file.
-- **Keep**: stamp the memory file reviewed as below, and flip the emoji to 📌.
-
-Stamping means writing `reviewed: <today>` as a `YYYY-MM-DD` date into the entry's frontmatter, replacing any earlier value, and changing nothing else in the file. The entry is main-root scratch, so the stamp goes out as the same whole-file heredoc rewrite the Guards state. Stamp only an entry that stays in the pen, being a keep or a skip. A promote or a retire takes no stamp, since the entry leaves for the archive. The stamp is what takes a kept entry off the front of `canon records stale memory`'s queue, so an entry kept without one returns in the next batch.
-
-Archiving means creating `.canon/memory/archive/` at the main worktree root and moving the file there under its original name, overwriting any file already at that name. Send the `mkdir -p` and a plain `mv`, routed the way `session-worktree` states for a main-root move. Never delete a memory entry. Nothing recovers one from a gitignored folder.
-
-Do not hand-edit `.canon/memory/index.md`. Once every archive move and stamp is done, regenerate it instead:
-
-```bash
-canon indexes regen --no-stage --root <main-root> <main-root>/.canon/memory/index.md
-```
-
-An archive move is a shell `mv`, which skips the index hook the way `session-worktree` states. Without this call the index keeps a row per archived entry and drifts exactly the way the hand-appended one did. Run it once after the last move rather than per item.
-
-Apply promotion edits one at a time via `Edit`. Claude Code's tool permission dialog is the confirmation gate per edit. Never rewrite a whole promotion target.
-
-This governs the tracked surfaces a promote lands in, which sit at `pwd` and take `Edit` from anywhere. The receipt and the memory entries are main-root scratch and follow the skill's heredoc guard instead.
-
-As each item resolves, update its status in the review file: flip the H2 emoji from 📝 to ✅ for applied, ⏭ for skipped, 📦 for retired, 📌 for kept, or 🤝 for handed off. Refresh the summary block counts at the top. Do not delete the file here. The sweep below decides whether it goes.
-
-**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.
-
-### Sweep the receipt
-
-Count the items still pending once the parse above has run. An item is pending when its H2 carries 📝, or when its H2 carries no status emoji and its `Decision:` slot holds nothing the parse above would act on or skip, since a receipt written by hand or by an older binary may lack the marker. Apply leaves one pending on `defer`, on empty, and on any unrecognized verb, so a receipt reaching this point may still be holding decisions.
-
-Leave the receipt in place when any remain. When none do, collect it per the collection rule in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`, which owns what a fold writes and which entry types take one.
-
-`context-fold` Step 9 sweeps the same folder on the same rule once per shipped branch, and either may reach a receipt first. Whichever does, the other finds no file and moves on.
-
-End with: `✅ Applied: <nums> | ⏭ Skipped: <nums> | 📝 Pending: <nums>`. Omit empty buckets. If anything is pending, remind the user they can refine `Decision:` lines and re-ping, run "discuss" for question items, or commit a skip with `skip <nums>` in chat.
-
-## Cleanup phase
-
-Trigger: user says "cleanup" or "delete the receipt" after Apply has run.
-
-Cleanup folds one receipt's skips and removes that receipt, and does nothing else. It is the fallback route now that Apply and `context-fold` Step 9 each collect a resolved receipt on their own, so it reaches a file those two left behind rather than being the only collector. Apply is still the only phase that moves a memory entry out of the pen, and it does so per approved item into `.canon/memory/archive/`. A user asking to sweep stale memories wants Propose, which classifies entries and writes a decision slot per entry.
-
-If no `.canon/memory/review/memory-review-*.md` exists at the main root, stop: `✅ No review receipt to clean up.` Every other refusal in this skill carries a message, and the phase reads a receipt before it does anything else.
-
-1. Read the latest `.canon/memory/review/memory-review-*.md` at the main root and confirm Apply has run against it. If any item is still pending, by the test the Apply sweep states, stop and name the pending numbers.
-2. Collect it per the collection rule in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`, folding each ⏭ skipped item before the file goes. The fold happens wherever a receipt is collected, so this phase runs the same rule the Apply sweep does.
-3. Delete that one file. Leave every other receipt beside it in place, because the pending test above covers the file it read and nothing has tested the rest.
-4. Leave every memory entry in the pen. A skip records the decline on the entry and keeps the file, and applied promotions, governance handoffs, and user-type memories each stay as the review left them.
-
-Do not promote or archive a memory entry. The skip fold is the one rewrite this phase makes, and it records a decline on an entry that stays in the pen.

package/claude/skills/memory-review/references/receipt-format.md

@@ -1,64 +0,0 @@
----
-title: Memory review receipt format
-description: The proposal file structure, its item template, and how each action type varies the body
----
-
-# Memory review receipt format
-
-The shape Step 4 of the Propose phase writes to `.canon/memory/review/memory-review-<slug>.md`. Only Propose writes this file. Challenge, Discuss, and Apply rewrite items inside a receipt that already exists, and Cleanup deletes one, so none of the four needs this file.
-
-## Structure
-
-A summary block at the top, a legend, then one H2 per numbered item. Number items across all actions so the user can reference them by number. Fuse the status, action, and target into each H2. Put the memory filename on its own line, a one-line Why, the rewritten rule inline in a fenced `diff` block prefixed with `+` so reviewers see the additions in green, and a `Decision:` slot for the user.
-
-Do not include a `Take:` slot in the template. Discuss inserts one directly under `Decision:` only when responding to a question item. Status starts as 📝 pending for every item at proposal time.
-
-````plaintext
-# Memory review: <slug>
-
-**Batch:** <n> of <due> due entries, in `canon records stale memory` order. <due minus n> stay due after this batch.
-
-**Pending:** <all numbers>
-
-Legend: ✅ applied · ⏭ skipped · 📦 retired · 📌 kept · 🤝 handed off · 📝 pending
-
-How to respond: fill in `Decision:` per item (`apply`, `skip`, `defer`, or a question with `?`), then re-ping the skill. Say "discuss" for question rounds, "apply" to commit. Chat shortcut: `all`, `none`, or a list of numbers.
-
-## 1. 📝 Promote → `<target>`
-
-`<memory-file>`
-
-Why: <one-line pulled from the memory's Why>
-
-Searched: <the targets the grep hit and read>
-
-```diff
-+ <rewritten rule text>
-```
-
-Decision:
-
-## 2. 📝 Retire
-
-`<memory-file>`
-
-Reason: <one-line reason, naming any unresolved path the stale record listed>
-
-Searched: <the targets the grep hit and read>
-
-Decision:
-
-## 3. 📝 Keep
-
-`<memory-file>`
-
-Reason: <one-line reason no surface owns the rule>
-
-Searched: <the targets the grep hit and read>
-
-Decision:
-````
-
-## Variation by action
-
-For Hand off items, the body is a pointer to the governance target instead of a rewritten rule: `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md` in the toolkit repo, or the `create-rule` skill in a target project. For a Promote to an always-loaded rule item, the H2 target names the rule file path the rule lands in, `<target>` in the template above, being an existing path under `internal/rules/` or `governance/rules/` in the toolkit repo, or under `.claude/rules/project/` in a target project, or the `create-rule` pointer when no existing file fits. For Retire and Keep items, skip the rewrite block. A batch holding fewer than 25 entries says so in the `**Batch:**` line, and a scope the user named replaces that line with `**Batch:** named by the user, <n> entries`. Every item gets a `Decision:` slot regardless of action. `Take:` is added only when a question response is needed.

package/claude/skills/project-commands/REQUIREMENT.md

@@ -1,42 +0,0 @@
----
-name: project-commands
-description: Why running a documented command stops at the report, and what a single-file read buys over framework inference
----
-
-# Project commands requirement
-
-## Gap
-
-Without this skill, a session asked to start the app infers a command from a framework it recognizes or a script name it likes the look of, and a project whose dev loop differs from the convention gets the convention anyway. The user cannot see it was a guess, because a guess and a read produce the same first line.
-
-The larger failure is the one past the launch. A session that starts a server keeps going into log reading, browser checks, and defects it noticed on the way, so a request that was one command becomes an open-ended investigation nobody asked for and the answer arrives buried. A request covering a frontend and a backend gets one of the two, which reports success on half an app.
-
-Two more failures are mechanical. A command that stays up run in the foreground blocks until the tool timeout, which reports as a service that never came up while nothing is left running. And a command whose effect outlives the process, such as a deploy or a migration, is not undone by stopping it, so running it to see what happens is not available.
-
-## Must
-
-- Read the documented dev loop and treat it as the only source, since a second file is a discovery chain and this skill has none
-- Match the request against the stated purpose rather than the command name, since a project documenting two similar commands means the distinction
-- Resolve every documented command the request covers, not the first one that matches
-- Background a command that stays up, and read its output back before checking anything against it
-- Report the port, URL, or exit status per command, then end the turn
-
-## Must not
-
-- Infer a command from a filename, a framework, or a second file
-- Stop, restart, or reconfigure a process the skill did not start, or tear down one it did
-- Continue past the report into a second check, a screenshot, or a defect report. Say in one line that one looks warranted and let the user decide.
-- Abandon the remaining commands when one fails
-
-## Guards
-
-- No documented dev loop stops by naming the missing file, since a reconstruction the user cannot see through is worse than a stop
-- A request matching nothing documented lists what is documented instead of inferring
-- A command whose effect outlives the process prints for the user to run rather than running, judged on the effect rather than the name
-
-## Out of scope
-
-- Confirming a change works in the running app, which is a verification request and needs the steps this skill refuses
-- Deploying, publishing, releasing, migrating, and resetting
-- Running the scaffold verification chain against `package.json` scripts: the `target-setup` skill's `verify` phase
-- Writing the entry it reads, which belongs to the project's own development docs

package/claude/skills/project-commands/SKILL.md

@@ -1,87 +0,0 @@
----
-name: project-commands
-description: Runs a command the project documents in its development context entry and stops there. Use when asked to "start the app", "start the dev server", "run the checks", "run the build", "spin it up", or "what commands does this project have". Do NOT use to confirm a change works in a running app, which needs verification past the launch. Do NOT use to deploy, publish, or release.
-metadata:
-  family: build
----
-
-# Project commands
-
-Read the project's development context entry, run the command the user named, report where it landed, and stop.
-
-The value is the stop. A launch that continues into log inspection, browser checks, or unrelated defects is the failure this skill exists to avoid.
-
-## Guards
-
-- Resolve the entry before anything else. Take the flat `development.md` under `canon/context/` when it exists, and `canon/context/development/overview.md` when the domain outgrew one file and split into a folder, which is where the `## Scripts` table lands in a split. Test both paths, then read one. If neither resolves, stop with the line below and let the user decide.
-- If the entry documents no command matching the request, stop and list what it does document. Do not infer a command from a filename or a framework.
-- If the resolved command has an effect that outlives the process and stopping it does not undo, print it for the user to run and stop. Deploying, publishing, releasing, migrating, and resetting are the common shapes, and the test is the effect rather than the name. A script called `infra:apply` or `promote` qualifies.
-
-Do not read another file to reconstruct an entry that did not resolve, because a guess is worse than a stop when the user cannot see it was a guess.
-
-The stop names the flat path in both cases, since a project carrying neither has no entry to point at and the flat one is where a project without a split keeps it:
-
-```plaintext
-❌ No canon/context/development.md. This project has no documented dev loop.
-```
-
-## Step 1: read the entry
-
-Read the path the guard resolved, from the project root, the whole entry rather than a named section. That file and no others. A second file is a discovery chain, and this skill has none. Testing two candidate paths is not one, since the test happens before any read and exactly one file is opened.
-
-A split domain keeps its other sub-area files out of reach on purpose. `overview.md` carries the run commands, and the siblings beside it cover verification stages, hooks, and scratch, none of which this skill runs.
-
-## Step 2: resolve the command
-
-Match the request against what the entry documents, reading the stated purpose and not only the command name. A project that documents two similar commands separately means the distinction, and the purpose column is where it says which is which.
-
-When the request maps to more than one documented command, resolve all of them. A project that starts as a frontend and a backend has two rows in the table and one request covering both, and running one of the two reports success on half an app.
-
-State the resolved command before running it. One line, no rationale.
-
-## Step 3: run it
-
-Run each resolved command as the entry writes it, from the project root. When a command only works from a subdirectory, the entry has to say so, since the table gives the skill nothing else to go on.
-
-A command that terminates runs in the foreground. A command that stays up runs in the background, by setting the Bash tool's `run_in_background` parameter on the call. Nothing backgrounds a process on its own, and a foreground dev server blocks until the tool timeout kills it, which reports as a command that never came up and leaves nothing running.
-
-Decide from what the entry says the command does, not from its name. When the entry does not say, treat a server, watcher, or preview as staying up.
-
-- Read a backgrounded command's output back before checking anything against it. The call that starts it returns immediately and carries no port.
-- Report the port or URL each command prints, and the log location when one exists
-- Confirm a service came up with one check against what it reports listening on
-- Leave a process the skill did not start alone. Never stop, restart, or reconfigure one.
-- Do not tear down what the skill started. A session that starts a server and stops it has not done what was asked.
-
-If a command fails or never comes up, report the failure and the last output. Do not retry with a different command, and do not abandon the others.
-
-An exit status here is part of the report rather than the basis for one. Step 3 confirms a service came up against what it printed, so the number is passed through to the reader and decides nothing. A documented command reaching `canon` is the case worth naming, since an operator's shell profile may wrap the binary in a function that takes its status from a later command, and judging that run by its exit would call a refusal a success.
-
-## Step 4: stop
-
-Report and end the turn. Specifically do not:
-
-- Run a second check after the first one passed
-- Read the startup log for anything beyond a failure
-- Open a browser, take a screenshot, or drive the running app
-- Report a defect noticed while starting up, however real
-
-Those belong to a verification request, which is a different ask. When one of them looks warranted, say so in one line and let the user decide.
-
-## Output
-
-```plaintext
-▶️ <resolved command>
-
-<what it reported: port, URL, or exit status>
-```
-
-One block per command when the request resolved to more than one.
-
-For a request with no command to run, list what the entry documents instead:
-
-```plaintext
-📋 Documented in <the entry path the guard resolved>
-
-- `<command>`: <purpose as the entry states it>
-```

package/claude/skills/repo-metadata/REQUIREMENT.md

@@ -1,37 +0,0 @@
----
-name: repo-metadata
-description: Why an About text nobody re-derives drifts from the README it summarizes, and why writing it stays a second, explicit step
----
-
-# Repo metadata requirement
-
-## Gap
-
-Without this skill, a repository's GitHub About description, homepage, and topics are set once by hand and never checked again. Nothing in either skill corpus reads or writes them, so a README rewrite carries no signal back to the three fields a stranger reads before the README, and they drift silently. That already happened here: the About text disagreed with the README's own opening line, and nobody noticed until someone read both side by side.
-
-A session that fixes this by hand skips the gate a repeatable proposal would have given it. It reads the README once, writes a description from memory, and never records what it compared against or gives anyone else a chance to see the diff before it goes out. The write is also public and immediate: `gh repo edit` changes what every visitor to the repository page sees, with no draft state and no second confirmation from GitHub itself.
-
-## Must
-
-- Compute the proposal from the tree alone, through `canon repo metadata propose`, and report the diff against the remote before any write is discussed
-- Route the choice of which fields to write through the structured question surface, since which field to accept is the operator's preference to decide
-- Run `canon repo metadata apply` only in a turn separate from the one that ran propose, carrying only the fields the operator answered in this conversation
-
-## Must not
-
-- Call apply in the same invocation that ran propose, whatever the operator's request already names
-- Write a field the operator has not answered in this conversation, even when the CLI's own proposal suggested a value for it
-- Read an absent field in the proposal as a suggestion to clear what the remote already carries
-- Edit `README.md` or any repository setting other than description, homepage, and topics
-- Fire from a request with no repository-metadata content, since a skill invoked on a vague signal risks presenting a write path the operator never asked for
-
-## Guards
-
-- No `gh` remote resolves. Stop, naming the refusal `canon repo metadata propose` reports, since a proposal with nothing to compare against is a suggestion nobody asked for.
-- `canon repo metadata propose` or `apply` does not resolve on an older install. Report that rather than proceeding, since the fix without the verb reintroduces the hand-written write this skill exists to gate.
-
-## Out of scope
-
-- Editing the README's own content, which is a request against that file rather than against repository metadata
-- Repository settings outside description, homepage, and topics, such as visibility or branch protection, which carry a different blast radius and no local source to propose from
-- Any repeat run outside a target project's own tree, since the proposal is computed from that tree's README and manifest rather than from this toolkit's shape

package/claude/skills/repo-metadata/SKILL.md

@@ -1,54 +0,0 @@
----
-name: repo-metadata
-description: Proposes a GitHub About description, homepage, and topic set computed from the README's opening line and package.json, reports the difference against what the repository's remote already carries, and stops without writing. A later invocation, carrying the operator's answered fields, writes the change through gh repo edit. Use when asked to "propose repo metadata", "check the github description", "does our github about text match the readme", "sync github topics", "update the repo homepage", or "apply the repo metadata answers". Do NOT use to edit README.md itself, or to change a repository setting other than description, homepage, or topics.
-metadata:
-  family: setup
----
-
-# Repo metadata
-
-Reads what `canon repo metadata propose` computes locally and reports it against the remote. Writing is a separate step: `canon repo metadata apply` never runs in the same invocation that ran propose, whatever the operator answers in the same breath. The gate is the two invocations, not a prompt inside one.
-
-## Guards
-
-- Report it rather than proceeding silently when `canon repo metadata propose` or `canon repo metadata apply` does not resolve. Both ship with the CLI, so a project on an older install meets a missing subcommand rather than a refusal.
-- The propose read refuses when the repository has no remote `gh` can read. Report that refusal verbatim and stop. A proposal with nothing to compare against is a suggestion nobody asked for.
-- Never call apply in the same turn that ran propose, even when the operator's request already names the fields to write. Surface the proposal, get the answer, then run apply as its own step.
-- Never write a field the operator did not confirm in this conversation. A field the proposal computed and the operator has not answered stays unwritten, whatever the CLI's own suggestion for it was.
-- A field absent from the proposal has no local source and is never a suggestion to clear what the remote already carries. Report it as unchanged, not as a removal.
-
-## Propose
-
-1. Run `canon repo metadata propose --json`.
-2. Read `diff` and `repo` from the record. `repo` is the `--repo` value the later apply step must carry. An empty `diff` means the remote already matches what this run computed: report that and stop, since there is nothing to answer.
-3. When `diff` carries a `description` field, compress its proposed value, the raw opening line `canon repo metadata propose` computed, into a single short phrase. Leave the shape and length of the phrase to judgment on each run. No numeric target applies. Keep the raw proposed value beside the compressed phrase in what gets reported, so the operator can check the phrase against the README line it came from.
-4. For each field `diff` carries, put the change to the operator through the structured question surface: which of the differing fields to write. For `description`, the value offered to accept is the compressed phrase from step 3, not the raw line beside it. Rank accepting the proposed value first for a field whose current value is stale or wrong, and give the reject option the cost of leaving the remote as it stands. Never pre-select an answer for the operator.
-5. Report the fields the proposal left absent as unchanged, naming that neither the README nor `package.json` carried a source for them.
-6. Stop. Do not run apply here even when the operator answers immediately, since answering is not yet an apply invocation.
-
-## Apply
-
-1. Confirm every field about to be written was answered by the operator in this conversation. Carry no field forward unanswered. For `description`, the answered value is the compressed phrase Propose offered, never the raw README line reported beside it.
-2. Run `canon repo metadata apply`, always passing `--repo <owner/name>` from the propose record's `repo` field, plus the flags for the answered fields: `--description <text>`, `--homepage <url>`, `--topics <comma-separated list>`. `--topics` is the full desired set, and the command reads the current set itself to compute what to add and remove. The command refuses rather than writing when `--repo` does not match what `--root` resolves to, so never omit it and never guess it from anything but the propose record's `repo` field.
-3. Report the written state from the JSON record.
-
-## Output
-
-Propose:
-
-```plaintext
-📋 Repo metadata proposal
-description: "<current>" → "<compressed>" (derived from the README's opening line: "<raw>")
-homepage: unchanged, no local source
-topics: +<added>, -<removed>
-
-Answer which fields to write, then ask again to apply.
-```
-
-Apply:
-
-```plaintext
-✅ Applied: <fields written>
-```
-
-Omit a line from the proposal block for a field `diff` did not carry.