@erclx/canon 5.44.0 → 5.46.0

package/claude/skills/git-stage/REQUIREMENT.md

@@ -7,33 +7,27 @@ description: What commit grouping is for, the gaps it closes, and how it differs
 
 ## Gap
 
-Without this skill, a staged diff spanning several concerns lands as one commit, so a later revert takes unrelated work with it. A renamed file staged as two separate paths records an add and a delete, losing the rename git would otherwise detect. Commits also land in the order the files happened to be listed rather than the order they depend on, so a bisect stops on a commit that cannot build.
+Without this skill, a staged diff spanning several concerns lands as one commit, so a later revert takes unrelated work with it. A renamed file staged as two paths records an add and a delete, and commits land in listing order rather than dependency order, so a bisect stops on a commit that cannot build.
 
-The routing failure sits on top of those. A description claiming every commit request pulls in the single-concern one this skill has no grouping to do on, and a staged set carrying a hunk-level selection reaches the unstage below and comes back widened to whole files, which is the one case the staged-set rule cannot hold.
+The routing fails on top of that. A description claiming every commit request pulls in single-concern sets with nothing to group, and a hunk-level selection reaching the unstage comes back widened to whole files.
 
 ## Must
 
-- Read the commit format reference and the prose standard before generating
-- Decline the single-concern and the hunk-level staged set in the description, naming the sibling that takes each. The widening is a property of the unstage, so it cannot be fixed here and has to be routed around.
-- Derive the groups from the staged diff, with lockfiles excluded from the derivation context
-- Account for every staged file in the preview, so a dropped file is visible before execution
-- Order the commits so a dependency lands before the file that imports it
-- Keep a rename pair in one group and restage both paths together, so git still detects the rename at commit time
-- Unstage everything first, then restage per group, since the incoming staged set is one undifferentiated blob
-- Count each subject against the length limit and shorten before executing
+- Each message follows the commit format reference, derived from the staged diff with lockfiles excluded, with each subject counted against the length limit before executing
+- Every staged file is accounted for in the preview, and no file the user did not stage is committed
+- Commits are ordered so a dependency lands before the file that imports it
+- A rename pair stays in one group, so git still detects the rename
+- The description declines single-concern and hunk-level staged sets and names `git-commit` for both
 
 ## Must not
 
-- Stage a file the user did not stage. The staged set is the input and widening it changes what ships.
+- Stage a file the user did not stage
 - Split a rename pair across groups
-- Emit anything after the result line. This runs inside a longer flow and prose here buries the next step.
-
-## Guards
-
-- Nothing staged: stop and name the command that stages
+- Run when nothing is staged
+- Emit anything after the result line
 
 ## Out of scope
 
-- Composing a single commit from the whole staged diff, which `git-commit` owns. That skill commits the staged set untouched, so a hunk-level selection belongs there and never here.
-- Splitting commits across branches, which `git-split` owns. The two partition different things: this one takes a staged diff and emits commits, that one takes commits and emits branches.
+- Composing one commit from the whole staged diff, which `git-commit` owns
+- Splitting commits across branches, which `git-split` owns
 - Pushing and opening the pull request, which `git-pr` owns

package/claude/skills/git-worktree/REQUIREMENT.md

@@ -7,32 +7,28 @@ description: What worktree listing and cleanup is for, the gaps it closes, and w
 
 ## Gap
 
-Without this skill, linked worktrees accumulate past the point where any of them is remembered. Merge state does not appear in the worktree list, so a cleanup either removes a worktree still holding unmerged work or, lacking a way to tell, removes nothing. Removing a worktree also leaves its local branch behind, so the branch list keeps growing even when cleanup runs.
+Without this skill, linked worktrees accumulate past the point where any of them is remembered. Merge state does not appear in the worktree list, so a cleanup either removes a worktree still holding unmerged work or removes nothing.
+
+A plain ancestry read misses the whole set, since `git branch --merged` decorates every branch checked out in a worktree. Removing a worktree also leaves its local branch behind, so the branch list keeps growing even when cleanup runs.
 
 ## Must
 
-- Resolve merge state per branch from the pull request first, and fall back to local ancestry when no pull request exists
-- Match the ancestry fallback against the branch name alone. `git branch --merged` decorates the current branch and every branch checked out in a linked worktree, which is the whole set this skill enumerates.
-- Remove the worktree and its local branch together, since either one left alone is the state the skill exists to prevent
-- Exclude five kinds of row from the remove set: the main root, the current session's worktree, any dirty tree, any worktree registered from outside the path prefix `session-worktree` creates under, and any worktree a live session is occupying
-- Give every skipped row a one-word reason, so the skip is a decision the user can overturn rather than a silence
-- Pick exactly one mode. Listing and removing are different requests and inferring both from one invocation removes worktrees the user meant to read about.
+- Merge state comes from the pull request first and from local ancestry matched on the branch name alone when no pull request exists
+- A worktree and its local branch are removed together
+- The main root, the current session's worktree, a dirty tree, a worktree outside the prefix `session-worktree` creates under, and one a live session occupies are never removed
+- Every skipped row carries a one-word reason, and an empty remove set says why each row was held
+- Each run is exactly one of listing or removing
 
 ## Must not
 
