@erclx/canon 5.52.0 → 5.53.0

package/claude/skills/record-screencast/REQUIREMENT.md

@@ -1,35 +0,0 @@
----
-name: record-screencast
-description: Why compiling and running a screencast draft needs a routed skill rather than an operator typing two verbs by hand, and why the unresolved-field refusal cannot be a suggestion
----
-
-# Record screencast requirement
-
-## Gap
-
-Without this skill, nothing routes a session from a screencast draft to `canon demo compile` and `canon demo run`. An operator has to know both verbs, type them in order, and read the compile record for unresolved fields by hand.
-
-A session that fills an unresolved field in on its own reproduces the failure `plan-unresolved` exists to catch, where nothing enforces it. A take with no composition ships raw, and an unguided one reaches for generic defaults.
-
-## Must
-
-- The default plan path resolves the way `canon demo compile` resolves it, and an existing plan there is run rather than recompiled, since its timing may be tuned by hand
-- Every unresolved field from the compile or run record is reported and the run stops there
-- Every path a run wrote is reported, skipping any the record carries as null
-- The video craft guidance loads before composing, and a draft whose wrap section asks for anything becomes a finished mp4 through HyperFrames, checked before rendering and handed to `read-frames`
-- A wrap section reading `none` throughout stops at the take, and an absent HyperFrames stops with its install command
-
-## Must not
-
-- Pass `--force` to compile, or guess what to compile when no draft path is given
-- Guess or fill a target, a URL, or any other unresolved field
-- Drive the application through anything other than `canon demo run`
-- Install HyperFrames, vendor it, or restate its composition rules
-- Assume anything reaches for this skill beyond `script-screencast`'s closing pointer or an operator, which a later review reads back
-
-## Out of scope
-
-- Drafting the beats, which `script-screencast` owns
-- The captions, zoom, pointer, and audio judgment, which `video-craft` owns
-- Reading the render back, which `read-frames` owns
-- Filling an existing plan's target or URL, which the operator owns

package/claude/skills/record-screencast/SKILL.md

