dsh-nerd-mode 0.4.0 → 0.4.4

package/skills/study-plus/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: study-plus
 description: Run one tracked session against a dated learning record. Load for an explicit command or after the user chooses tracked study in the upper router.
-argument-hint: "<topic>, or empty to continue the last topic"
+argument-hint: "<course-slug>, or empty to continue the current Course"
 ---
 # Study Plus
 
@@ -14,23 +14,29 @@ Two rules override everything below.
 
 ## 1. Find the workspace and material
 
-The topic directory is `study/<slug>/` in the workspace root, where the slug is the topic in lowercase with hyphens.
+The Course directory is `study/<course>/` in the workspace root, where `<course>` is the Course name in lowercase with hyphens.
 
 Find it with a recursive search. Call `glob` with `study/**` from the workspace root and treat the hits as the full file list under `study/`. A `glob` of `study/*` or a `read` of `study` can come back empty while the directory exists, so one empty result never proves the record is missing. When either returns nothing, call `glob` with `**/study/**/graph.md` before you decide. Name the path you searched whenever you say no record exists.
 
-- With an argument: resolve the slug. If the directory exists, continue it. If it does not exist, build the graph (section 2). If it exists without a `graph.md`, the folder belongs to something else, so ask before writing.
-- Without an argument: take the topic names from the parent directories of the `study/**` hits. One topic, continue it. Several, ask which. None, ask for a topic.
+- With an argument: resolve the slug. If the directory exists, continue it. If it does not exist, ask once whether to create it, then build the graph (section 2). If it exists without a `graph.md`, the folder belongs to something else, so ask before writing.
+- Without an argument: the first tracked study settles the Course. Exactly one Course is used and named in one line. A new Course from the path item asks for its name once; every other Course is named without a question. Several Courses get one question that lists them and offers a new Course.
 - No `study/` anywhere in the workspace: create it on first use.
 
-Each topic holds `graph.md`, `state.md`, and `log.md`, plus `lectures/`, `diagrams/`, and `lectures/archive/` as needed. Read `graph.md`, `state.md`, and the last two blocks of `log.md` before you speak. A legacy `plan.md` is inert user data: never read it, never write it, never delete it. Do not read or write an unrelated file under `study/` just because the directory search finds it.
+When the opening question runs, it carries the Course in its path item: one complete answer in this conversation with no Course record, one continue choice for each existing Course, then start a new Course. Show a continue choice only for a Course that exists under `study/`. Call the only existing Course the current Course; with several, use each name. One round for the opening question, with no separate path question. An explicit `/study-plus` skips the opening question, so the Course question stands alone there. Settle the Course once per conversation and never ask again.
+
+A new Course from the path item asks for its name once before the graph. Offer the request's subject as the suggested name. When the name matches an existing Course, ask whether to continue that Course or use another name. An explicit `/study-plus <course>` settles the Course with no question. Otherwise, the name comes from the learner's words. Slug it the way the record path is slugged today, show the slug in the confirmation line, and create the folder on first write.
+
+When the conversation has a Course and the request is about a different subject, ask one question with two options: add these concepts to the current Course, or start a new Course. The first option runs the existing graph change. Never ask two questions in one turn.
+
+Each Course holds `graph.md`, `state.md`, and `log.md`, plus `lectures/`, `diagrams/`, and `lectures/archive/` as needed. Read `graph.md`, `state.md`, and the last two blocks of `log.md` before you speak. A legacy `plan.md` is inert user data: never read it, never write it, never delete it. Do not read or write an unrelated file under `study/` just because the directory search finds it.
 
 Use material supplied with the current request as scope and reference. Read it, then check important or uncertain claims when needed. Accuracy wins over the source, and relevant differences must be flagged. Use the approved graph and material by default. Do not research the web for every lecture.
 
-The record belongs to this workspace. The same topic studied in another folder starts a separate record. If the learner moves workspaces mid-topic, say so and offer to copy `study/<slug>/` across.
+The record belongs to this workspace. The same Course studied in another folder starts a separate record. If the learner moves workspaces mid-Course, say so and offer to copy `study/<course>/` across.
 
 ## 2. Build, migrate, or change the graph
 
-For a new topic, or when the learner asks for a change, build or rebuild the graph. For a legacy graph that uses `Structure` or `Block`, show a migration preview before continuing. If an existing graph lacks both Chapter/Section metadata and Structure/Block grouping, propose Chapter/Section groupings from its concepts and prerequisites, show the preview, and ask whether to retain or adjust it before writing. Convert legacy groupings to `Chapters`, `Chapter`, and `Section`. If the graph gives no chapter grouping, propose logical groupings. Ask only whether to retain or adjust the preview. After confirmation, write the normalized graph once. Do not change tracker states or lecture bodies.
+For a new Course, or when the learner asks for a change, build or rebuild the graph. For a legacy graph that uses `Structure` or `Block`, show a migration preview before continuing. If an existing graph lacks both Chapter/Section metadata and Structure/Block grouping, propose Chapter/Section groupings from its concepts and prerequisites, show the preview, and ask whether to retain or adjust it before writing. Convert legacy groupings to `Chapters`, `Chapter`, and `Section`. If the graph gives no chapter grouping, propose logical groupings. Ask only whether to retain or adjust the preview. After confirmation, write the normalized graph once. Do not change tracker states or lecture bodies.
 
 A graph change keeps work the learner already has.
 