-- Enter or create a worktree. The description states the boundary so the model routes entry elsewhere rather than discovering it here.
-- Remove a worktree with uncommitted work, whatever its merge state
-- Remove a worktree a live session is occupying, whatever its merge state
-- Remove the worktree the session is currently running in
+- Enter or create a worktree
+- Remove a dirty or occupied worktree, whatever its merge state
+- Remove the worktree the session runs in
+- Run outside a git repository
 - Emit anything after the result line
 
-## Guards
-
-- Not a git repository: stop
-- Remove set is empty: stop and say why every row was held back
-
 ## Out of scope
 
-- Entering a worktree, which `session-worktree` owns. That skill derives the name and aligns the branch, and this one never creates.
-- Deciding which features can run in parallel, which is a planning call rather than a git operation
-- The pull request lifecycle, which `git-pr` and `git-followup` own. This skill reads pull request state and never writes it.
+- Entering a worktree, which `session-worktree` owns
+- Writing pull request state, which `git-pr` and `git-followup` own
+- Deciding which features can run in parallel, which the planning skills own

package/claude/skills/make-deck/REQUIREMENT.md

@@ -7,38 +7,30 @@ description: Why the skill draws a deck as HTML in the project's tokens inside i
 
 ## Gap
 
-Without this skill, a deck request turns into hand-built output. The session writes a deck into whatever path occurs to it, so a second deck overwrites the first and nothing lists either. It writes pptxgenjs code or hex colors per deck, so the deck takes neither the project's design nor any other deck's, and it invents attributes the converter does not read, so a section, a chart, or an entrance silently goes missing. Every slide comes out as a title over bullets, which is the shape that needs no decision and reads as a document rather than a deck.
+Without this skill, a session writes a deck into whatever path occurs to it, so a second deck overwrites the first and nothing lists either. It writes pptxgenjs code or hex colors, so the deck ignores the project's design. Every slide comes out as a title over bullets, which reads as a document rather than a deck.
 
-A first render shipped unread hands the audience the overlap, the overflow, and every element the converter fell back to a picture for, since markup that looks correct says nothing about the file it produces.
+It invents attributes the converter does not read, so a section, a chart, or an entrance silently goes missing. A first render shipped unread hands the audience the overlap, the overflow, and every element the converter fell back to a picture for.
 
 ## Must
 
-- Read the existing decks and the slide format from the CLI before drawing, and pick a deck name no listed deck carries unless the request names one
-- Write each deck into its own folder under the slides record folder, one HTML file per slide in filename order
-- Draw with the project's custom properties so the deck takes the project's design
-- Vary the composition across the deck rather than repeating one shape
-- Size content to fit the slide frame, keeping titles short and lines tight
-- Shell out to the render command for the deck itself
-- Read every fallback and refusal the render reports, run one QA pass over the rendered images, and fix what both report
+- The existing decks and the slide format are read from the CLI before drawing, and a new deck takes a name no listed deck carries unless the request names one
+- Each deck lands in its own folder under the slides record folder, one HTML file per slide in filename order, drawn with the project's custom properties
+- The composition varies across the deck, and content fits the slide frame with short titles and tight lines
+- The render command produces the deck itself
+- Every fallback and refusal the render reports is read, one QA pass runs over the rendered images, and what both report is fixed once
 
 ## Must not
 
-- Hardcode a deck name, an attribute, or a chart type, which goes stale the moment the CLI changes
-- Reimplement the conversion, the master, or the packaging, which the CLI owns
+- Hardcode a deck name, an attribute, or a chart type, or reimplement the conversion, the master, or the packaging the CLI owns
 - Write a deck into the shared layouts folder, which is never listed as a deck
-- Invent token values when the project has no token stylesheet
+- Invent token values when the project has no token stylesheet, rather than saying the deck renders unstyled
 - Write centered body text or content that overflows a slide
-- Loop on aesthetics past a single fix pass
-
-## Guards
-
-- No token stylesheet: draw the deck anyway and say it renders unstyled.
-- Image conversion tools missing: skip the image pass and say so. Do not fail the render over a verification step.
+- Loop on aesthetics past a single fix pass, or fail the render when the image tools for the QA pass are missing
 
 ## Out of scope
 
 - Converting HTML to PowerPoint, which the CLI owns end to end
-- The project's palette and faces, which live in its token stylesheet rather than in the slides
-- Writing the content the deck is about, which the caller brings
-- Drafting a deck as a canvas page, which waits on a measurement of that authoring surface
+- The project's palette and faces, which its token stylesheet owns
+- Writing the content the deck is about, which the caller owns
+- Drafting a deck as a canvas page, which no skill owns until that authoring surface is measured
 - Recording a demo, which `script-screencast` owns

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