@@ -1,99 +0,0 @@
----
-name: record-screencast
-description: Drives a screencast draft through to a recording. Compiles it with `canon demo compile` when no plan exists yet at the default path, skipping compile when one is already there, runs `canon demo run` once nothing is unresolved, then composes the take into a finished mp4 through HyperFrames when the draft's wrap section asks for anything. Reports every unresolved field from the compile or run record and stops rather than guessing one. Use when asked to "record the screencast", "run the demo", "compile and record this draft", or right after `script-screencast` prints its next-step line. Do NOT use to draft the beats, which is `script-screencast`, or to fill in a plan's target or URL, which is the operator's own edit.
-metadata:
-  family: generate
----
-
-# Record screencast
-
-## Guards
-
-- If no draft path is given, stop: `❌ No draft path. Pass the path script-screencast printed.`
-- Never guess or fill an unresolved field, a target, a URL, or anything else the compile or run record names. Report it and stop.
-- Filling one in reproduces the failure `canon demo run`'s `plan-unresolved` reason exists to catch, one layer up where nothing enforces it
-- Never pass `--force` to compile. A plan at the default output path may carry timing tuned by hand that the draft cannot reproduce.
-- Drive the application through `canon demo run` alone. Never open a browser, click through the app, or write to the output paths some other way.
-
-## Step 1: resolve the plan path
-
-A draft lives at `demos/<slug>/beats.md`, so `<slug>` is the folder holding it and the plan sits beside it at `demos/<slug>/plan.json`. `demos/inline-edit/beats.md` resolves to `demos/inline-edit/plan.json`.
-
-Pass `--slug <slug>` to compile, since its default reads the draft's filename and would name every demo `beats`. A plan compiled before the folder layout sits at `demos/<slug>.json`, so pass it to Step 3 by path when the caller names it.
-
-## Step 2: compile only when no plan exists yet
-
-Check whether the resolved plan path already exists.
-
-- **It exists.** A person may have tuned it by hand since compiling. Skip compiling and go to Step 3 with this path.
-- **It does not exist.** Run:
-
-  ```bash
-  canon demo compile <draft> --slug <slug> --json
-  ```
-
-  Branch on the record rather than the exit code:
-  - `reason: draft-missing` or `reason: draft-unreadable`: report the reason, plus the record's `message` when it carries one, and stop.
-  - No `reason` key, meaning the plan was written: read `unresolved` off the record.
-    - Non-empty: report the plan path and every field the array names, one per line, and stop. Do not proceed to Step 3.
-    - Empty: continue to Step 3 with the record's `plan` path.
-
-## Step 3: run
-
-Run:
-
-```bash
-canon demo run <plan> --json
-```
-
-Branch on the record's `reason`:
-
-| `reason`                                                                                                           | Do                                                                                                      |
-| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- |
-| `plan-unresolved`                                                                                                  | Report every field in `unresolved`, one per line, and stop. A pre-existing plan skipped Step 2's check. |
-| `plan-missing`, `plan-unreadable`, `no-output-requested`, `cursor-unreadable`, `engine-missing`, `browser-missing` | Report the reason, plus the record's `message` or `install` line when it carries one, and stop          |
-| None, meaning the run wrote its output                                                                             | Continue to Step 4                                                                                      |
-
-The take lands in `demos/<slug>/take/`, which git ignores.
-
-## Step 4: compose when the draft asks for it
-
-Read the draft's `## Wrap` section. When intro, outro, and music all say `none`, or the section is absent, stop at the take and go to Step 6, since an empty composition says nothing the take does not.
-
-### Presence test
-
-Otherwise confirm HyperFrames' `hyperframes` skill resolves. `bunx` would fetch the package on a machine without it, which installs by the back door, so the skill is the presence test.
-
-- When it does not resolve, stop and report `bunx -y hyperframes init`, warning that init installs its skills machine-wide without asking
-- Report the take's paths as Step 6 does, so the operator still holds the recording
-- Never install it from here
-
-### Build and render
-
-When it resolves, load it, then load `canon:video-craft` for the captions, zoom, pointer, and audio judgment, reporting it rather than proceeding silently when it does not resolve. Those two skills own the composition rules, so this body states none.
-
-Build `demos/<slug>/index.html` around the take with the intro, outro, and music the wrap names, aiming each zoom from the timeline the run wrote beside the take. Then run both from `demos/<slug>/`:
-
-```bash
-bunx -y hyperframes check
-bunx -y hyperframes render --quality delivery --output renders/<slug>.mp4
-```
-
-Report a failing check, with the take's paths, and stop rather than rendering past it. The render sits in `demos/<slug>/renders/`, which git ignores.
-
-## Step 5: read the render
-
-Hand the render to `read-frames` as its video path, so the composed result is checked rather than only the raw take.
-
-## Step 6: output
-
-The record carries `video`, `mp4`, `gif`, `still`, and `timeline`, each a path or `null`. Report each one that is not `null`, one per line, and add the render path when Step 4 wrote one.
-
-| Output     | Name it as                                            |
-| ---------- | ----------------------------------------------------- |
-| `mp4`      | The deliverable                                       |
-| webm       | The raw take                                          |
-| `gif`      | The form for a host that strips video                 |
-| `timeline` | The per-step timing a composition aims its zooms from |
-
-Say so plainly if `canon demo compile` or `canon demo run` is not available, rather than driving the application some other way. Both ship with the CLI and this skill ships with the plugin, so a project carrying one and not the other is a real state.

package/claude/skills/script-screencast/REQUIREMENT.md

@@ -1,34 +0,0 @@
----
-name: script-screencast
-description: Why a recording script ships pre-seeded rather than blank, what the four discovery questions buy, and why the draft stays stack-agnostic
----
-
-# Script screencast requirement
-
-## Gap
-
-Without this skill, a recording plan arrives as blank fields, so the user fills a template instead of editing a draft. The opposite failure costs more. A session skipping discovery guesses the audience, the length, and the hero moment, and writes beats that get thrown away. What surrounds the take surfaces only at compose time.
-
-A draft naming the recording software, the editing software, or the window manager pins the script to one person's setup. Re-invoking to refine silently overwrites the edits the user made in the file, which destroys work rather than wasting it.
-
-## Must
-
-- Project context and recent commits are read before proposing, and exactly four discovery questions each carry a default derived from them
-- The run waits for answers rather than reading silence as acceptance
-- Every section is pre-seeded with concrete content, so the draft ships as written and the user edits down
-- The draft lands at `demos/<slug>/beats.md` at the project root, with the slug derived from the topic and the answers, and its path printed on its own line
-- A wrap section names intro, outro, and music with a default each
-
-## Must not
-
-- Name recording software, editing software, fonts, or window managers
-- Record, edit video, or generate captions
-- Re-run against an existing draft to refine it, since re-running overwrites
-- Infer the hero moment without asking, or guess the topic when none is given
-
-## Out of scope
-
-- Producing the recording, which `record-screencast` owns
-- Slide decks, which `make-deck` owns
-- Refining an existing draft, which a direct edit of the file owns
-- Where the recording ships, which the user owns