@@ -45,8 +51,8 @@ For a new graph:
 1. Use supplied material first, then reliable sources when needed, then your own knowledge. Do not research the web for every lecture.
 2. Make a concept table in prerequisite order. Each row has a one-line definition and prerequisite numbers. Keep prerequisite order separate from textbook reading order.
 3. Use the source's book and chapter hierarchy when present. Otherwise, propose logical chapter groupings.
-4. Present the full graph and chapter layout together in the existing approve, edit, or rebuild question. Do not add another approval step. State in that question that approval starts draft generation for every concept, including any concept the learner then skips, and that drafts are not teaching.
-5. After approval, run calibration as one `question` call with three items: what the learner wants to be able to do after this topic, what they have already read, studied, or used in this area in their own words, and which concepts in the approved graph they know well enough to skip, as a multi-select list. Items 1 and 2 are free text. Ask the goal and background items only when the current request and the supplied material do not already state them. Derive the level. Then write `graph.md`, create `state.md` with every concept `new` and undated except the concepts selected to skip, which are `skipped`, create an empty `log.md`, and generate one draft per concept (section 3). Do not create `plan.md`.
+4. Show the full graph and chapter layout in the reply before the approval question, as a Markdown table. Keep the question text short, because it renders as one paragraph: ask whether to approve, edit, or rebuild the graph shown above, and state that approval starts draft generation for every concept, including any concept the learner then skips, and that drafts are not teaching. Do not put the table in the question text. Do not add another approval step.
+5. After approval, run calibration as one `question` call with up to three items: what the learner wants to be able to do after this Course, what they have already read, studied, or used in this area in their own words, and which concepts in the approved graph they know well enough to skip, as a multi-select list. Items 1 and 2 are free text. Ask the goal and background items only when nothing already answers them: not the current request, not the opening question, not the supplied material. Reuse an opening-question answer verbatim. Derive the level. Then write `graph.md`, create `state.md` with every concept `new` and undated except the concepts selected to skip, which are `skipped`, create an empty `log.md`, and generate one draft per concept (section 3). Do not create `plan.md`.
 
 Calibration writes `Goal`, `Background`, and `Teaching level` to `graph.md`. Derive the level from the two answers:
 
@@ -58,15 +64,15 @@ Calibration writes `Goal`, `Background`, and `Teaching level` to `graph.md`. Der
 
 When the two answers clearly conflict, you may choose an adjacent level and state the reason in one line. When the learner declines or gives no usable answer, write `Teaching level: standard` and omit the `Goal` and `Background` lines. Each selected concept becomes `skipped`, with no date and no passes.
 
-Do not ask for calibration on a topic that already has a `graph.md`. A missing `Teaching level` line means `standard`. A graph rebuild keeps the existing `Goal`, `Background`, and `Teaching level` values and asks for nothing the previous graph already recorded.
+Do not ask for calibration on a Course that already has a `graph.md`. A missing `Teaching level` line means `standard`. A graph rebuild keeps the existing `Goal`, `Background`, and `Teaching level` values and asks for nothing the previous graph already recorded.
 
-A mid-topic request such as "too detailed" or "give me the conclusion" changes the level for this session only. Write nothing to `graph.md` and add no log entry. A learner preference is not evidence. When the learner says to keep the change, rewrite the `Teaching level` line and keep the other two lines. This is the only path that changes an existing topic, and the only upgrade path for a topic with no `Teaching level` line.
+A mid-Course request such as "too detailed" or "give me the conclusion" changes the level for this session only. Write nothing to `graph.md` and add no log entry. A learner preference is not evidence. When the learner says to keep the change, rewrite the `Teaching level` line and keep the other two lines. This is the only path that changes an existing Course, and the only upgrade path for a Course with no `Teaching level` line.
 
 The level never changes the Recall Session, the skipped-prerequisite recap, the unseen questions, the Teach-back, the pass threshold, or any learner state. It affects the lecture only.
 
 The hierarchy is Book, Chapter, Section. A graph concept is one Section named after the concept. A lecture is the teaching explanation for one concept in one Concept cycle. It is not a book, chapter, or separate graph concept.
 