@@ -7,9 +7,9 @@ description: Why the markdown format rules travel in a skill, and where the boun
 
 ## Gap
 
-Without this skill, the markdown format rules sat in a standard that a session opened only when a rule told it to. The banned characters and the structure rules are facts a scan settles, yet a session wrote the whole document from memory and learned the result only from the audit's exit.
+Without this skill, the markdown format rules sit in a standard that a session opens only when a rule tells it to. The banned characters and the structure rules are facts a scan settles, yet a session writes the whole document from memory and learns the result only from the audit's exit.
 
-The rules also had three carriers, a standard, a generated rule pointing at it, and a second hand-written rule routing voice. Each stated one routing and each drifted from the others.
+The rules also have three carriers, a standard, a generated rule pointing at it, and a hand-written rule routing voice. Each states one routing and each drifts from the others.
 
 ## Must
 
@@ -20,4 +20,10 @@ The rules also had three carriers, a standard, a generated rule pointing at it,
 ## Must not
 
 - Restate the banned characters in the body
-- Carry voice, rhythm, or word guidance, which `write-human` owns
+- Carry voice, rhythm, or word guidance
+
+## Out of scope
+
+- Voice, rhythm, and word choice, which `write-human` owns
+- A Mermaid fence or a figure, which `draw-figure` owns
+- The banned-character scan itself, which `canon markdown audit` owns

package/claude/skills/pick-by-eye/REQUIREMENT.md

@@ -7,80 +7,30 @@ description: Why a decision settled by looking needs its own surface, and where
 
 ## Gap
 
-Without this skill, a session facing a decision nobody can settle from a diff:
+Without this skill, a session facing a decision settled by looking describes the options in prose or ships one answer to a taste call. The operator never sees what they chose between. A drafted set varies several properties or the wrong layer, sits in the real surface, and mixes themes and widths, so no pick names what decided it.
 
-- Describes two options in prose and asks the operator to choose. The operator decides by looking, so a described option is not an option and the answer that comes back is arbitrary.
-- Produces one answer for a decision that was taste, so the operator never sees what they were choosing between and the call is taken silently by whoever wrote the code.
-- Reports that a candidate reads well without rendering it, so the claim rests on the markup having been written rather than on the page having been seen.
-- Hands over one image per arm, which asks the operator to hold the differences in memory rather than showing them. The comparison is the artifact and a set of separate files is not one.
-- Varies three properties at once across the arms, so the pick cannot say which difference decided it and the next iteration guesses.
-- Writes the candidates into the real surface, so the losing arms have to be unpicked out of a tree the operator has not judged yet, and a variant left behind a flag becomes a second design nobody maintains.
-- Stops the loop when the arms stop differing rather than when the operator says the pick is right, which ends the run on the session's own patience.
-- Reads a driver record as a verdict and drops an arm on it. `canon drive` reports findings and never gates, so a run filtering the arms on a probe reading has made a claim the probe catalog has not earned.
-- Reads a color without compositing its alpha, samples a round control at the corner of its bounding box, or confirms a panel's dimensions while it sits above the viewport. Each reads as a passing measurement about something no reader sees.
-- Meets a machine with no browser binary and reports on the arms anyway, since nothing in the default flow separates a render that failed from one that was never attempted.
-- Hand-writes a mockup of a surface a running app already serves, which drifts from what ships by a few pixels and a few words the moment the app's own markup or stylesheet moves on.
-- Varies a property the decision is not about, which satisfies the one-property rule and produces a set differing in the layer a reader notices least. Five palettes over one identical page read as five skins of one design, and the operator rejected the whole set on sight.
-- Renders each arm in whatever theme it happens to carry, so a set spanning both themes cannot be compared without the operator toggling every arm and holding the earlier ones in memory.
-- Looks at a render to confirm it came out rather than to judge whether it is worth showing, which satisfies the rule against reporting an unseen result and still hands over weak work.
-- Writes the run's renders to a scratch path outside the record that cites them, leaving the folder holding source markup and none of the images, so the judgment is unreachable to everyone except the session that made it.
-- Narrows the page onto the picked arm in place on each iteration, so every earlier round is overwritten and a later pass cannot see what was already rejected.
-- Names no layer at all, since the instruction to name one carries no catalog to name from and nothing reports the omission. Four consecutive rounds against one page each varied a property at the top layer while the defect sat two below it, and three of the four changed nothing the operator could see.
-- Judges a lower layer through a finished higher one, so an operator asked about composition looks at the palette instead and answers about that.
-- Hands over the combined page alone for a decision about layout, where every arm sits in a column while the media queries answer to the whole window, so no arm is ever seen at its own viewport and a fault that appears only narrower survives the pick.
-- Rebuilds a navigation harness by hand on a run with several rounds, since each round writes its own folder and nothing reaches all of them from one address. Two design tracks hand-wrote the same page picker and theme toggle.
-- Meets a session with no canvas server and drafts into a file instead, which leaves the operator a second surface to open and the run a second close to remember. The canvas is the one drafting surface, so a run without one starts it rather than falling back.
-- Puts the pick question with no address in its output, after capturing the page and reading the image back. The operator then has to ask for a served page before they can look, so the question goes unanswered or gets answered blind.
-- Sets the theme on an arm that persists its own and reads it back on load, so the control reports one theme while the arm renders the other and the set is compared across two.
+The evidence fails as well. Arms get reported without being rendered or judged, a driver finding reads as a verdict, and the pick question arrives with no address to look at. Renders land in scratch, each round overwrites the last, and the losing arms vanish with the run's pages.
 
 ## Must
 