package/claude/skills/script-screencast/SKILL.md

@@ -1,70 +0,0 @@
----
-name: script-screencast
-description: Drafts a screencast script with pre-seeded beats, defaults, and decisions to `demos/<slug>/beats.md`. Reads project context, asks four discovery questions with proposed defaults, then writes a shippable draft. Use when asked to "draft a screencast", "write a recording script", "plan a demo video", or "scaffold a screencast for X". Do NOT re-invoke to refine an existing draft. Re-running overwrites. Edit the draft file directly.
-metadata:
-  family: generate
----
-
-# Script screencast
-
-## Guards
-
-- If no topic is provided, stop: `❌ No screencast topic. Describe what you are recording.`
-- Draft, then hand off. Do not edit video, generate captions, or drive the application, since a recording is `record-screencast`'s job. Name it as the next step and stop.
-- Stack-agnostic in the draft. Never name a recording tool, an editing tool, a font, or a window manager.
-- Keep selectors, URLs, wait conditions, and timings out of the beats, since the compiler adds those four in a plan of its own and a beat carrying them stops being readable
-
-## Step 1: read the project context
-
-Read these in parallel from the project root, skipping any that do not exist:
-
-- `CLAUDE.md`: behavior rules and project pitch
-- `canon/REQUIREMENTS.md`: feature scope, non-goals, audience hints
-- `.canon/tasks/index.md`: current scope
-- Recent commits via `git log --oneline -20 2>/dev/null || echo "FALLBACK"`: what shipped recently is usually the recording subject.
-
-## Step 2: discovery with proposed defaults
-
-Ask exactly four questions in chat. Each carries a proposed default derived from Step 1. The user confirms, overrides, or says "use defaults" to accept all.
-
-```markdown
-**Discovery:**
-
-1. Audience: proposing technical peers. Override?
-2. Length: proposing 75-90s. Override?
-3. Hero moment: proposing <best guess from context, or "the single thing that has to land">. Override?
-4. What to cut: proposing <best guess, or "anything that is not the hero moment">. Override?
-```
-
-Wait for answers before drafting. Do not infer silence as acceptance.
-
-## Step 3: derive the slug
-
-Build a 2-to-4-word kebab-case slug from the topic and discovery answers. Examples: `auth-flow-redesign`, `cli-onboarding`, `inline-edit-launch`.
-
-## Step 4: write the draft
-
-Create `demos/<slug>/beats.md` at the project root, creating the folder if it does not exist. The file is committed with the rest of the demo's sources, so a recording can be rebuilt from the folder alone.
-
-### Fill the template
-
-Write all nine sections from `${CLAUDE_SKILL_DIR}/references/beats-template.md`, read on reaching this step. Pre-seed every section with concrete content so the draft ships as-is, and the user edits down rather than fills blanks. A run stopped at discovery skips it.
-
-Load `canon:video-craft` for every zoom and caption value the draft names, and report it rather than proceeding silently when it does not resolve.
-
-## Step 5: output
-
-Print the file path on its own line and a one-line summary. Do not paraphrase the path into prose.
-
-```markdown
-📝 Wrote demos/<slug>/beats.md
-
-Draft has 5 beats and pre-seeded defaults. Edit the beats, the resolved decisions, and the wrap.
-
-To record it rather than shoot it by hand:
-record-screencast demos/<slug>/beats.md
-```
-
-Name the skill and stop there. Do not compile the draft, do not run it, and do not generate captions. The operator edits the beats first, and the compiler reports which selectors and URLs they still owe it.
-
-Say so plainly if `canon demo compile` is not available, rather than driving the application some other way. The command ships with the CLI and the skills ship with the plugin, so a project carrying one and not the other is a real state.

package/claude/skills/script-screencast/references/beats-template.md