-`graph.md` keeps `# Topic`, `Goal`, `Background`, and `Teaching level`, and may add `Book: <title>`. The three brief lines are optional. If `Book` is absent, use the topic as the book title. A multi-chapter graph has `## Chapters` followed by numbered rows in book order: `1. <chapter title>: <scope>`. The concept table keeps prerequisite order and adds integer `Chapter` and `Section` columns. Each concept belongs to one chapter and one section. Number sections from 1 within each chapter in textbook order. A single-chapter graph still uses `Chapter = 1` and section numbers, but omits `## Chapters`; use the Book title, or topic fallback, as the displayed chapter title.
+`graph.md` keeps `# Course: <name>`, `Goal`, `Background`, and `Teaching level`, and may add `Book: <title>`. A new file opens with `# Course: <name>`. A reader accepts `# Topic:` as well, so an older graph keeps its title, and the skill never rewrites an existing `# Topic:` heading. The three brief lines are optional. If `Book` is absent, use the Course as the book title. A multi-chapter graph has `## Chapters` followed by numbered rows in book order: `1. <chapter title>: <scope>`. The concept table keeps prerequisite order and adds integer `Chapter` and `Section` columns. Each concept belongs to one chapter and one section. Number sections from 1 within each chapter in textbook order. A single-chapter graph still uses `Chapter = 1` and section numbers, but omits `## Chapters`; use the Book title, or Course fallback, as the displayed chapter title.
 
 A wrong order mis-teaches for weeks. Do not skip the approval.
 
@@ -74,7 +80,7 @@ A wrong order mis-teaches for weeks. Do not skip the approval.
 
 A Lecture draft is complete teaching material written before any Concept cycle. It is not teaching, it carries no teaching date, and it changes no learner state.
 
-1. Compute one destination per concept: `study/<slug>/lectures/<NN>-<concept-slug>.md`, where `NN` is the graph's concept number padded to at least two digits. The list covers every concept, including skipped concepts.
+1. Compute one destination per concept: `study/<course>/lectures/<NN>-<concept-slug>.md`, where `NN` is the graph's concept number padded to at least two digits. The list covers every concept, including skipped concepts.
 2. Hand the approved graph, the relevant supplied material, the three brief lines, and that explicit destination list to `study`. Copy `Goal`, `Background`, and `Teaching level` from `graph.md` verbatim: do not compress, summarize, or rewrite them. Pass one Chapter per request. `study` owns the draft content and its frontmatter, and it never reads tracker files or chooses paths.
 3. Split the Chapters across subagents when they are available. Give each one the `study` draft rules and keep each agent's destination list disjoint. Without subagents, write the Chapters yourself, one at a time.
 4. Check every returned file: path, `status: draft`, the `concept` number, one H1, coverage of every concept in the Chapter, prerequisite consistency, use of the supplied material, and any contradiction across Chapters. Report a contradiction in one line.
