@erclx/canon 5.52.0 → 5.53.0

package/claude/skills/teach-workspace/references/glossary.md

@@ -1,90 +0,0 @@
----
-title: Glossary reference
-description: Frontmatter, entry shape, ordering, and the rules deciding which terms a glossary carries
----
-
-# Glossary reference
-
-Applies to a glossary, the file holding one entry per term a body of material defines. It changes whenever the material names a concept a reader cannot look up yet, and it is revised in place rather than appended to.
-
-## Scope
-
-Governs a glossary at `.canon/teach/<nn>-<topic>/GLOSSARY.md` and at whatever path a surface fixes for one it holds: its frontmatter, entry shape, ordering, grouping, and the rules deciding which terms it carries.
-
-Does not govern:
-
-- The folder a learning workspace lays out around its glossary, and the other files in it: `teach.md`
-- Which surface a glossary moves to once it leaves the material that produced it, which belongs to the surface driving that move
-- Voice, rhythm, and sentence construction: the `write-human` skill
-- Headings, punctuation, word choice, and file references: `markdown.md`
-
-## What a working glossary looks like
-
-A glossary works when a reader who meets a term in the material settles it here without opening the page that introduced it:
-
-- Which word does this material use for the concept, and which words does it deliberately not use?
-- What does the term mean, stated without leaning on the term itself?
-- Where does the term appear, so a reader can see it used rather than only defined?
-- Does every entry carry a term the material actually uses?
-
-A glossary failing these is non-conforming even when it satisfies every shape rule below.
-
-## Frontmatter
-
-- `title` (required): names the material the terms come from, in sentence case
-- `description` (required): one line naming what a reader gets from the entries
-
-## Entries
-
-- Write one entry per term, as a single bullet.
-- Lead the bullet with the term as a bolded span, then the definition in one or two sentences.
-- Define the term without using it. A definition that spends the term explains nothing to the reader who arrived not knowing it.
-
-### Placement and order
-
-Each entry points at its first use and sits where a reader would look for it.
-
-- Name where the term first appears, so a reader can reach one use of it in context.
-- Keep an entry to the meaning. Worked detail belongs on the page that teaches the term.
-- Sort entries alphabetically, so a reader who knows only the word finds it without reading the file.
-
-## Which terms it carries
-
-- Add a term once the material has used it, never ahead of that. A glossary front-loaded with terms nothing has introduced is a syllabus rather than a reference.
-- Pick one word per concept and use that word everywhere. A glossary carrying two words for one thing hands the reader a choice it exists to remove.
-- List each rejected synonym as an alias to avoid inside the entry that won, so a reader arriving with the wrong word lands on the right one.
-- Use the glossary's own terms inside other definitions. A definition reaching for a synonym of a term defined two entries down teaches the reader a word the material does not use.
-- Revise an entry the material has moved under rather than adding a second one narrating the change.
-
-## Grouping
-
-- Keep a short glossary as one alphabetical list under the title. Grouping a handful of entries costs a heading per category and saves no lookup.
-- Group a glossary long enough that one list stops helping under `##` headings by category, sorted alphabetically within each. Roughly two screens of entries is the signal.
-- Name each category so a reader picks it from the term alone. A category a reader cannot predict makes the grouping a second thing to search.
-- State a departure from any rule above in the file itself, naming what it departs from and why
-- A glossary serving no single body of material is the case that produces one, since a term drawn from everywhere has no first appearance to name
-
-## Rendered grouping
-
-Applies to a rendered glossary page, never to the source file above, which stays the flat alphabetical list the `## Grouping` rules above govern.
-
-- Group a rendered glossary by the lesson its own "First seen in" citation names, ordered by lesson order, under a sub-heading naming the lesson's title rather than its filename.
-- Trail with an "Other terms" group holding any entry the citation cannot attribute to a lesson, whether it names a reference page or carries no citation
-- Keep "Other terms" in the alphabetical order the source file already carries
-- Keep the workspace-wide term filter matching against every group, and drop a group's own heading once filtering leaves nothing under it.
-
-## Template
-
-```markdown
----
-title: <Material the terms come from>
-description: <one line naming what a reader gets from these entries>
----
-
-# <Material the terms come from>
-
-<One line on which material these terms come from and when the file changes.>
-
-- **<Term>**: <the meaning in one or two sentences, written without using the term>. Avoid <rejected synonym>. First appears in `<page or lesson>`.
-- **<Term>**: <the meaning in one or two sentences, written without using the term>. First appears in `<page or lesson>`.
-```