@@ -1,119 +0,0 @@
----
-title: Beats template
-description: The nine-section template script-screencast writes to demos/<slug>/beats.md, pre-seeded so the draft ships as-is
----
-
-# Beats template
-
-Applies to the draft `script-screencast` Step 4 writes. Fill every placeholder from the project context and the discovery answers. The template states no zoom or caption value, since each traces to a source `canon:video-craft` records.
-
-## Template
-
-```markdown
-# Screencast: <short title>
-
-## 1. Header
-
-- Audience: <from discovery>
-- Length: <from discovery>
-- Hero moment: <from discovery>
-- Pitch: <one sentence, derived from project context>
-
-## 2. Pre-recording checklist
-
-- [ ] Browser at 1920x1080 with notifications silenced
-- [ ] Session storage and history cleared for the recorded surfaces
-- [ ] Cursor highlighter on
-- [ ] Live URLs and fixtures verified healthy
-- [ ] <one or two project-specific items derived from context>
-
-## 3. Beat sheet
-
-Five beats. Each uses five fields. Add a sixth `Transition out` only when non-default.
-
-### Beat 1: Cold open
-
-- On screen: <derived from hero moment>
-- Action: <one verb, derived>
-- Watch for:
-- Emphasis: zoom onto the action, scale and speed per `canon:video-craft`
-- Caption:
-
-### Beat 2: Setup
-
-- On screen:
-- Action:
-- Watch for:
-- Emphasis: none
-- Caption:
-
-### Beat 3: Hero moment
-
-- On screen: <hero moment from discovery>
-- Action:
-- Watch for:
-- Emphasis: highlight overlay
-- Caption:
-
-### Beat 4: Payoff
-
-- On screen:
-- Action:
-- Watch for:
-- Emphasis: none
-- Caption:
-
-### Beat 5: Outro
-
-- On screen:
-- Action:
-- Watch for:
-- Emphasis: zoom out to full frame
-- Caption:
-
-## 4. Sequencing notes
-
-- Hover before click. The cursor needs a beat to register.
-- Do not cut mid-reset. Let state changes complete on screen.
-- Cut on action, not on stillness.
-- <one or two project-specific gotchas derived from context>
-
-## 5. Production notes
-
-- Resolution: 1920x1080
-- Frame rate: 30fps
-- Container: mp4 H.264
-- Zoom: only on an action too small to read at full frame, scale, speed, and dwell per `canon:video-craft`, zoomed out before every cut
-- Highlight overlay: ~1.5s soft glow
-
-## 6. Captions
-
-- Each caption names what its beat's frame shows, at most two lines of 42 characters, per `canon:video-craft`
-- Hold and reading rate per `canon:video-craft`, splitting a caption across beats rather than shortening its hold
-- Placed off the element the beat acts on
-
-## 7. Distribution
-
-Where the recording ships. Strike rows that do not apply.
-
-- [ ] Native upload to social platform
-- [ ] Canonical host (long-form video platform)
-- [ ] Linked from project README or release notes
-
-## 8. Resolved decisions
-
-Pre-seeded with the common picks. Strike or rewrite as needed.
-
-- Audio: silent plus captions
-- Language: English
-- Chip order: <leave for user, derived from beats>
-- Thumbnail: hero-moment frame
-
-## 9. Wrap
-
-What surrounds the take in the finished video. Each row carries a proposed default. Write `none` on every row to ship the raw take.
-
-- Intro: <proposed title card of two to three seconds naming the subject, or `none`>
-- Outro: <proposed closing card naming where to go next, or `none`>
-- Music: none
-```

package/claude/skills/teach-workspace/REQUIREMENT.md