-- Produce three to five arms with the shipping state among them, each carrying an id, a label, and what the arm costs.
-- Draft every arm of a round as one self-contained frame on one canvas page and capture that page once as a composite, so the comparison arrives as one image, except where the surface under decision is a running app: there each frame links a copy of the built stylesheet inside the page folder rather than inlining it, per `references/live-arms.md`.
-- Start the canvas when none is serving, and stop on a canvas that refuses to start or answers with a blank shell, rather than drafting into a file.
-- Emit the layer in the run's own output, drawn from the catalog `design-taste` fixes rather than from a word invented per run, and vary the arms at that layer alone. A layer held privately is one nothing can report missing, which is how the instruction went unfollowed while every round passed its own rules.
-- Grey-box the set when the declared layer sits below typography, and say the set is grey-boxed when handing it over, so the operator reads a flat page as the question rather than as unfinished work.
-- Theme every arm off the attribute the canvas toggle sets on each frame, so one control sets the whole set and the comparison holds still while the operator reads it, and give no arm a script that reads a stored preference back on load over the toggle.
-- Give each frame the width the arm is judged at, since a frame renders at its own layout width and answers how an arm behaves at a width where a column on a shared page could not.
-- Judge each render against a stated bar before handing it over, name the weakest thing on the page, and fix it where that sentence would embarrass the work.
-- Write each iteration to its own canvas page rather than narrowing the previous one in place, so every earlier round stays openable from the canvas page list.
-- Write the run's renders inside the record that cites them wherever one exists, and reserve the scratch path for inputs that are re-runnable and cited by nothing.
-- Render before reporting on any arm, and report a missing browser binary as a refusal naming the repair rather than describing an arm nobody has seen.
-- Take the pick through the structured question surface, with the recommendation ranked first and marked, and every option carrying its cost. Read the canvas selection only to resolve an answer that points at it, and treat an empty or stale selection as no answer.
-- Keep every write inside the run's own canvas pages until the pick is final.
-- Apply the winning arm in one change.
-- Capture every arm from the round the pick came from, whichever round that is, as an image named for its frame before deleting the run's pages, rather than discarding the losing arms with them.
-- Delete only the canvas pages the run itself added, recorded as it adds them, and stop only a canvas server the run itself started.
-- Resolve the archival capture's destination against the main worktree root, never against a linked worktree the run happens to be building in.
-- Put the candidates on the canvas on every run, whatever the decision's layer, and emit the canvas link ahead of the first pick question, so the operator can open the page the question is about and a still is never the only address.
+- Three to five arms, the shipping state among them, each carry an id, a label, and a cost, and vary only at a layer named from the `design-taste` catalog
+- Each round is one canvas page of frames at their judged widths, themed by the canvas toggle and captured once as a composite, with the link ahead of the first pick question
+- Every arm is rendered and judged against a stated bar before handover, and a missing browser or a canvas that will not start is reported as a refusal
+- The pick comes through the structured question surface with the recommendation first and every option's cost, and the winner lands in one change
+- Every round stays openable on its own page until the pick, and the picked round's arms are captured into the citing record at the main root before the run's pages go
 
 ## Must not
 
-- Take the pick where two arms are both defensible and the difference is taste. That call is the operator's, and taking it silently is the failure this skill exists to prevent.
-- Draft candidates for a decision the operator has not asked to make. Each arm costs a render, and a run offering options everywhere spends their attention rather than saving it.
-- Restate the mechanics of the canvas, the render, or the probes. `canon canvas` and `canon drive` own those and their help text is the source, so a second copy here hands one case two answers.
-- Read a `canon drive` finding as a gate over the arms.
-- Fire on a request that already names one answer.
-
-## Guards
-
-The refusal strings sit in the body, since the runtime loads that file and ignores this one. Two conditions stop a run: a request naming one answer and asking for it to be built, and a decision with no visible form for a render to show.
+- Take the pick where two arms are defensible and the difference is taste
+- Draft candidates for a decision the operator has not asked to make, or for a request that already names one answer
+- Write into the real surface before the pick is final
+- Restate the mechanics `canon canvas` and `canon drive` own, or read a drive finding as a gate over the arms
+- Delete a canvas page or stop a server the run did not start
 
 ## Out of scope
 