@@ -122,15 +128,15 @@ A tracked lecture belongs in `lectures/<NN>-<slug>.md`, with `date` and `concept
 
 Teach one concept according to `study`'s lecture rules. Write or update the Markdown file yourself, then show the same lecture content in the conversation. For long source material, give a roadmap and progress. Save the complete lecture file before displaying it in chunks if a platform limit requires chunking. Do not start assessment until the full lecture is displayed.
 
-The lecture has no length cap. Teach until the concept is complete at the given level. For visual authoring rules, load `diagram`, but save figures only under the scoped topic's `study/<slug>/diagrams/<name>.svg`, not its generic default. Sanitize the figure name to one lowercase kebab-case segment with no slashes or dot segments. If it is unclear, choose a safe fallback. Before writing, confirm the resolved parent stays within the scoped topic's `diagrams/` root and the target is not `graph.md`, `state.md`, or `log.md`. Compute every plotted point with the host shell. Use `pwsh` on Windows and `bash` on macOS or Linux. Never place a point by eye. Before replacing a same-name SVG, copy the old file to `<name>.svg.bak`, replacing any older backup.
+The lecture has no length cap. Teach until the concept is complete at the given level. For visual authoring rules, load `diagram`, but save figures only under the scoped Course's `study/<course>/diagrams/<name>.svg`, not its generic default. Sanitize the figure name to one lowercase kebab-case segment with no slashes or dot segments. If it is unclear, choose a safe fallback. Before writing, confirm the resolved parent stays within the scoped Course's `diagrams/` root and the target is not `graph.md`, `state.md`, or `log.md`. Compute every plotted point with the host shell. Use `pwsh` on Windows and `bash` on macOS or Linux. Never place a point by eye. Before replacing a same-name SVG, copy the old file to `<name>.svg.bak`, replacing any older backup.
 
 If saving the lecture fails, continue the assessment and record produced evidence. Tell the learner which save path failed.
 
 If the row was already `in_process`, say that the last session stopped before the questions, repeat the full lecture, then go to the questions. The configured question slots were never asked, so they are still unseen. When the log records a defer rather than a crash, say what remains and offer the questions before repeating the lecture.
 
-**Ask unseen questions.** Use the explicit count or type preference in the current `/study-plus` request when present. Otherwise, use the profile defaults in the top-level Nerd Mode instructions. Plan the configured number of unseen question slots, from 0 to 10. A hint, re-ask, or similar question stays in its current slot and does not add a slot. For each slot, write down the expected answer and criteria for a good answer. Keep both private. A draft never contains them. The criteria test the conclusion and whether each step taken is valid, not the route you had in mind. Ask one question at a time, then wait. Outside `study-plus`, ignore these preferences.
+**Ask unseen questions.** Use the explicit count or type preference in the current `/study-plus` request when present. Otherwise, use the profile defaults in the top-level Nerd Mode instructions. Plan the configured number of unseen question slots, from 0 to 10. A hint, re-ask, or similar question stays in its current slot and does not add a slot. For each slot, write down the expected answer and criteria for a good answer. Keep both private. A draft never contains them. The criteria test the conclusion and whether each step taken is valid, not the route you had in mind. Ask one question at a time, then wait. One call asks one question. Outside `study-plus`, ignore these preferences.
 
-For `short-answer`, ask a short-answer question. For `multiple-choice`, give four options with exactly one correct answer; choosing it is sufficient. For `mixed`, choose short-answer or multiple-choice independently at random for each planned slot. Do not add question-type details to the session log. When the configured count is zero, skip unseen questions. A passed Teach-back alone is sufficient to pass. With one or more slots, require a passed Teach-back and `ceil(2 × slot count / 3)` correct slots.
+For `short-answer`, ask the question in the conversation. For `multiple-choice`, ask it as one `question` call with four options and exactly one correct answer; choosing it is sufficient. Give the labels alone, with no description, and shuffle the four positions for each slot. A host without a `question` tool gets the same four options as a numbered text list. A typed answer that names or repeats one option counts as choosing it. Any other typed answer is graded like a short answer. For `mixed`, choose short-answer or multiple-choice independently at random for each planned slot. Do not add question-type details to the session log. When the configured count is zero, skip unseen questions. A passed Teach-back alone is sufficient to pass. With one or more slots, require a passed Teach-back and `ceil(2 × slot count / 3)` correct slots.
 
 A question exists to find the gap, not to stop the session. Nothing in this step blocks the learner.
 
@@ -140,6 +146,7 @@ A question exists to find the gap, not to stop the session. Nothing in this step
 - When an answer is wrong, do three things in one message: name the wrong step, work the correct answer with its process, then ask a similar question in the same slot. Mark one miss. Keep the original miss recorded even if the learner answers the similar question correctly.
 - When the learner asks for the answer, do the same: give the worked answer, mark one miss, ask a similar question in the same slot. Keep the original miss recorded even if the learner answers the similar question correctly.
 - When the learner defers a question or asks to move on, accept it at once. Record the defer and the learner's reason in the log. The concept stays `in_process`, because a defer is neither evidence nor a miss. Never argue about time.
+- When the learner closes the question card or the card times out, treat it as no answer. Ask the same question once more. If it happens again, record a defer with no reason. The concept stays `in_process`.
 
 **Teach-back.** Ask the learner to explain the idea to someone who has not seen it. Grade two things: the idea is correct, and the explanation would let that person use it. Note whether the language stays plain. Do not ask where the idea stops applying. When the answer is valid overall and something is missing or loose, name it, correct it in one sentence, and pass. A miss is for a wrong idea, not for a gap you can close in the moment.
 
@@ -173,7 +180,7 @@ After a completed cycle, rebuild the Book (section 8) and offer three choices in
 `graph.md`:
 
 ```md
-# Topic: <topic>
+# Course: <course>
 Goal: <one line, optional>
 Background: <one line, optional>
 Teaching level: beginner | standard | advanced
@@ -188,7 +195,7 @@ Book: <title, optional>
 | 2 | <name> | <one line> | 1 | 1 | 2 |
 ```
 
-Omit `Book` when the topic is the title. Omit `## Chapters` for one chapter. Use that chapter's table value `Chapter = 1` and section numbers within it. `Goal`, `Background`, and `Teaching level` are optional, and the values are lowercase. A missing `Teaching level` means `standard`. The Book shows no `Background` or `Teaching level` line.
+Omit `Book` when the Course is the title. Omit `## Chapters` for one chapter. Use that chapter's table value `Chapter = 1` and section numbers within it. `Goal`, `Background`, and `Teaching level` are optional, and the values are lowercase. A missing `Teaching level` means `standard`. The Book shows no `Background` or `Teaching level` line.
 
 A dated Lecture and a Lecture draft share one file per concept and differ in frontmatter:
 
@@ -214,7 +221,7 @@ A legacy `plan.md` stays on disk untouched. Nothing reads or writes it.
 
 Assemble a book by grouping lecture files according to Chapter and Section metadata, in textbook order, including drafts and dated Lectures. Each lecture file remains one concept. The page labels a draft as a draft and never shows learner states.
 
-Run `node skills/study-plus/scripts/build-book.mjs study/<slug>` from the workspace root after a complete or partial draft batch, after saving a Lecture, and after a graph rebuild. The learner does not need to ask. The builder copies the current `book.html` to `book.html.bak` before each replacement, and it replaces the older backup. If the builder fails, the current Book stays intact: say which path failed in one line and continue the Concept cycle. If it reports a malformed graph, explain the issue and propose a graph fix for confirmation before changing it.
+Run `node skills/study-plus/scripts/build-book.mjs study/<course>` from the workspace root after a complete or partial draft batch, after saving a Lecture, and after a graph rebuild. The learner does not need to ask. The builder copies the current `book.html` to `book.html.bak` before each replacement, and it replaces the older backup. If the builder fails, the current Book stays intact: say which path failed in one line and continue the Concept cycle. If it reports a malformed graph, explain the issue and propose a graph fix for confirmation before changing it.
 
 `state.md`:
 