@@ -1,34 +0,0 @@
----
-name: teach-workspace
-description: Scope boundary for learning a subject across sessions, and the split between the disposable lesson and the durable reference page
----
-
-# Teach workspace requirement
-
-## Gap
-
-Without this skill, a session asked to teach answers in the conversation, so everything dies with it. It teaches from recall, picks topics from the subject's order rather than the learner's errors, and asks nothing about what they know. A structure lesson points at a diagram and ships none.
-
-A worked-through page and a looked-up page have different lifetimes, and merging them yields disposable material kept or durable material carrying a quiz. Opened by bare path, a lesson renders unstyled. A workspace resolved against the current directory forks per worktree, and the editing tools refuse a main-root write from one.
-
-## Must
-
-- Hold the workspace at the main worktree root, name the write route from a linked worktree, and route edits to an existing workspace file through a verb that resolves the root
-- Ask the learner's starting point, research from sources chosen by the teach standard's ladder, and place each lesson from the learning records
-- Split the output by lifetime into lessons and reference pages, record the wrong answer itself rather than a count, and decide each lesson's figure before its body
-- Hand the learner a link to the workspace in a real browser on every run, read back from the verb that served it
-- Propose each durable page's destination by who owns its subject, wait for the operator, and hand the page off through a named file a branch lands and deletes
-
-## Must not
-
-- Teach from recall without saying which claims rest on it
-- Write to a destination surface outside the fold mode, or overwrite a file a promotion block routes to
-- Promote a lesson at any age, since it is generated markup carrying a quiz
-- Open a second workspace on a covered subject, or renumber anything
-- Scaffold a wiki folder the project never chose
-
-## Out of scope
-
-- What the verbs do internally, which the `canon teach` CLI domain owns
-- What a lesson renders as and how its quiz behaves, which the lesson-craft reference and the rendering layer own
-- Firing on a description match, since opening a workspace is the learner's call

package/claude/skills/teach-workspace/SKILL.md