-- `plan-feature` plans the work once the answer is settled, and declares the pull request boundary its plan carries. This produces the answer to pick from and stops before the plan.
-- `ux-audit` reads source to find roughness and reports it. This takes its input from the operator and changes nothing until they pick.
-- `ux-measure` measures what a running interface costs to paint. This measures whatever a visual claim depends on, which is usually geometry or contrast rather than cost.
-- `ui-checklist` writes what to look at on a change already made. This runs before there is a change to look at.
-- `script-screencast` scripts a recording of something already built. This has nothing built yet.
-- `canon canvas` owns the page, the frames, the selection, the address, and the render, and `canon drive` owns the probes. Both are invoked rather than reimplemented.
-
-### What did not travel
-
-This descends from a project-local skill whose interactive half was written against one repository. Three of its capabilities do not travel, and the two verbs above are what stands in their place:
-
-- An arm switcher compiled into the project's own page, driven by a query parameter. A canvas page of frames replaces it, which puts the arms on the canvas rather than in the source and removes the call site a run had to remember to delete.
-- A copy cycle keyed to canonical page text held in a second repository. No toolkit surface has that shape, so a project holding one owns the second edit and this skill states nothing about it.
-- A walker that reads every control on every page and groups them by treatment. `canon drive` probes one page and reports findings, so a sweep across every surface of a site is out of reach here and a run needing one measures by hand.
-
-The capture mechanics traveled with a change of owner rather than being lost. They sat in a project-local path-scoped rule that fired whether or not the skill ran, and `canon canvas capture` owns them here, which is why this file bars restating them rather than naming a rule to defer to.
+- Planning the work once the answer is settled, which `plan-feature` owns
+- Finding roughness by reading source, which `ux-audit` owns
+- Measuring what a running interface costs to paint, which `ux-measure` owns
+- Listing what to look at on a change already made, which `ui-checklist` owns
+- Scripting a recording of something already built, which `script-screencast` owns

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

@@ -7,37 +7,28 @@ description: What feature planning is for, the gaps it closes, and why it stops
 
 ## Gap
 
-Without this skill, implementation starts before anyone knows what it touches. A session reads no project context and rediscovers a settled constraint halfway through, the file list emerges as the work goes rather than before it, and the ambiguities that needed a decision get resolved silently in whichever direction the first edit happened to go. A constraint naming a surface to leave alone forbids two different acts at once, so the executing session picks one and the branch either grows an excluded concern or ships a reference to a file the change deleted.
+Implementation starts before anyone knows what it touches. A session rediscovers a settled constraint halfway through, and an ambiguity gets resolved silently in whichever direction the first edit went. A feature stacked into pull requests over the same files pays the review cost once per slice.
+
+A constraint naming a surface to leave alone forbids two acts at once, conforming it and retargeting a pointer into it. A vague ask reaches the plan with no checkable criterion, and a decision rests on a practice recalled from memory.
 
 ## Must
 
-- Read the project's own Claude setup before scanning source, so the plan inherits decisions already made instead of reopening them
-- Reframe a vague ask as observable, checkable success criteria before listing any file, and carry each criterion into the plan's verification, so a plan never ships a check with nothing measurable to prove
-- Slice batches by a user-visible path rather than by layer, and sequence the riskiest batch first while a sweep stays last, so the batch most likely to change the plan lands while later ones can still move, and fold a stacked batch that shares most of its files into its parent unless the plan writes down why the two are judged apart, since a canvas inspector built as five stacked pull requests over 26 files paid the full review, rebase, and merge cost five times
-- Predict the operator's answers to the next three questions about the ask's success criteria, proceed on the ones it can predict, and ask when it can predict none, since a plan built on a guessed goal proves the wrong thing
-- Fetch the outside source a decision rests on, quote the passage relied on in the plan's `**Sources:**` section, and mark a source it could not fetch as unverified, since a planner that paraphrases a practice from model memory ships an unaudited claim. A measured planner run fetched its sources only after a follow-up message asked, and the `search-craft` measured run shows a plain research request never loaded that skill unprompted
-- Name every file the work touches with the reason it is touched
-- Place each new path against the layout guidance with a one-clause reason, loading that guidance only when the plan creates a file or folder, since the planner decides placement and the worker copies whatever path it is given
-- Name how each outcome is proven and which input or state would break the change, so the executing session has a check to run and the reviewer has a place to look
-- Surface each unresolved ambiguity as a numbered question carrying a suggested answer and an empty answer slot, so the plan is decision-ready in one pass
-- State which act a constraint forbids when it names a surface to leave alone, since conforming that surface and retargeting a pointer into it are different acts and only one is out of scope
-- Scale the output to the work. A two-file change with nothing to decide should not produce a plan file.
-- Stop at the plan and wait to be told to continue
+- Read the project's Claude setup before scanning source, and name every file the work touches with the reason it is touched
+- Reframe a vague ask as observable success criteria, carry each into the plan's verification, and ask when none can be predicted
+- Slice by user-visible path with the riskiest batch first, and fold a stacked batch sharing most of its files into its parent unless the plan says why they differ
+- Quote the fetched passage behind each outside source, mark an unfetched one unverified, and place each new path against the layout guidance with a one-clause reason
+- Surface each ambiguity as a numbered question with a suggested answer and an empty slot, and stop at the plan
 
 ## Must not
 
 - Implement, or edit any file the plan describes