package/claude/skills/teach-workspace/references/lesson-build.md

@@ -1,106 +0,0 @@
----
-title: Lesson build reference
-description: The block list canon teach render takes and the verbs that build the lesson body, being render, nav, stylesheet, and glossary
----
-
-# Lesson build reference
-
-Mechanics rather than judgment. `lesson-craft.md` covers what a lesson should be, and this file covers how its body reaches the page through the verbs.
-
-## The block list
-
-`canon teach render` takes a JSON array of blocks and renders it through the same components a lesson body composes. Six types, and every structural body composes from them:
-
-- `{"type":"heading","level":1|2,"text":"<text>"}`: an `<h1>` or `<h2>`.
-- `{"type":"paragraph","text":"<text>","lede":true,"cites":[1]}`: a `<p>`, marked `lede` for the opening dek. `cites` adds a footnote marker per reference number, and a lede takes none.
-- `{"type":"list","items":["<text>", ...],"ordered":true}`: a `<ul>` or, with `ordered`, an `<ol>`.
-
-### Reference, code, and raw blocks
-
-The other three carry sources, code, and markup the components cannot.
-
-- `{"type":"refs","items":[{"title":"<name>","url":"<https URL>","note":"<text>"}, ...]}`: the one reference list, numbered from 1. `url` and `note` are optional, and a `url` must be http or https.
-- `{"type":"code","lang":"ts","text":"<source>"}`: a sample highlighted at render time with no script. `lang` is optional and takes a highlight.js name or alias, and an unregistered one renders plain.
-- `{"type":"raw","html":"<markup>"}`: the escape hatch, passed through unescaped.
-
-### Where code and raw go
-
-Code never travels through `raw`. A hand-written `<pre><code>` renders with no color, and `nav` never highlights markup already in a body, so it stays plain for good. A fenced block in a reference page's markdown is highlighted by `nav` on its own.
-
-The quiz and teach-back block in `lesson-craft.md` always need `raw`, since their fixed contract is not a components concern. Give them the array's last `raw` entry, followed only by `refs`, and use `raw` nowhere the other types could carry the content.
-
-### Citing
-
-A claim resting on a source carries a `cites` number, and the source goes in the lesson's one `refs` block rather than the sentence.
-
-- Draw every reference from what `canon teach resource --read` recorded, never from a lead, since a lead is a source nobody opened
-- Render refuses a cite no reference resolves, so number the list before citing into it
-
-## Building the lesson body
-
-Step 4 of `teach-workspace` reads this section before writing a lesson, after the lesson verb has resolved its path and quiz order. Write the chrome as four empty marker pairs rather than composing it by hand.
-
-- `<!-- canon:teach:style -->` and `<!-- /canon:teach:style -->` inside `<head>`
-- `<!-- canon:teach:header -->`, `<!-- canon:teach:footnav -->`, and `<!-- canon:teach:scripts -->`, each with its own close marker, in that order in `<body>`
-
-### Render the body
-
-Build the authored `<h1>`, lede, body, and quiz as a JSON array of blocks, and render it through the verb rather than a component import:
-
-```bash
-echo '[
-  {"type":"heading","level":1,"text":"<title>"},
-  {"type":"paragraph","lede":true,"text":"<the dek>"},
-  {"type":"paragraph","text":"<a body paragraph>"},
-  {"type":"paragraph","text":"<a claim resting on a source>","cites":[1]},
-  {"type":"list","ordered":true,"items":["<step one>","<step two>"]},
-  {"type":"raw","html":"<the quiz and teach-back block composed per lesson-craft.md>"},
-  {"type":"refs","items":[{"title":"<source name>","url":"<https URL>"}]}
-]' | canon teach render --json
-```
-
-`## The block list` above states each type and where `raw` belongs. Write the call's `html` field between the header's close marker and the footnav's open marker, and nothing else anywhere in the file.
-
-### When a verb does not resolve
-
-Every verb in this section can be missing from an installed CLI that predates it. Report that rather than proceeding silently, and never hand-compose the body, the chrome, or a palette as a fallback.
-
-A hand-composed body is the state this section exists to end. A target holds this skill body before the verb, since a plugin skill reaches a target on merge while the CLI arrives only when a release publishes.
-
-### Fill the chrome
-
-Then run:
-
-```bash
-canon teach nav <topic> --json
-```
-
-It fills every marker pair from what the workspace holds on disk, and rewrites the workspace's contents page and the teach-root listing in the same run.
-
-- The markers take the embedded stylesheet, the header with its breadcrumb and jump menus, the prev and next footer nav, and the behavior scripts
-- It refuses a lesson missing a marker pair by name rather than guessing the boundary, so a dropped marker is caught here rather than read back as a lesson nothing links to
-
-### Seed the stylesheet
-
-On the first lesson in a workspace, seed the stylesheet through the verb rather than authoring a palette:
-
-```bash
-canon teach stylesheet <topic> --json
-```
-
-It writes the design tokens as custom properties and the components built on them, from the one source every rendered surface reads.
-
-- Add lesson rules under the seed, and reach a value through its property rather than restating the hex, which is how each workspace forked the palette
-- It refuses to overwrite, so a rerun on a workspace with its own rules is safe and reports `written` as false
-
-### Add glossary terms
-
-Add every term the lesson defines to `GLOSSARY.md` through the verb, which places entries alphabetically in the shape the standard fixes:
-
-```bash
-canon teach glossary <topic> --json \
-  --term "<term>=<definition, written without using the term>" \
-  --first-seen <the lesson or reference page this batch comes from>
-```
-
-`--term` repeats and one call writes the file once, which keeps a batch of terms from racing on it. A term already defined is refused, since a definition the subject has moved under is a revision of the entry rather than a second one.