@@ -1,196 +0,0 @@
----
-name: teach-workspace
-description: Opens and runs a learning workspace on one subject, holding a mission, resources, numbered lessons, reference pages, a glossary, and learning records that survive across sessions, proposes where a durable page from one belongs once it outgrows the workspace, and lands the confirmed pages from a branch. Use when asked to "teach me X", "open a learning workspace", "I want to learn X", "quiz me on this", "continue the lesson", "resume my workspace on X", "promote this reference page", or "fold the promoted pages in". Do NOT use to write project documentation, which belongs to the surface owning that document, and do NOT use to answer one question, which is an ordinary reply. Do NOT auto-trigger.
-argument-hint: <subject to learn, the topic of a workspace to resume or promote, or fold>
-metadata:
-  family: answer
----
-
-# Teach workspace
-
-Run a learning workspace on one subject across sessions. The workspace holds what the learner has been through, so a session weeks later resumes from the folder rather than from the conversation.
-
-## References
-
-Read `${CLAUDE_SKILL_DIR}/references/teach.md` before writing anything into the folder, since it fixes the workspace's shape. The glossary answers to `${CLAUDE_SKILL_DIR}/references/glossary.md` wherever it lands.
-
-The pedagogy sits in `${CLAUDE_SKILL_DIR}/references/pedagogy.md`, the lesson craft and its build in `${CLAUDE_SKILL_DIR}/references/lesson-craft.md` and `lesson-build.md`, the revisit schedule in `revisit.md`, and the promotion routing in `${CLAUDE_SKILL_DIR}/references/promotion.md`.
-
-## Guards
-
-- If the invocation names no subject and no existing workspace matches, stop: `❌ No subject. Invoke with the subject to learn, or the topic of a workspace to resume.`
-- Never trust recall for what the subject says. Research first, cite what was read, and say what was not.
-- Write nothing outside the workspace folder, apart from the one handoff file Step 6 names and the destinations the fold mode lands from that file
-- A durable page stays in `reference/` until the operator confirms a destination, and only the fold mode copies it out, from a branch
-
-### Workspaces and promotion
-
-One subject takes one workspace, and only its reference pages ever leave it.
-
-- Do not open a second workspace on a subject one already covers. Resume that one.
-- Never promote a lesson. It is generated markup carrying a quiz and a learner, and no request makes it promotable.
-- Never write a favicon link by hand. `canon teach nav` puts the toolkit's icon on every page and in a lesson's `style` region, so a hand-written one gives the page two.
-
-## Step 0: let the CLI resolve the workspace root
-
-Workspaces live at the main worktree root, never inside a linked worktree. A copy per worktree forks the learning records, and the learner is one person.
-
-Every `canon teach` verb resolves that root in-process, so no step below composes a path to a workspace file. Read the folder through the CLI:
-
-```bash
-canon teach list --json
-```
-
-It reports every workspace with its path, its counts, and the ordinal a new one would take. A `no-teach` refusal means the project has opened none yet, which is Step 1's new-workspace path, and the open verb creates the folder.
-
-Every path under the main root is a main-root write, routed the way `session-worktree` states. The route splits by what the write does to the file:
-
-- Creating a whole file that does not exist yet, which is a lesson, a reference page, and a learning record, goes out as a heredoc
-- Changing a line inside a file that already exists goes through the verb that owns it
-
-## Step 1: open or resume
-
-A topic the listing already carries is a resume, and anything else is a new workspace. Two invocations are neither.
-
-- One asking to promote reads the named workspace through the listing and goes to Step 6, which teaches nothing and writes no lesson
-- One asking to fold confirmed promotions in goes to `## Fold mode`
-
-### On a resume
-
-Run `canon teach list <topic> --json` for the files behind each count, then read the highest-numbered learning record and `GLOSSARY.md`, which carry where the learner stopped and what they got wrong.
-
-- The record's `success` holds the mission's success lines, the exit criteria. Report them with what is already met before teaching anything.
-- `due` lists what the learning records schedule, soonest first, each with its item, date, rung, `overdue` flag, and the two dates the next record could write
-- Read `due` here, since `canon teach lesson` takes a `--slug` naming a choice already made. Report what is overdue before proposing a lesson.
-- An empty `due` on a workspace holding records means no record scheduled anything, which is a gap in the records rather than a clear schedule
-
-### On a new workspace
-
-Settle the starting point first, by asking rather than by assuming. Difficulty with no floor under it teaches nobody, and the mission cannot be written without it. Then open the workspace, which derives the ordinal and writes all three required files:
-
-```bash
-canon teach open <topic> --json \
-  --subject "<one line stating the subject>" \
-  --starting-point "<what the learner already knows>" \
-  --success "<an observable thing the learner will be able to do>" \
-  --out-of-scope "<what this workspace does not cover>"
-```
-
-Repeat `--success` and `--out-of-scope` per line. The verb refuses a topic another workspace already covers, which is the guard against opening a second one on the same subject.
-
-## Step 2: research before teaching
-
-Read the subject from sources rather than from recall, chosen by the standard's `### Choosing sources` ladder, with a third-rung source's reason in its title. Record what was read and what was only found through the verb that owns the file:
-
-```bash
-canon teach resource <topic> --json \
-  --read "<title, naming which claims rest on it>=<url>" \
-  --lead "<title>=<url>"
-```
-
-Each flag repeats, and the pair splits on the first `=` so a URL carrying one survives. A listed URL is refused, but `--read` moves an opened lead.
-
-A claim nothing was read for is the failure this step exists against. Where no source is reachable, say so in the lesson and mark what rests on recall.
-
-## Step 3: place the learner
-
-Pick the next lesson from the learning records rather than from the subject's own order. The target is the band immediately past what the learner can already do unaided, which `${CLAUDE_SKILL_DIR}/references/pedagogy.md` states in full.
-
-- Open on what `due` reports as overdue, oldest date first, before anything new
-- Where nothing is overdue, open on retrieval of what the last session got wrong. A learner who cannot retrieve the previous lesson is not ready for the next one.
-- Never place from the last record alone, since a topic missed three sessions ago is invisible to that read and sits in `due` with a date already past
-
-## Step 4: write the lesson and the reference
-
-Two outputs with two lifetimes, and the split decides the format.
-
-- A lesson is a self-contained page carrying its own quiz, a teach-back block, and feedback per question, embedding one shared stylesheet. It is disposable and never promoted.
-- A reference page goes to `reference/<slug>.md`, written for a reader with no learner in it. It is the half that survives, so it passes the authoring gates a promotion applies.
-- A lesson's `refs` pass the source ladder, and a learner's or organization's file goes in the body, labeled
-- `canon teach nav` renders a reference to a `reference/<slug>.html` sibling, and a lesson links that sibling, since a served `.md` opens as plain text
-
-### Resolve the lesson
-
-Resolve the lesson before writing it, rather than composing its name or its quiz order by hand:
-
-```bash
-canon teach lesson <topic> --json \
-  --slug <kebab slug for what this lesson covers> \
-  --questions <how many questions the quiz carries> \
-  --options <how many options each question carries>
-```
-
-It writes nothing and reports three things:
-
-- `lesson`, the numbered path the lesson takes. Write it there.
-- `success`, the mission's success lines, carried here so Step 5 needs no second read.
-- `quiz`, one entry per question, carrying `order` and `answer`.
-
-Write the correct option first, then present the options in the order `order` reports, as authored indices where `0` is the correct one. Take the order as given, since a lesson that reorders by judgment puts the answer back in the first slot.
-
-### The quiz, the teach-back block, and the lesson body
-
-Read `${CLAUDE_SKILL_DIR}/references/lesson-craft.md` before writing the lesson. Its `## Quiz construction` and `## Teach back` fix the markup `canon teach nav`'s stepper gates on, and a quiz in any other shape shows every question at once with nothing reporting it.
-
-- Then read `${CLAUDE_SKILL_DIR}/references/lesson-build.md` for the block list, the four marker pairs, the render, nav, stylesheet, and glossary verbs, and the rule against hand-composing any of them
-- Keep every quiz answer the same length, so formatting leaks no clue about which one is correct
-- Decide the figure first, by `## Diagrams` in `lesson-craft.md`
-
-### Hand over a link, never a path
-
-A lesson is a page carrying a script, and an editor preview cannot run it, so a path alone opens markup with no working quiz. Serve the teach root and give the learner a link. One verb refreshes every page's chrome and serves the folder from the main worktree root:
-
-```bash
-canon teach up <topic> --json
-```
-
-- Where the installed CLI predates `up`, run the line the `Open` step of `canon teach list <topic>` prints, with `--json` appended
-- Never hand-write `canon serve .canon/teach`, which serves an absent folder from a linked worktree
-- Start it in the background and read `url` off the record, since the verb walks past a port already in use and a guessed URL gets that port wrong
-- Report the refusal and its `reason` when `ok` is false, and report it rather than proceeding silently when the verb does not resolve at all
-- Do this on every run that opens or resumes a workspace, including one that writes no lesson, since the learner's route in is the same link
-
-## Step 5: record what happened
-
-Write `learning-records/<nnnn>-<slug>.md` before the session ends, carrying the lessons covered, what the learner retrieved unaided, what they got wrong with the wrong answer itself, and a `## Revisit` section.
-
-- Record the wrong answer rather than the count. The next session places the learner from this file, and a tally carries no misconception to work against.
-- Record what the teach-back left out under what the learner got wrong, naming the concept and where the explanation broke, since both are retrieval failures one section holds
-- Read `${CLAUDE_SKILL_DIR}/references/revisit.md` before writing `## Revisit`, for the bullet shape, where each date and rung comes from, and an unscheduled item's first schedule
-
-### Restate the mission
-
-Restate the mission's success lines from the `success` the lesson verb reported, rather than from `MISSION.md` by eye. Report each line as met or not met, and name what the learner did that meets it.
-
-A mission whose lines are all met is finished, and saying so is what closes a workspace.
-
-## Step 6: propose where the durable half belongs
-
-Run this when the invocation asks for it, or offer it in one line when a mission finishes, since its reference pages then stop changing. Never run it unasked mid-course.
-
-Read `${CLAUDE_SKILL_DIR}/references/promotion.md` first. It carries what may be promoted, the routing test, the wiki folder and its refusal, each destination's expectations, and under `## Proposing and handing off` the proposal, the handoff file, and the fold instruction. Propose and wait, and write nothing to a destination here.
-
-## Fold mode
-
-Run this only when the invocation asks to fold, and only from a branch in a linked worktree, since every destination is a tracked file committing with the branch while the handoff sits in gitignored scratch at the main root.
-
-Read `${CLAUDE_SKILL_DIR}/references/promotion-fold.md` for how each block lands, the overwrite refusal, the handoff delete, and the output lines, which replace the Output block below.
-
-## Output
-
-```plaintext
-✅ <opened|resumed> .canon/teach/<nn>-<topic>/
-Lesson:    .canon/teach/<nn>-<topic>/lessons/<nnnn>-<slug>.html
-Reference: .canon/teach/<nn>-<topic>/reference/<slug>.md
-Record:    .canon/teach/<nn>-<topic>/learning-records/<nnnn>-<slug>.md
-Figure:    <drawn through draw-figure, or the one-line reason prose carries it>
-Progress:  <n> of <m> success lines met
-Open:      [<the url the serve verb reported>](<the same url>)
-```
-
-- Omit the reference line where the lesson produced no durable page
-- Never omit the open line, the learner's only route into the page. It carries what the serving verb reported, or names the refusal where the verb refused.
-- Write that line as a markdown link with the URL as both text and target, never a bare URL or a code span the reader has to copy
-- Emit every path from the project root, in the form the project's instruction file sets
-
-A promotion pass reports the shape `${CLAUDE_SKILL_DIR}/references/promotion.md` gives at the end of `## Proposing and handing off` instead.