-- Read directories speculatively. Context spent on files the feature does not touch is context the plan does not get.
-- Bundle independent concerns into one plan, since a plan covering two things gets executed as neither
-- Restate the plan in chat during follow-up rounds. The file is the source of truth and a chat copy of it goes stale immediately.
-
-## Guards
-
-- No feature description: stop and ask for one
-- No predictable success criterion: ask before planning rather than guessing the goal
+- Read directories speculatively, since context spent on files the feature does not touch is context the plan does not get
+- Bundle independent concerns into one plan
+- Restate the plan in chat during follow-up rounds, since the file is the source of truth
 
 ## Out of scope
 
-- Executing the plan, which is the ship pipeline
-- Task-board state, which `task-board` owns. A plan links to its task and does not create one.
-- Reconciling the context entries after the work lands, which `context-fold` owns, and marking the board, which `task-complete` owns
+- Executing the plan, which `auto-ship` owns
+- Creating a task for the plan, which `task-board` owns
+- Reconciling the context entries after the work lands, which `context-fold` owns
+- Marking the board, which `task-complete` owns

package/claude/skills/plan-groundwork/REQUIREMENT.md

@@ -7,43 +7,27 @@ description: Why a question that has not been measured gets a disposable folder
 
 ## Gap
 
-Without this skill, a question nobody has measured is answered with a plan. The session commits to an approach before the current state is known, and the reasoning that produced it lives in a conversation that compacts away. A research pass that does run spreads its findings across chat, so the next session re-measures what this one already counted, or worse carries a figure from recall and states it as current.
+A question nobody has measured is answered with a plan. The session commits before the current state is known, and its reasoning compacts away with the conversation, so the next session re-measures what this one counted or states a figure from recall as current.
 
-Two failure modes cost more than the rest. A track that fans out to subagents returns findings without the reasoning that makes the folder worth keeping, which turns a conversation into a search result. And an experiment fixture written under the project root loads that project's own instruction files through the ancestor chain, so the arm measures the repository instead of the question, and the result reads as evidence either way.
-
-A track that closes with several separable findings writes only one task, and the rest have no stated route out of the folder. Without one, a finding sits until the operator asks whether filing it elsewhere is the next step, which is how a track that measured everything correctly still lost work between sessions.
+A track fanning out to subagents returns findings without their reasoning. Under the project root, a fixture loads its instruction files, so the arm measures the repository instead of the question. When a closing track holds several findings, one task is written and the rest have no route out.
 
 ## Must
 
-- Detect open, resume, and close from the folder itself, matching the topic against tracks already there before deriving a slug
-- Name a newly opened folder with a two-digit ordinal ahead of the slug, taken from the highest one already present across groundwork and intake
-- Apply the qualifying test in open mode alone, so a track already measured is not refused by the test that admitted it
-- Measure the current state now rather than carrying a figure from a previous session
-- Carry a lean and the finding that would overturn it on every open question, or admit that a measurement is missing
-- Confine writes to the track folder, with the close-time task file, the experiment fixture, and the intake routing below as the only exceptions
-- Route a closing-track finding the required task does not cover through `plan-intake`, rather than leaving it to be asked about. The route runs in the same session, so it is a write outside the folder rather than a handoff to a later one.
-- Place the closing task's row through `task-board` Step 4 rather than writing `priority.md` or `backlog.md` directly
-- Link every claim about a source outside the project, and list an unread source as a lead rather than citing it
-- Put a fixture a headless run is pointed at outside the repository
-- Write the next-session file self-contained, since backing the folder through `canon records push` and `canon records pull` holds only where a records remote is configured, protects only against the machine being lost even there, and never against a compaction dropping this session's reasoning before it has pushed
+- Detect open, resume, and close from the folder itself, matching the topic against existing tracks first, and number a new folder past the highest ordinal across groundwork and intake
+- Measure the current state now, carry a lean and the finding that would overturn it on every open question, link every outside claim, and end a pass with every question leaned on a plain retell
+- Confine writes to the track folder, plus the close-time task file, the experiment fixture, and the intake routing
+- Route a closing finding the task does not cover through `plan-intake` in the same session, and place the closing task's row through `task-board`
+- Put a fixture a headless run is pointed at outside the repository, and write the next-session file self-contained
 
 ## Must not
 
 - Write a feature plan, a source change, a standard, a rule, or a reference doc
-- Dispatch subagents. A search too large to run inline is a finding that the question is too broad.
-- Close while an open question quietly fails an outcome, rather than resolving it or recording it as knowingly accepted
-- Spawn more than three billed headless runs without asking
-- Match a topic against the shared scratch directory, which holds folders that were never tracks
-- Pause for approval between steps, which the write scope is what makes safe
-
-## Guards
-
-- No topic given: stop rather than inferring one
-- Fewer than two of the three qualifying conditions hold in open mode: stop and route to the planning skill, because the decision is already made
-- Resume and close are exempt from that test by definition
+- Dispatch subagents, since a search too large to run inline is a finding that the question is too broad
+- Close while an open question quietly fails an outcome, or spawn more than three billed headless runs without asking
+- Pause for approval between steps, or open a track with no topic or fewer than two of the three qualifying conditions
 
 ## Out of scope
 
 - Writing the plan the track concludes toward, which `plan-feature` owns