package/skills/study-plus/scripts/book-data.mjs

@@ -96,8 +96,8 @@ function readChapterList(text, heading, errors) {
 
 function graphMetadata(text, topicFallback) {
   const firstHeading = text.match(/^#\s+(.+?)\s*$/m)?.[1]?.trim() || '';
-  const headingTopic = firstHeading.replace(/^Topic:\s*/i, '');
-  const topic = (headingTopic.toLowerCase() === 'topic' ? '' : headingTopic || topicFallback || 'Topic').trim();
+  const headingTopic = firstHeading.replace(/^(?:Topic|Course):\s*/i, '');
+  const topic = (headingTopic.toLowerCase() === 'topic' || headingTopic.toLowerCase() === 'course' ? '' : headingTopic || topicFallback || 'Course').trim();
   const book = (text.match(/^Book:\s*(.+?)\s*$/mi)?.[1] || '').trim();
   const goal = (text.match(/^Goal:\s*(.*?)\s*$/mi)?.[1] || '').trim();
   return { topic, title: book || topic, goal };
@@ -237,7 +237,7 @@ function demote(body) {
 /** Parse a graph and its lecture files into ordered book chapters and sections. */
 export function parseBookData(graphText, lectureFiles, { topicFallback = '' } = {}) {
   const graph = parseGraph(graphText, topicFallback);
-  if (!lectureFiles.length) throw new Error('No lecture files found. Add Markdown lectures under the topic lectures/ folder.');
+  if (!lectureFiles.length) throw new Error('No lecture files found. Add Markdown lectures under the Course lectures/ folder.');
 
   const lectures = lectureFiles.map(parseLecture);
   const byConcept = new Map();

package/skills/study-plus/scripts/build-book.mjs

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-// Build study/<topic>/book.html from the graph and its existing lecture files.
+// Build study/<course>/book.html from the graph and its existing lecture files.
 
 import { readFileSync, readdirSync, writeFileSync, existsSync, unlinkSync, realpathSync, statSync, lstatSync, copyFileSync, renameSync } from 'node:fs';
 import { join, resolve, dirname, relative, isAbsolute, sep } from 'node:path';
@@ -23,7 +23,7 @@ function findTopic(arg) {
   try {
     studyStat = lstatSync(studyPath);
   } catch (error) {
-    if (error.code === 'ENOENT') die('No study/ folder here. Pass a topic folder under workspace study/.');
+    if (error.code === 'ENOENT') die('No study/ folder here. Pass a Course folder under workspace study/.');
     die(`Cannot inspect workspace study/ folder: ${error.message}`);
   }
   if (studyStat.isSymbolicLink()) die(`Refusing to use symlink as workspace study/ folder: ${studyPath}`);
@@ -38,7 +38,7 @@ function findTopic(arg) {
   let topicPath = arg ? resolve(arg) : '';
   if (!arg) {
     const hits = readdirSync(studyRoot).filter((name) => existsSync(join(studyRoot, name, 'graph.md')));
-    if (hits.length !== 1) die(`Pass a topic folder under workspace study/. Found ${hits.length} topics under study/: ${hits.join(', ') || 'none'}.`);
+    if (hits.length !== 1) die(`Pass a Course folder under workspace study/. Found ${hits.length} Courses under study/: ${hits.join(', ') || 'none'}.`);
     topicPath = join(studyRoot, hits[0]);
   }
 
@@ -46,11 +46,11 @@ function findTopic(arg) {
   try {
     topicDir = realpathSync(topicPath);
   } catch (error) {
-    die(`Cannot resolve topic folder ${topicPath}: ${error.message}`);
+    die(`Cannot resolve Course folder ${topicPath}: ${error.message}`);
   }
   const topicRelative = relative(studyRoot, topicDir);
   if (!statSync(topicDir).isDirectory() || !topicRelative || topicRelative === '..' || topicRelative.startsWith(`..${sep}`) || isAbsolute(topicRelative)) {
-    die(`Topic folder must be a real directory at least one level below workspace study/: ${topicPath}`);
+    die(`Course folder must be a real directory at least one level below workspace study/: ${topicPath}`);
   }
   return topicDir;
 }

package/skills/teach/GLOSSARY-FORMAT.md

@@ -1,35 +0,0 @@
-# GLOSSARY.md Format
-
-`GLOSSARY.md` is the canonical language for this teaching workspace. All explainers, exercises, and learning records should adhere to its terminology. Building it is itself part of learning: compressing a concept into a tight definition is evidence the user understands it.
-
-## Structure
-
-```md
-# {Topic} Glossary
-
-{One or two sentence description of the topic this glossary covers.}
-
-## Terms
-
-**Hypertrophy**:
-Muscle growth driven by mechanical tension and metabolic stress over repeated training sessions.
-_Avoid_: Bulking, getting big
-
-**Progressive overload**:
-Systematically increasing the demand on a muscle over time, via load, volume, or intensity.
-_Avoid_: Pushing harder, levelling up
-
-**RPE (Rate of Perceived Exertion)**:
-A 1–10 self-rating of how hard a set felt, where 10 is failure and 8 means two reps left in the tank.
-_Avoid_: Effort score, intensity rating
-```
-
-## Rules
-
-- **Add a term only when the user understands it.** The glossary is a record of compressed knowledge, not a dictionary the user reads to learn. If the user has just been introduced to a concept, wait until they can use it correctly before promoting it here.
-- **Be opinionated.** When several words exist for the same concept, pick the best one and list the rest as aliases to avoid. This is how language compresses.
-- **Keep definitions tight.** One or two sentences. Define what the term IS, not what it does or how to do it.
-- **Use the glossary's own terms inside definitions.** Once a term is in the glossary, prefer it everywhere, including inside other definitions. This is what makes complex terms easier to grasp later.
-- **Group under subheadings** when natural clusters emerge (e.g. `## Anatomy`, `## Programming`). A flat list is fine when terms cohere.
-- **Flag ambiguities explicitly.** If a term is used loosely in the wider field, note the resolution: "In this workspace, 'set' always means a working set; warm-ups are tracked separately."
-- **Revise as understanding deepens.** A definition the user wrote in week one may be wrong by week six. Update in place; do not leave stale entries.

package/skills/teach/LEARNING-RECORD-FORMAT.md

@@ -1,46 +0,0 @@
-# Learning Record Format
-
-Learning records live in `./learning-records/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc. Create the directory lazily: only when the first record is written.
-
-They are the teaching equivalent of ADRs: they capture non-obvious lessons, key insights, and stated prior knowledge that will steer future sessions. They are used to calculate the zone of proximal development.
-
-## Template
-
-```md
-# {Short title of what was learned or established}
-
-{1-3 sentences: what was learned (or what prior knowledge was established), and why it matters for future sessions.}
-```
-
-That is the whole format. A learning record can be a single paragraph. The value is recording _that_ this is now known and _why_ it changes what to teach next, not in filling out sections.
-
-## Optional sections
-
-Only include these when they add genuine value. Most records won't need them.
-
-- **Status** frontmatter (`active | superseded by LR-NNNN`): useful when an earlier understanding turns out to be wrong and is replaced.
-- **Evidence**: how the user demonstrated the understanding (a question answered, an exercise completed, prior experience cited). Useful when the claim might be revisited.
-- **Implications**: what this unlocks or rules out for future sessions. Worth recording when non-obvious.
-
-## Numbering
-
-Scan `./learning-records/` for the highest existing number and increment by one.
-
-## When to write a learning record
-
-Write one when any of these is true:
-
-1. **The user demonstrated genuine understanding of something non-trivial**: not just exposure, but evidence they can use the concept correctly. This sets a new floor for what to teach next.
-2. **The user disclosed prior knowledge**: "I already know X." Record it so future sessions don't re-teach it. Also record the _depth_ claimed.
-3. **A misconception was corrected**: the user previously believed something wrong and now sees why. These are high-value: they predict future stumbling blocks for related topics.
-4. **The mission shifted in response to learning**: the user discovered they cared about something different than they thought. Cross-link to [[MISSION.md]] and update it.
-
-### What does _not_ qualify
-
-- Material that was merely covered. Coverage is not learning. Wait for evidence.
-- Anything already captured tersely in [[GLOSSARY.md]] as a term definition. Don't duplicate.
-- Session-by-session activity logs. Learning records are not a journal: they are decision-grade insights.
-
-## Supersession
-
-When a later record contradicts an earlier one (the user's understanding deepened or corrected), mark the old record `Status: superseded by LR-NNNN` rather than deleting it. The history of how understanding evolved is itself useful signal.

package/skills/teach/MISSION-FORMAT.md

@@ -1,31 +0,0 @@
-# MISSION.md Format
-
-`MISSION.md` lives at the workspace root. It captures the _reason_ the user is learning this topic. Every teaching decision (what to teach next, which resources to surface, which exercises to design) should trace back to this document.
-
-## Template
-
-```md
-# Mission: {Topic}
-
-## Why
-{1-3 sentences. The concrete real-world goal the user is chasing. What changes in their life or work when they have this skill? Avoid abstract framings like "to understand X"; push for the underlying outcome.}
-
-## Success looks like
-- {A specific, observable thing the user will be able to do}
-- {Another specific thing}
-- {…}
-
-## Constraints
-- {Time, budget, prior commitments, learning preferences, anything that bounds the approach}
-
-## Out of scope
-- {Adjacent topics the user explicitly does not want to chase right now, protecting the zone of proximal development}
-```
-
-## Rules
-
-- **One mission per workspace.** If the user wants to learn two unrelated things, that is two workspaces.
-- **Concrete over abstract.** "Run a half marathon by October" beats "get fitter." "Ship a Rust CLI to my team" beats "learn Rust."
-- **Push back on vagueness.** If the user cannot articulate why, interview them before writing anything. A bad mission is worse than no mission.
-- **Revise when reality shifts.** Missions change. When the user's goal moves, update this file: don't leave a stale mission steering future sessions.
-- **Keep it short.** If `MISSION.md` runs past a screen, it has stopped being a compass and started being a plan.

package/skills/teach/RESOURCES-FORMAT.md

@@ -1,32 +0,0 @@
-# RESOURCES.md Format
-
-`RESOURCES.md` is the curated set of trusted sources for this topic. Knowledge for explainers should be drawn from here, not from parametric guesses. Wisdom comes from the communities listed here.
-
-## Structure
-
-```md
-# {Topic} Resources
-
-## Knowledge
-
-- [Book: _The Science and Practice of Strength Training_ by Zatsiorsky & Kraemer](https://example.com)
-  Foundational text on programming and adaptation. Use for: anything to do with periodisation, recovery, intensity zones.
-- [Article: "How Much Should I Train?" by Greg Nuckols (Stronger By Science)](https://example.com)
-  Evidence-based review of volume landmarks. Use for: weekly set targets per muscle group.
-
-## Wisdom (Communities)
-
-- [r/weightroom](https://reddit.com/r/weightroom)
-  High-signal subreddit, moderated against bro-science. Use for: programme critique, plateau troubleshooting.
-- Local: Tuesday strength class at {gym name}
-  Use for: real-time coaching feedback on lifts.
-```
-
-## Rules
-
-- **High-trust only.** Prefer primary sources, recognised experts, peer-reviewed work, and communities with strong moderation. If a resource is marketing dressed as education, leave it out.
-- **Annotate every entry.** A bare link is useless in three months. Add one line: what it covers and when to reach for it.
-- **Group by Knowledge / Wisdom.** Mirrors the philosophy in [SKILL.md](./SKILL.md). It is fine for a resource to appear in only one group.
-- **Surface gaps explicitly.** If no good resource exists for an area the mission needs, write a `## Gaps` section listing what is missing. This drives future search.
-- **Prune ruthlessly.** A resource that turned out to be wrong, shallow, or off-mission should be removed, not buried. Better five sharp sources than thirty mediocre ones.
-- **Record community preferences.** If the user has opted out of joining communities, note it here so future sessions don't keep proposing them.

package/skills/teach/SKILL.md

@@ -1,140 +0,0 @@
----
-name: teach
-description: Teach the user a new skill or concept, within this workspace.
-disable-model-invocation: true
-argument-hint: "What would you like to learn about?"
----
-
-The user has asked you to teach them something. This is a stateful request - they intend to learn the topic over multiple sessions.
-
-## Teaching Workspace
-
-Treat the current directory as a teaching workspace. Workspace paths (`./lessons/` and the rest) resolve from the directory `/teach` was run in; only the `*-FORMAT.md` links resolve from this skill's folder. The state of their learning is captured in this directory in several files:
-
-- `MISSION.md`: A document capturing the _reason_ the user is interested in the topic. This should be used to ground all teaching. Use the format in [MISSION-FORMAT.md](./MISSION-FORMAT.md).
-- `./reference/*.html`: A directory of reference materials. These are the compressed learnings from the lessons - cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
-- `RESOURCES.md`: A list of resources which can be explored to ground your teaching in contextual knowledge, or to acquire knowledge and wisdom. Use the format in [RESOURCES-FORMAT.md](./RESOURCES-FORMAT.md).
-- `./learning-records/*.md`: A directory of learning records, which capture what the user has learned. These are loosely equivalent to architectural decision records in software development - they capture non-obvious lessons and key insights that may need to be revised later, or drive future sessions. These should be used to calculate the zone of proximal development. They are titled `0001-<dash-case-name>.md`, where the number increments each time. Use the format in [LEARNING-RECORD-FORMAT.md](./LEARNING-RECORD-FORMAT.md).
-- `./lessons/*.html`: A directory of lessons. A **lesson** is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in this workspace.
-- `./assets/*`: Reusable **components** shared across lessons. See [Assets](#assets).
-- `NOTES.md`: A scratchpad for you to jot down user preferences, or working notes.
-
-## Philosophy
-
-To learn at a deep level, the user needs three things:
-
-- **Knowledge**, captured from high-quality, high-trust resources
-- **Skills**, acquired through highly-relevant interactive lessons devised by you, based on the knowledge
-- **Wisdom**, which comes from interacting with other learners and practitioners
-
-Before the `RESOURCES.md` is well-populated, your focus should be to find high-quality resources which will help the user acquire knowledge. Never trust your parametric knowledge.
-
-Some topics may require more skills than knowledge. Learning more about theoretical physics might be more knowledge-based. For yoga, more skills-based.
-
-### Fluency vs Storage Strength
-
-You should be careful to split between two types of learning:
-
-- **Fluency strength**: in-the-moment retrieval of knowledge
-- **Storage strength**: long-term retention of knowledge
-
-Fluency can give the user an illusory sense of mastery, but storage strength is the real goal. Try to design lessons which build long-term retention by desirable difficulty:
-
-- Using retrieval practice (recall from memory)
-- Spacing (distributing practice over time)
-- Interleaving (mixing up different but related topics in practice - for skills practice only)
-
-## Lessons
-
-A lesson is the main thing you produce: the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html` where the number increments each time.
-
-A lesson should be **beautiful**, with clean, readable typography and layout, since the user will return to these later to review. Think Tufte.
-
-The lesson should be short, and completable very quickly. Learners' working memory is very small, and we need to stay within it. But each lesson should give the user a single tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development.
-
-If possible, open the lesson file for the user by running a CLI command.
-
-Each lesson should link via HTML anchors to other lessons and reference documents.
-
-Each lesson should recommend a primary source for the user to read or watch. This should be the most high-quality, high-trust resource you found on the topic.
-
-Each lesson should contain a reminder to ask followup questions to the agent. The agent is their teacher, and can assist with anything that's unclear.
-
-## Assets
-
-Lessons are built from reusable **components**, stored in `./assets/`: stylesheets, quiz widgets, simulators, diagram helpers, and anything else a second lesson could reuse.
-
-Reuse is the default, not the exception. Before authoring a lesson, read `./assets/` and build from the components already there. When a lesson needs something new and reusable, write it as a component in `./assets/` and link to it; never inline code a future lesson would duplicate.
-
-A shared stylesheet is the first component every workspace earns: every lesson links it, so the lessons look like one consistent course rather than a pile of one-offs. As the workspace grows, so should the component library.
-
-## The Mission
-
-Every lesson should be tied into the mission - the reason that the user is interested in learning about the topic.
-
-If the user is unclear about the mission, or the `MISSION.md` is not populated, your first job should be to question the user on why they want to learn this.
-
-Failing to understand the mission will mean knowledge acquisition is not grounded in real-world goals. Lessons will feel too abstract. You will have no way of judging what the user should do next.
-
-Missions may change as the user develops more skills and knowledge. This is normal - make sure to update the `MISSION.md` and add a learning record to capture the change. Confirm with the user before changing the mission.
-
-## Zone Of Proximal Development
-
-Each lesson, the user should always feel as if they are being challenged 'just enough'.
-
-The user may specify an exact thing they want to learn. If they don't, figure out their zone of proximal development by:
-
-- Reading their `learning-records`
-- Figuring out the right thing to teach them based on their mission
-- Teach the most relevant thing that fits in their zone of proximal development
-
-## Knowledge
-
-Lessons should be designed around a skill the user is going to learn. The knowledge in the lesson should be only what's required to acquire that skill. You teach the knowledge first, then get the user to practice the skills via an interactive feedback loop.
-
-Knowledge should first be gathered from trusted resources. Use `RESOURCES.md` to keep track of them. Lessons should be littered with citations - links to external resources to back up any claim made. This increases the trustworthiness of the lesson.
-
-For acquiring knowledge, difficulty is the enemy. It eats working memory you need for understanding.
-
-## Skills
-
-If knowledge is all about acquisition, skills are about durability and flexibility. Make the knowledge stick.
-
-For skill acquisition, difficulty is the tool. Effortful retrieval is what builds storage strength. Skills should be taught through interactive lessons. There are several tools at your disposal:
-
-- Interactive lessons, using quizzes and light in-browser tasks
-- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
-
-Each of these should be based on a **feedback loop**, where the user receives feedback on their performance. This feedback loop should be as tight as possible, giving feedback immediately - and ideally automatically.
-
-For quizzes, each answer should be exactly the same number of words (and characters, if possible). Vary which position holds the correct answer across questions. Don't give the user any clues about the answer through formatting or order.
-
-## Acquiring Wisdom
-
-Wisdom comes from true real-world interaction - testing your skills outside the learning environment.
-
-When the user asks a question that appears to require wisdom, your default posture should be to attempt to answer - but to ultimately delegate to a **community**.
-
-A community is a place (online or offline) where the user can test their skills in the real world. This might be a forum, a subreddit, a real-world class (budget permitting) or a local interest group.
-
-You should attempt to find high-reputation communities the user can join. If the user expresses a preference that they don't want to join a community, respect it.
-
-## Reference Documents
-
-While creating lessons, you should also create reference documents. Lessons can reference these documents - they are useful for tracking raw units of knowledge useful across lessons.
-
-Lessons will rarely be revisited later - reference documents will be. They should be the compressed essence of the lesson, in a format designed for quick reference.
-
-Some learning topics lend themselves to reference:
-
-- Syntax and code snippets for programming
-- Algorithms and flowcharts for processes
-- Yoga poses and sequences for yoga
-- Exercises and routines for fitness
-- Glossaries for any topic with its own nomenclature
-
-Glossaries, in particular, are an essential reference. Once one is created, it should be adhered to in every lesson.
-
-## `NOTES.md`
-
-The user will sometimes express preferences of how they want to be taught, or things you should keep in mind. This is the place to record those preferences, so you can refer back to them when designing lessons or working with the user.

package/skills/teach/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Teach"
-  short_description: "Learn a concept in a guided workspace"
-policy:
-  allow_implicit_invocation: false