package/claude/skills/teach-workspace/references/lesson-craft.md

@@ -1,135 +0,0 @@
----
-title: Lesson craft reference
-description: Typography, restraint, quiz construction, and what makes a lesson worth returning to
----
-
-# Lesson craft reference
-
-Judgment rather than shape. The workspace standard fixes where a lesson sits and what it is named, and this file covers what makes one worth opening twice. The block list and the verbs that build the lesson body sit in `lesson-build.md`.
-
-## Contents
-
-- [One course, not a pile of pages](#one-course-not-a-pile-of-pages)
-- [Typography](#typography)
-- [Restraint](#restraint)
-- [Diagrams](#diagrams)
-- [Quiz construction](#quiz-construction)
-- [Teach back](#teach-back)
-- [Tokens travel with the course](#tokens-travel-with-the-course)
-- [What makes a lesson worth returning to](#what-makes-a-lesson-worth-returning-to)
-
-## One course, not a pile of pages
-
-A workspace accumulates lessons over weeks. The learner reads them as one body of material, so a lesson that invents its own look reads as someone else's work.
-
-- `canon teach nav` embeds and re-embeds the shared stylesheet into every lesson on each run, so growing that stylesheet, by promoting anything used a second time into it, is the only step left by hand.
-- Keep the structural furniture identical across lessons: where the title sits, where the quiz sits, what a correct answer looks like
-- Do not restate styles inside a lesson. A local override is a decision the next lesson has to either copy or contradict.
-- Refer to another lesson in the workspace as "lesson" plus its four-digit number, such as "lesson 0003". `canon teach nav` links the mention and reports a number naming no lesson.
-- Never hand-write a link to another lesson, the one form nav never checks
-
-## Typography
-
-The learner is reading, so the reading surface is the product.
-
-- Set body text at a comfortable reading size with generous line height, and hold the measure to roughly 65 to 75 characters
-- Use one typeface for prose and one for code, and no others
-- Build hierarchy from size and weight rather than from color. Color that carries meaning fails for a reader who cannot see it.
-- Give code blocks room. Cramped code is the part of a lesson a learner skips.
-
-## Restraint
-
-Every element competes with the material for attention.
-
-- Cut any decoration that carries no information
-- Use at most one accent color, reserved for the thing the learner acts on
-- Do not animate anything the learner did not trigger
-- Prefer whitespace over rules and boxes to separate sections
-
-## Diagrams
-
-Decide the figure once per lesson, before writing the body.
-
-1. Name the one relationship, boundary, path, or before-and-after the lesson is about. A lesson about none ends here, with `Figure: none, <why it names no structure>` on the reply.
-2. Hold it against the bar in `${CLAUDE_SKILL_DIR}/../draw-figure/references/figures.md`, which also carries the drawing rules.
-3. Draw it through `canon:draw-figure` into a `raw` block before the quiz, never inside it or after its feedback, which breaks the stepper's gating. Report an unresolved skill rather than drawing.
-4. Or write one line on why prose carries it better, such as a structure an earlier lesson gave.
-
-A structure lesson takes step 3 or 4, never neither. Put the outcome on the reply's `Figure:` line, off the lesson page. Never draw to satisfy the step, or on every section (`## Restraint`).
-
-## Quiz construction
-
-The quiz is the retrieval, so a leak in its construction turns it into a reading test.
-
-- Write every option to the same length, in words and in characters. A longer option reads as the considered one.
-- Write the correct option first and let the ordering verb place it. An author varying position by hand varies it by judgment, which settles on the first slot.
-- Make each wrong option a misconception someone actually holds. An obviously wrong option removes itself and shrinks the question.
-- Write one feedback block per question, covering the correct option and why each distractor fails, saying why rather than whether
-- Give feedback after the attempt, never alongside the question
-
-One feedback block reads as an explanation where a block per option reads as four verdicts, and only the explanation names what separates a wrong option from the answer.
-
-### The markup
-
-The quiz shape is a contract rather than a convention. `canon teach nav` splices a stepper into the lesson that gates on exactly these class names and this nesting, so a quiz written in any other shape renders with every question on screen at once and nothing reports it.
-
-```html
-<div class="quiz">
-<h2>Retrieval check</h2>
-
-<div class="q"><p class="q-stem">1. <stem></p>
-<label class="opt" data-k="A"><input type="radio" name="q1"><span><the option text></span></label>
-<label class="opt" data-k="B"><input type="radio" name="q1" data-a="1"><span><the option text></span></label>
-<div class="fb"><b>Correct: <the answer in a few words>.</b> <why each distractor fails.></div></div>
-</div>
-```
-
-- Give every option in one question the same `name`, and a different `name` per question. Options sharing a name across two questions let one answer clear another.
-- Mark the correct option with `data-a="1"` and leave the others without the attribute
-- Carry `data-k` on the `label`, since the workspace stylesheet renders the key letter from it
-
-### Structure and the legacy button
-
-The nesting matters as much as the class names.
-
-- Keep `.fb` the last child of its `.q`. The stepper reveals it as a direct child, and a feedback block nested deeper stays hidden.
-- Put the option text in a `<span>` inside the label rather than bare beside the input, so the workspace can lay the two out
-- Never write a `<button class="opt">` in a new lesson. That is the shape written before the stepper, and it is kept working by an injected script the presence of a button is what still triggers.
-
-The stepper hides and shows and sets nothing else, so how a selected option looks, and whether a wrong one is marked as wrong, is the workspace stylesheet's to grow. Name the correct option in the feedback text for that reason: it is what a learner reads to find out whether they were right.
-
-## Teach back
-
-A quiz is recognition and a teach-back is production, which is the form retrieval practice prefers. Carry both: the quiz places the learner against options someone could hold, and the teach-back is where the learner finds out what they cannot say without help.
-
-- Ask for an explanation to a named audience rather than for an answer. Telling a non-programmer why a lazy quantifier is not an optional one has a floor, and "explain lazy quantifiers" has none.
-- Ask about the thing the lesson was for, not a detail beside it. A teach-back on a footnote tests attention rather than the material.
-- Carry a self-check as a closed `<details>` listing what a complete explanation covers. A learner with no session in the room otherwise cannot grade the ask, and closed leaks nothing.
-- Write the self-check as what the explanation has to cover rather than as the explanation itself. A model answer is read instead of produced, which turns the block back into reading.
-
-```html
-<div class="teach-back">
-<h2>Explain it back</h2>
-<p>Without looking above: <the ask, naming who it is for.></p>
-<details><summary>What a complete explanation covers</summary>
-<ul>
-<li><a point the explanation has to reach></li>
-</ul>
-</details>
-</div>
-```
-
-It needs no styles of its own beyond what the workspace already gives a section and a `<details>`.
-
-## Tokens travel with the course
-
-A lesson carries its own values in the shared stylesheet rather than reading a host project's. A workspace runs in any project and most carry no token record at all, so a lesson inheriting one is a lesson that renders unstyled wherever the record is absent, with nothing reporting it.
-
-Pick values the material needs rather than values the project happens to hold. Inheriting is worth offering as something a learner asks for once, and it is the wrong default in every project that cannot answer.
-
-## What makes a lesson worth returning to
-
-- The worked example is complete. A learner returning for the example finds the whole thing rather than a fragment they have to reconstruct.
-- The lesson states what it assumes. A returning reader can tell in one line whether they are in the right place.
-- The hard part is named as the hard part. Material that flattens everything to one difficulty gives a returning reader nothing to navigate by.
-- Nothing depends on the session it was written in. A lesson referring to what was discussed is unreadable a week later.

package/claude/skills/teach-workspace/references/promotion-fold.md

@@ -1,35 +0,0 @@
----
-title: Fold promoted pages
-description: How teach-workspace's fold mode lands each page a teach promotion handoff carries from a branch, deletes the handoff, and reports what it landed or left unfolded
----
-
-# Fold promoted pages
-
-The fold mode of `teach-workspace`, run from a branch in a worktree. The session reads this file when the invocation asks to fold confirmed promotions in.
-
-## Read the handoff
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../git-branch/references/slug.md`, falling back to `latest` on an empty result, and read `.canon/tmp/handoff/teach-promotion/<slug>.md` at the main worktree root.
-
-- `teach-workspace` writes it, one H2 per destination naming the path, a source line under the heading, and the page body fenced below that
-- Read the body out of the fence rather than off the heading level, since a reference page carries headings of its own and only the fence separates them from the next destination
-- Stop when the file is absent, reporting `❌ No promotion handoff at .canon/tmp/handoff/teach-promotion/<slug>.md. Run the promotion step from the workspace first.`
-
-## Land each block
-
-Each block is a page an operator already confirmed a destination for, so this step lands it rather than judging it again. Write to the destination the heading names at `pwd` rather than the main root, since every destination is a tracked file that commits with the branch.
-
-- A wiki page and a public doc arrive as a whole file. Write it as the block gives it, and leave the block unfolded when the destination holds a file, since overwriting another's page is not a fold.
-- A context entry is merged into rather than created. Fold the body into the sections it belongs under, and never add an entry the catalog does not already carry.
-
-Then delete the handoff file so a later run does not fold it twice, and regenerate the index of any folder that carries one.
-
-## Output
-
-One line per page landed, one naming the handoff when one was consumed, and one per block left unfolded rather than dropped.
-
-```plaintext
-✅ Promoted: <destination path>
-🧹 Folded: .canon/tmp/handoff/teach-promotion/<slug>.md
-⚠ Skipped: <destination path> already exists. Merge by hand.
-```

package/claude/skills/teach-workspace/references/promotion.md

@@ -1,116 +0,0 @@
-# Promotion routing
-
-Which surface a durable page from a learning workspace belongs to, and what to do when the destination does not exist yet.
-
-## What may be promoted
-
-Only the durable half. A reference page under `reference/` and `GLOSSARY.md` carry no learner and are ordinary reference prose about a subject, so they sort under the routing test like anything else.
-
-A lesson is never promoted, at any age and on any request. It is generated markup worked through once, carrying a quiz and a second person, and nothing downstream cites it.
-
-- Promoting one puts ungated markup into a corpus every other page passed a gate to enter
-- A reference page carrying a quiz, a second person, or an instruction to the learner is a lesson wearing the wrong extension
-- Say so, and propose rewriting that page in place before promotion rather than repairing it at the destination
-
-## The routing test
-
-Sort by who owns the subject, which is the test the wiki already runs. The reader's activity decided the workspace and decides nothing here.
-
-| The page's subject                                                                                                   | Destination                                                                                               |
-| -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
-| Owned by Anthropic                                                                                                   | the project's wiki                                                                                        |
-| Owned by another tool or vendor, owned by no single vendor, or written for someone consuming what this project ships | the project's public docs                                                                                 |
-| How this project itself works, for the people who build it                                                           | `canon/context/<domain>.md`, or the domain's own nested `index.md` when it is already split into a folder |
-
-A page a reader cannot sort by that question is a page whose subject has not been settled. Say which two destinations it sits between and let the operator choose, rather than picking the nearer one.
-
-## Where the wiki sits
-
-The folder has two spellings and a project carries whichever the project created:
-
-- `.claude/wiki/`, the folder inside the Claude setup
-- A folder named `wiki` at the project root
-
-Read which one exists rather than composing either. A project carrying both keeps its pages at the root, so propose the root spelling and say the other folder is there.
-
-### Neither spelling
-
-A project carrying neither gets a refusal rather than a scaffold:
-
-```plaintext
-❌ No wiki folder. Create `.claude/wiki/` with an `index.md`, then promote again.
-```
-
-Creating the folder as a side effect of promoting one page hands the project a surface it never chose, and the refusal is one step from resolved.
-
-## What a promoted page owes its destination
-
-Each destination gates prose the workspace does not, so name what the page still needs rather than proposing a move that fails at the gate.
-
-- A wiki page closes its intro paragraph with a sentence naming who owns the subject, and links the canonical page when one exists. A page carrying no such sentence is not ready to move.
-- A context entry is internal narrative about one domain, so a page landing there merges into an existing entry rather than arriving as a new one.
-- A glossary keeps the shape `glossary.md` fixes wherever it lands, and a promoted one has to state any rule it departs from.
-
-## Anti-patterns
-
-- **The page promoted into a new context entry.** Entries are created deliberately, so a promotion proposing one is proposing a domain rather than moving a page.
-- **The glossary split across destinations.** Terms drawn from one subject move together or not at all, since an entry defining a term the other half uses strands both.
-- **The workspace emptied on promotion.** Promotion copies rather than moves. The workspace stays readable to the learner who built it, and the page's later life belongs to its destination.
-
-## Proposing and handing off
-
-Step 6 of `teach-workspace` reads this section once the routing above has placed each page. Propose and wait. A promoted page is public prose that needs a line naming who owns its subject, which is a judgment about ownership rather than a move a session makes on its own reading. Present one block per candidate page:
-
-```plaintext
-reference/<slug>.md → <destination path>
-Subject owner: <who owns it, in a few words>
-Still owed:    <what the destination expects that the page does not carry yet>
-```
-
-Then stop and let the operator strike, redirect, or confirm each block.
-
-### Record the handoff
-
-Write nothing to a destination here. One skill owns the durable writes, and two skills editing one file at one step is the failure that rule exists against.
-
-Record each confirmed block in `.canon/tmp/handoff/teach-promotion/<slug>.md` at the main worktree root instead, appending when the file exists. Each destination takes one H2 naming its path, the source page beneath it, and the page body fenced:
-
-````markdown
-## <destination path>
-
-Source: .canon/teach/<nn>-<topic>/reference/<slug>.md
-
-```markdown
-<the page body as it should land, with the source line the destination expects>
-```
-````
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../git-branch/references/slug.md`. Fall back to `latest` on an empty result.
-
-### Why the fence
-
-A reference page carries headings of its own, and the reader splits this file on its H2 lines. An unfenced body turns every section heading in the page into a destination naming no path.
-
-- Open the body fence with four backticks, so a page carrying a fenced code block still closes where it should
-- Widen both fences together if the page carries a four-backtick fence
-
-### Why a file of its own
-
-The routed-facts file another skill writes is deleted by whichever pass folds it, so a second producer's unread work would go with it. A sibling path costs the folding skill one more read and removes the interaction.
-
-### Sending and reporting
-
-An append is a whole-file operation, so send it as a heredoc, per the skill's Step 0. Then tell the operator that `/teach-workspace fold` folds the file in from a branch.
-
-The proposal costs nothing tracked and runs anywhere. The page it describes is a tracked file, so the fold is a worktree operation and the workspace it came from is not.
-
-### Output
-
-A promotion pass reports this shape in place of the skill's Output block, one line per page the operator confirmed and one naming the handoff:
-
-```plaintext
-➡️ Promoting: .canon/teach/<nn>-<topic>/reference/<slug>.md → <destination path>
-→ Confirmed pages wait at .canon/tmp/handoff/teach-promotion/<slug>.md. Run /teach-workspace fold from a branch to fold them in.
-```
-
-A pass where the operator confirmed nothing writes no handoff file and reports that alone.

package/claude/skills/teach-workspace/references/revisit.md

@@ -1,28 +0,0 @@
----
-title: Revisit schedule
-description: How teach-workspace Step 5 writes a learning record's Revisit section, being the bullet shape, where each date and rung is copied from, the first schedule for a new item, and how a later record revises one
----
-
-# Write the Revisit section
-
-Part of Step 5 of `teach-workspace`. The session reads this file once the record's lessons, retrievals, and wrong answers are written, before restating the mission's success lines.
-
-Then write `## Revisit`, one bullet per item, in the shape `${CLAUDE_SKILL_DIR}/references/teach.md` fixes:
-
-```markdown
-## Revisit
-
-- **<what comes back up>**: due <YYYY-MM-DD>, rung <n>
-```
-
-## Where the date comes from
-
-Take both the date and the rung from the `due` entry Step 1 already read. Copy `hit` for an item the learner retrieved unaided and `miss` for one they did not, with the rung stepped the same way.
-
-- Do not compute a date from the ladder. A session told to widen a gap still picks the number by judgment, which is why the verb reports both dates.
-- An item never scheduled has no `due` entry. Open it at rung 1, dated the day after this session, the ladder's floor and the one number this body states.
-- Every later date for that item comes from the verb
-
-## Writing the shape exactly
-
-An entry outside this shape schedules nothing and nothing reports that it was skipped, so write the shape exactly. A later record naming the same item supersedes an earlier entry, so revise a schedule by writing the new bullet rather than editing the record it was set in.