-- Implementing anything the track recommends
-- Persisting the folder. It is gitignored and disposable, which is what makes it the right container for an unanswered question.
+- Filing a breadth dump, which `plan-intake` owns
+- Placing a task row, which `task-board` owns

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

@@ -1,6 +1,6 @@
 ---
 name: plan-groundwork
-description: Opens and runs a numbered groundwork folder under `.canon/groundwork/<nn>-<slug>/` for a topic that has to be measured before it can be planned. Detects open, resume, and close from the folder itself. Use when asked to "research X", "dig into X", "work out what we should do about X", "measure this before we commit", or "open a groundwork folder". Do NOT use to write a feature plan or to implement. That is `plan-feature`.
+description: Opens and runs a numbered groundwork folder under `.canon/groundwork/<nn>-<slug>/` for a topic that has to be measured before it can be planned. Detects open, resume, and close from the folder itself. Use when asked to "research X", "dig into X", "work out what we should do about X", "measure this before we commit", "open a groundwork folder", or "retell the groundwork". Do NOT use to write a feature plan or to implement. That is `plan-feature`.
 metadata:
   family: decide
 ---
@@ -88,6 +88,7 @@ A matched folder routes on its own `<nn>-<slug>/`. Detect the mode from the fold
 
 - Present without `06-decision.md`: resume
 - Present and the user judges it ready: close
+- Present and the user asks for a retell: read the track and end on the retell, measuring and writing nothing
 
 ## Step 2: orient
 
@@ -135,4 +136,6 @@ Aside from an experiment fixture, Steps 4 and 5 are the only ways close mode rea
 
 ## Output
 
-Emit the full relative path from the project root for every file written or updated, since a bare filename names a file the reader cannot open. Read `${CLAUDE_SKILL_DIR}/references/output.md` on reaching this step for the open and resume template and the close template. A run that stops on a guard skips it.
+Emit the full relative path from the project root for every file written or updated, since a bare filename names a file the reader cannot open. Read `${CLAUDE_SKILL_DIR}/references/output.md` on reaching this step for the open and resume template, the retell, and the close template. A run that stops on a guard skips it.
+
+End on the retell in place of the open and resume template once every open question carries a lean. A question marked `none, needs measuring` keeps the open and resume template, unless the operator asks for a retell, which answers whatever the state. The retell lists written files under `**Written:**`, and close keeps its one-line report.

package/claude/skills/plan-groundwork/references/output.md

@@ -1,6 +1,6 @@
 ---
 title: Groundwork output reference
-description: The chat output a groundwork run closes on, one template for open and resume and one for close
+description: The chat output a groundwork run closes on, one template for open and resume, a retell for a fully leaned pass, and one for close
 ---
 
 # Groundwork output reference
@@ -26,6 +26,52 @@ Use `📂 Resumed` in place of `📂 Opened` on a resume pass.
    - Overturned by: <the finding that would change it>
 ```
 
+## Retell
+
+Replaces the open and resume template once every open question carries a lean. It also answers an operator who asks for one, whatever the questions' state. Chat only, and the retell itself writes no file.
+
+Use H2 only, one-line bold-label bullets, and numbers only where they settle something. Stay near 300 words.
+
+- Keep the leans that decide the operator's call, five at most, and fold the rest into one line naming how many more there are and where they sit
+- Label each reversal `Overturned by`, as `groundwork.md` does
+- Drop the held and not held split when the operator gave no hunch to test
+- Put a question marked `none, needs measuring` under `## More measuring` as a yes, since an asked-for retell has no lean to give it
+- List a file the pass wrote or updated under `**Written:**` after the verdict, and omit the block when none was
+
+```plaintext
+**<the verdict in one line>**
+
+**Written:**
+
+- `.canon/groundwork/<nn>-<slug>/<file>.md`
+
+## Problem
+
+<one or two sentences>
+
+## What is true now
+
+- **Held:** <the part of the operator's hunch the evidence supports>
+- **Not held:** <the part it does not>
+
+## Leans
+
+1. <lean>
+   - **Overturned by:** <the finding that would change it>
+
+## More measuring
+
+**<Yes or No>:** <its cost, and what it would decide>
+
+## Dropped
+
+- <what was set aside>
+
+## Your call
+
+<the single decision the operator owes>
+```
+
 ## Close
 
 Omit the uncited-claims block when the count is zero.

package/claude/skills/plan-intake/REQUIREMENT.md

@@ -7,43 +7,28 @@ description: Why a brain dump gets a filed inventory rather than ten plans, and
 
 ## Gap
 
-Without this skill, a brain dump reaches a session that has nowhere to put it. `plan-feature` answers with one plan per independent concern, so forty findings produce ten plan files before anything has been measured. `plan-groundwork` refuses a breadth pass outright, since its qualifying test asks whether the current state is unknown and most items are knowable by grep. What gets filed instead is a list of opinions, because nothing forces a count against the tree and a complaint reads the same whether it covers three sites or three hundred.
+A brain dump reaches a session with nowhere to put it. One plan per concern turns forty findings into ten plans before anything is measured, and what gets filed instead is a list of opinions, because nothing forces a count against the tree.
 
-Two failure modes cost more than the rest. An operator's silence on an item reads as consent when the folder borrows the plan file's blank-means-accept contract, which ships changes nobody approved across a folder read over weeks. And a report naming only a path cannot distinguish three new items from one reworded sentence in a file that holds a dozen items, so every reader diffs it against memory to find out what moved.
-
-Four more are cheaper to name than to rediscover. A question filed without a pick comes back unresolved, measured across one folder's 19 open items, where every one carrying a suggestion resolved on a bare `ok` and the five carrying none did not.
-
-A session with no numbering convention re-decides the folder shape per dump, so no two intakes are readable the same way and the second one has to be learned from scratch. A question answerable both in the index and on its item resolves to whichever a reader opens first, with no rule saying which wins. And a pass with no write scope starts fixing what it files, which turns a triage into a branch nobody asked for and nobody reviewed.
+An empty operator slot reads as consent under a blank-means-accept contract, which ships changes nobody approved. A report naming only a path hides what moved. A question filed without a pick comes back unresolved, and a pass with no write scope starts fixing what it files.
 
 ## Must
 
-- Route each item on whether the repository can answer it today, sending what needs an experiment or an outside source to the groundwork skill and what is already decided to the planning skill
-- Measure every problem line against the tree during this pass, carrying a number or a file path rather than a figure from recall
-- Close every item with a verdict, and pair every open question with a suggested pick
-- Treat an empty operator slot as unread rather than as agreement
-- Reserve the index number and carry the domain in every other filename, leaving the rest of the numbering as read order
-- Name a newly opened folder with a two-digit ordinal ahead of the slug, taken from the highest one already present across intake and groundwork
-- Keep answers on items alone, with the index pointing at them
-- Name the heading and the act beside every path the pass wrote
-- Confine writes to the intake folder
+- Route each item on whether the repository can answer it today, sending experiments to `plan-groundwork` and decided work to `plan-feature`
+- Measure every problem line against the tree, close every item with a verdict, and pair every open question with a suggested pick
+- Treat an empty operator slot as unread, and keep answers on items with the index pointing at them
+- Reserve the index number, carry the domain in every other filename, and number a new folder past the highest ordinal across intake and groundwork
+- Confine writes to the intake folder and name the heading and the act beside every path written
 
 ## Must not
 
 - Write a plan, a task file, a standard, a rule, or a source change
-- Fill an operator's answer slot, or infer a disposition from an empty one
-- Replace a verdict with an overlap line, which drops the call on exactly the items where a live board task might be the thing that is wrong
-- Reserve mid-range numbers, which would force every future intake into one dump's shape
-- Date every file, since the first edit to one leaves the rest stale
-- Open a folder for a single question, which is either a groundwork track or a plan
-
-## Guards
-
-- No dump given: stop rather than inferring one
-- One question rather than a set of findings: stop and route to the groundwork or planning skill
+- Fill an operator's slot, or replace a verdict with an overlap line
+- Reserve mid-range numbers or date every file
+- Open a folder for a single question or for no dump
 
 ## Out of scope
 
 - Measuring one question in depth, which `plan-groundwork` owns
 - Planning a promoted item, which `plan-feature` owns
 - Promoting an item onto the board, which `task-board` owns
-- Enforcing any of this. The folder is gitignored, so no check reaches its contents and every rule holds only while a session reads it.
+- Enforcing any of this, which no check does since the folder is gitignored

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

@@ -113,9 +113,9 @@ Where an item touches a task already on the board, say so in the index rather th
 - **You:**
 ```
 
-- `Problem:`, `Fix:`, `Worth it:`, and the empty `You:` slot ship on every item. The other two are conditional.
+- `Problem:`, `Fix:`, `Worth it:`, and the empty `You:` slot ship on every item, each on one line since the reader takes nothing after it. The other two are conditional.
 - Number items per cluster file, giving a finding split later a letter suffix such as `3a` beside `3`, since renumbering moves every cited label
-- `Suggested:` is required whenever `Open:` is present, since `ok` against two defensible options carries no information
+- `Open:` reads on its own, with no bare "it" or "this" for the Fix, and `Suggested:` is required beside it, since `ok` against two options carries no information
 - Where the answer is the operator's preference rather than a technical call, say so in that form rather than inventing a default
 - `Overlaps:` never replaces `Worth it:`, since an item a live board task might have wrong is the one whose verdict matters most