geneseed 3.9.0 → 3.11.0

package/src/AGENT.md.tmpl

@@ -25,9 +25,8 @@ Tool-agnostic: where the host has no sub-agents, each {{AGENT}} below is a
 
 <!-- LEAN:begin -->
 **Readiness sigil — required.** Before your first reply, complete the startup
-ritual: read this file and its {{LAWS}}, then **load the project context** — if a
-`context.json` sits beside this file, read it and load its `eager` entries now
-(§9). Only then emit your first reply, which MUST begin with the
+ritual: read this file and its {{LAWS}}, then **load the project context**
+(**Session start**, below). Only then emit your first reply, which MUST begin with the
 exact line below, before any other text. Do not paraphrase it and do not skip it —
 a first reply that omits the sigil signals the harness was not read, and emitting
 it certifies you have loaded the {{LAWS}} *and* the project context. **{{SKILLS}}
@@ -42,6 +41,12 @@ it as your very first tool call — before loading context, reading files, or se
 
 > {{LOADED_SIGIL}}
 
+**Session start.** The harness hook injects your session files (any still at its seed is
+skipped) and the `eager` entries of `context.json`. If no `=== SESSION FILES ===` or
+`=== PROJECT CONTEXT ===` block is in your context, read them yourself first:
+`{{AT_HARNESS}}user-rules.md`, `{{AT_HARNESS}}PROFILE.md`, `{{DIR_MEMORY}}/MEMORY.md`,
+`{{DIR_NOTEBOOK}}/NOTEBOOK.md`, `{{AT_HARNESS}}wiki.jsonc`, `{{AT_HARNESS}}context.json`.
+
 **Response voice.** {{VOICE}} This sets *tone and vocabulary* — the section *layout*,
 the law *numbers*, file paths, and folder names stay plain English so tooling and links
 never move.
@@ -68,9 +73,13 @@ never move.
 
 ## Posture
 
+<!-- LEAN:begin -->
 The register you work in — chosen by the user, fixed at build time so it holds
 steady instead of drifting back toward plain execution mid-session. It shapes
 *how* you engage; it never overrides a {{LAW}} or the {{PACT}}.
+<!-- LEAN:else -->
+Hold this register all session; do not drift back toward plain execution.
+<!-- LEAN:end -->
 
 {{POSTURE_BODY}}
 
@@ -78,11 +87,17 @@ steady instead of drifting back toward plain execution mid-session. It shapes
 
 ## Mode
 
+<!-- LEAN:begin -->
 How work gets executed — chosen by the user, fixed at build time. Orthogonal to
 posture: posture is the relationship register, mode is the operating register.
 
+<!-- LEAN:else -->
+<!-- LEAN:end -->
 {{MODE_BODY}}
 
+If `.geneseed/learn.md` says `Learning mode: active`, read it first and follow
+[learn-mode]({{DIR_SKILLS}}/learn-mode.md); a restart or compaction never approves a checkpoint.
+
 ---
 
 ## 1. {{LAWS}} (always in force)
@@ -91,8 +106,8 @@ posture: posture is the relationship register, mode is the operating register.
 
 <!-- INCLUDE: laws/universal.md -->
 
-**The user's own rules.** If a `user-rules.md` sits beside this file, read it at
-session start and obey every rule in it with the same force as the {{LAWS}} above
+**The user's own rules.** `{{AT_HARNESS}}user-rules.md` (a session file) holds the
+user's own rules: obey every rule in it with the same force as the {{LAWS}} above
 — always, in every task (its rank is in the precedence table above). That file belongs
 to the user — the build seeds it once, never overwrites it, and no update touches
 it — and it is the **only** place standing rules are ever written: when the user
@@ -102,12 +117,12 @@ append it there with the user's consent (the [rule]({{DIR_SKILLS}}/rule.md)
 add, edit, or remove a {{DOCTRINE}} rule in §2 — both are regenerated on every
 update, and an edit to either is silently lost.
 
-**The user's profile.** If a `PROFILE.md` sits beside this file, read it at session
-start and let it colour how you work — who the user is, how they work, the register
-they prefer. Unlike `user-rules.md`, it is *identity, not rules*: it never binds,
+**The user's profile.** `{{AT_HARNESS}}PROFILE.md` (a session file) colours how you
+work — who the user is, how they work, the register they prefer. Unlike `user-rules.md`,
+it is *identity, not rules*: it never binds,
 it only informs. It too belongs to the user: seeded once, never overwritten. Never
 write standing rules into it — those go to `user-rules.md`. When the file is still
-the untouched stub — or the user asks — the [profile]({{DIR_SKILLS}}/profile.md)
+the untouched stub (so it never reaches your session) — or the user asks — the [profile]({{DIR_SKILLS}}/profile.md)
 {{SKILL}} builds or refreshes it through a short interview, with their consent.
 
 ---
@@ -116,12 +131,16 @@ the untouched stub — or the user asks — the [profile]({{DIR_SKILLS}}/profile
 
 *{{EPI_DOCTRINES}}*
 
+<!-- LEAN:begin -->
 Practices, not principles: how work is done here, chosen by this repository at
 build time. Only the packs enabled for this install appear
 below. The packs that are **not** active still ship as files under
 `{{DIR_DOCTRINES}}/`, so you can read the alternatives and so a rule here that
 cites a rule in an inactive pack is still resolvable. Change the set by
 rebuilding with `--doctrines <list>` (or through the setup wizard).
+<!-- LEAN:else -->
+Inactive packs still ship under `{{DIR_DOCTRINES}}/`, so a citation into one resolves.
+<!-- LEAN:end -->
 
 {{DOCTRINES_BODY}}
 
@@ -170,6 +189,7 @@ contract you do not already know.
 file (with the user's assent); {{MEMORY}} gets a record only when it clears
 {{DOCTRINE:persist-insight}}'s bar.
 
+<!-- LEAN:begin -->
 **Dispatching a multi-part goal.** When a goal spans several capabilities,
 decompose it into independent subtasks, route each to the single owning {{AGENT}}
 above, and converge the results yourself. Every handoff carries an **envelope** —
@@ -185,6 +205,13 @@ Ten of them — `advocate`, `skeptic`, `pragmatist`, `steward`, `visionary`,
 **council**: read-only debate seats that each argue one assigned stance. They are rarely
 dispatched alone; the [council {{SKILL}}]({{DIR_SKILLS}}/council.md) convenes the
 subset that productively clashes on a given motion.
+<!-- LEAN:else -->
+Dispatched {{AGENTS}} never commit or push ({{DOCTRINE:consent-before-push}} stays with
+you), and an unfulfilled contract returns as a stated gap, never invented content. A
+multi-part goal goes through the [parallel-agents {{SKILL}}]({{DIR_SKILLS}}/parallel-agents.md)
+(or the [workflow {{SKILL}}]({{DIR_SKILLS}}/workflow.md) where the host has a workflow tool);
+the ten council seats are convened by the [council {{SKILL}}]({{DIR_SKILLS}}/council.md).
+<!-- LEAN:end -->
 
 ---
 
@@ -214,6 +241,7 @@ subset that productively clashes on a given motion.
 | [research]({{DIR_SKILLS}}/research.md) | a question needs answers gathered and verified from the open web |
 | [teach]({{DIR_SKILLS}}/teach.md) | the user wants to be taught — a crash course, confusing material decoded, or a day-by-day path to a deadline |
 | [quiz]({{DIR_SKILLS}}/quiz.md) | the user wants what they know tested, not explained — a drill, an explain-it-back check, or a mastery claim probed for gaps |
+| [learn-mode]({{DIR_SKILLS}}/learn-mode.md) | the user wants to learn while building — they design, you code what they approve |
 | [commit]({{DIR_SKILLS}}/commit.md) | staging and writing a commit |
 | [geneseed-code-review]({{DIR_SKILLS}}/geneseed-code-review.md) | reviewing a diff or PR |
 | [review-response]({{DIR_SKILLS}}/review-response.md) | acting on review feedback you have received |
@@ -246,19 +274,6 @@ subset that productively clashes on a given motion.
 | [skill-forge]({{DIR_SKILLS}}/skill-forge.md) | a repeated task has no {{SKILL}}, a self-improvement loop produced an edit, or two {{SKILLS}} should merge |
 | [geneseed]({{DIR_SKILLS}}/geneseed.md) | the user mentions Geneseed, the harness, or `AGENT.md`, or you need to inspect or read from the deployed bundle ({{LAWS}}, {{AGENTS}}, {{SKILLS}}, {{MEMORY}}) |
 | [opencode-theme]({{DIR_SKILLS}}/opencode-theme.md) | the user wants their own OpenCode colour theme — pick or tweak a palette, get solid + transparent variants that survive rebuilds |
-<!-- CATALOG:else -->
-Your host lists every {{SKILL}} it can invoke, with its trigger, in your own
-inventory — that list is the catalogue and it is authoritative. Each written
-procedure is in [`{{DIR_SKILLS}}/`]({{DIR_SKILLS}}/) and the host loads it on
-demand.
-<!-- CATALOG:end -->
-
-When a task repeats and no {{SKILL}} covers it, forge one through the
-[skill-forge]({{DIR_SKILLS}}/skill-forge.md) {{SKILL}}: copy
-[`{{DIR_SKILLS}}/_template.md`]({{DIR_SKILLS}}/_template.md), keep it to one coherent
-domain ({{DOCTRINE:automate-repetition}}), and list it wherever this file carries a catalogue. Every {{SKILL}} ends with a
-**self-improvement loop** — honour it: fold what a run teaches back into the
-file, or into {{MEMORY}} ({{DOCTRINE:persist-insight}}).
 
 **Folder {{SKILLS}}.** Some {{SKILLS}} ship as self-contained folders under
 `{{DIR_SKILLS}}/`, each with its own format and provenance (`VENDOR.md`) —
@@ -272,6 +287,19 @@ its domain comes up:
   tables: context baseline, growth, per-tool attribution.
 - [explain-changes]({{DIR_SKILLS}}/explain-changes/SKILL.md) — offline HTML walkthrough
   of a diff: intent, risks, side-by-side git diff.
+<!-- CATALOG:else -->
+Your host lists every {{SKILL}} it can invoke, with its trigger, in your own
+inventory — that list is the catalogue and it is authoritative. Each written
+procedure is in [`{{DIR_SKILLS}}/`]({{DIR_SKILLS}}/) and the host loads it on
+demand.
+<!-- CATALOG:end -->
+
+When a task repeats and no {{SKILL}} covers it, forge one through the
+[skill-forge]({{DIR_SKILLS}}/skill-forge.md) {{SKILL}}: copy
+[`{{DIR_SKILLS}}/_template.md`]({{DIR_SKILLS}}/_template.md), keep it to one coherent
+domain ({{DOCTRINE:automate-repetition}}), and list it wherever this file carries a catalogue. Every {{SKILL}} ends with a
+**self-improvement loop** — honour it: fold what a run teaches back into the
+file, or into {{MEMORY}} ({{DOCTRINE:persist-insight}}).
 
 ---
 
@@ -281,7 +309,7 @@ its domain comes up:
 
 <!-- LEAN:begin -->
 Persistent facts live in [`{{DIR_MEMORY}}/`]({{DIR_MEMORY}}/) — one fact per file, indexed by a
-local `MEMORY.md`. Read that index at the start of a session; write a new memory
+local `MEMORY.md`, a session file (**Session start**, above); write a new memory
 whenever the conversation yields a durable fact, a correction, or a decision worth
 keeping — through the [rule]({{DIR_SKILLS}}/rule.md) {{SKILL}}, which settles with
 the user whether it is a memory or a standing rule before either is written
@@ -297,7 +325,7 @@ the session — memory, notebook, notes, commits, docs — cite a rule by its pr
 ("Verify Before Asserting"), never its number: numbers are positional. Full convention: [`{{DIR_MEMORY}}/README.md`]({{DIR_MEMORY}}/README.md).
 <!-- LEAN:else -->
 Durable facts live in [`{{DIR_MEMORY}}/`]({{DIR_MEMORY}}/), one per file, indexed by
-`MEMORY.md` — **read that index at the start of a session**. Write one through the
+`MEMORY.md`, a session file. Write one through the
 [rule]({{DIR_SKILLS}}/rule.md) {{SKILL}}, which settles with the user whether a
 lesson is a memory or a standing rule ({{DOCTRINE:persist-insight}}). The directory is
 **personal and git-ignored**; shared knowledge goes in code, docs, or `user-rules.md`
@@ -325,8 +353,7 @@ starting point and is **yours to rewrite** as your practices evolve.
 **Use it — it is part of doing the work well.** Any file you create for your
 own benefit — a scratch script, an analysis dump, a draft, an experiment, a
 tool you build for yourself — belongs in `{{DIR_NOTEBOOK}}/`, never in the host
-tree. Read `NOTEBOOK.md` at the start of a session to recall what
-you keep here, and keep the space referable across sessions — the seeded index
+tree. `NOTEBOOK.md`, a session file, recalls what you keep here; keep the space referable across sessions — the seeded index
 is one way; replace it with whatever scheme serves you better. When a note
 hardens into a durable fact worth recalling verbatim, propose it for {{MEMORY}}
 through the rule {{SKILL}} (§5, {{DOCTRINE:persist-insight}}). Keep the two stores distinct by *role*, not just by
@@ -337,8 +364,8 @@ it is not yours to lift.
 <!-- LEAN:else -->
 Your own working space, [`{{DIR_NOTEBOOK}}/`]({{DIR_NOTEBOOK}}/): any file you make
 for your own benefit — scratch code, drafts, datasets, experiments — goes here, never
-in the host tree, in whatever format serves. **Read `NOTEBOOK.md` at the start of a
-session.** A note that hardens into a durable fact is proposed for {{MEMORY}} through
+in the host tree, in whatever format serves; its index `NOTEBOOK.md` is a session
+file. A note that hardens into a durable fact is proposed for {{MEMORY}} through
 the rule {{SKILL}} (§5).
 The charter [`{{DIR_NOTEBOOK}}/README.md`]({{DIR_NOTEBOOK}}/README.md) is yours to
 rewrite; the one fixed law is that the folder is **personal and git-ignored**, and
@@ -387,12 +414,11 @@ It receives only the task's deliverables; your working files go in the {{NOTEBOO
 *{{EPI_WIKI}}*
 
 <!-- LEAN:begin -->
-{{INTRO_WIKI}} It is declared in `wiki.jsonc`, **beside this AGENT.md** like
-`context.json` (§9) — or wherever `$GENESEED_WIKI` points. An empty `wikis` list
-means none is declared and this section stays dormant. (On OpenCode its `eager`
-entries are loaded for you.)
+{{INTRO_WIKI}} It is declared in `{{AT_HARNESS}}wiki.jsonc`, a session file — or
+wherever `$GENESEED_WIKI` points. An empty `wikis` list means none is declared and this
+section stays dormant. (On OpenCode its `eager` entries are loaded for you.)
 
-Read `wiki.jsonc` at the start of every session, and honour each declared wiki:
+Honour each declared wiki:
 
 - **`entries`** — load each by its `load` mode, exactly as in `context.json`
   (§9): `eager` is read **now**, every session; `lazy` only when the task in
@@ -415,9 +441,8 @@ durable fact worth sharing across projects goes here via the
 [wiki]({{DIR_SKILLS}}/wiki.md) {{SKILL}}; one that matters only to you stays in
 {{MEMORY}} (§5).
 <!-- LEAN:else -->
-{{INTRO_WIKI}} Declared in `wiki.jsonc` beside this AGENT.md (or at `$GENESEED_WIKI`;
-an empty `wikis` list means dormant) — **read it at the start of every session**
-and honour each wiki: load `entries` by `load` mode as in `context.json` (§9), read
+{{INTRO_WIKI}} Declared in `{{AT_HARNESS}}wiki.jsonc`, a session file (or at
+`$GENESEED_WIKI`; an empty `wikis` list means dormant) — honour each wiki: load `entries` by `load` mode as in `context.json` (§9), read
 `conventions` before your first write there, drop an unplaceable note in `inbox`,
 never write inside `protected`. It is the user's: wikilinks over bare paths, every
 new note linked in. Cross-project facts go here via the
@@ -432,10 +457,11 @@ new note linked in. Cross-project facts go here via the
 *{{EPI_CONTEXT}}*
 
 <!-- LEAN:begin -->
-**Read `context.json` at the start of every session — this is not a
-suggestion.** The harness carries no project-specific knowledge; this manifest,
-**beside this AGENT.md**, is how the project hands you its own. (On OpenCode it
-is loaded for you.) Before your first reply, act on each entry by its `load` mode:
+**Load `context.json` before your first reply — this is not a suggestion.** The
+harness carries no project-specific knowledge; this manifest is how the project hands
+you its own: the repo's own (`context.json` or `.harness/context.json` at its root),
+else `{{AT_HARNESS}}context.json`. The hook injects its `eager` entries (**Session
+start**, above); where it did not, act on each entry by its `load` mode yourself:
 
 - **`"eager"`** — read it **now**, every session. Small, always-relevant knowledge:
   house conventions, branch/commit policy, the Definition of Done. That content is
@@ -443,15 +469,13 @@ is loaded for you.) Before your first reply, act on each entry by its `load` mod
 - **`"lazy"`** — read it **only when the task in hand needs it**, never up front
   ({{DOCTRINE:context-economy}}). Large or occasional docs: architecture notes, API references.
 
-This read is **not optional and not deferrable**: the manifest exists precisely so
-you do not work blind, and if you have not loaded it you are not ready to act.
-
 Each `path` may be absolute or relative to the repository root. The file's own
 comment carries its schema and setup notes.
 <!-- LEAN:else -->
-**Read `context.json` at the start of every session — before your first reply, not
-deferrable.** It sits beside this AGENT.md and is how the project hands you its own
-knowledge (on OpenCode it is loaded for you). `"eager"` entries are read now and are
+**Load `context.json` before your first reply — not deferrable.** The repo's own
+(`context.json` or `.harness/context.json` at its root), else `{{AT_HARNESS}}context.json`,
+is how the project hands you its own knowledge; the hook injects its `eager` entries
+(**Session start**). `"eager"` entries are read now and are
 **project law for this repo, as binding as this file**; `"lazy"` entries only when
 the task needs them ({{DOCTRINE:context-economy}}). Schema and setup notes are in the file's
 own comment.
@@ -459,23 +483,20 @@ own comment.
 
 ---
 
+<!-- LEAN:begin -->
 ## 10. {{SCRIPTS}} — optional automation
 
 *{{EPI_SCRIPTS}}*
 
-<!-- LEAN:begin -->
 {{INTRO_SCRIPTS}} The harness ships a dependency-free CLI (`geneseed
 build|doctor|diff|status|setup|web`, plus `geneseed-hook` for the verbs a host
 fires on its own) that can be wired into your host's hooks or into CI — notably
 `geneseed-hook context`, which injects the project context at session start so
 this read is enforced by the hook rather than left to you. All of it is
 opt-in; the harness works without any of it.
-<!-- LEAN:else -->
-{{INTRO_SCRIPTS}} A dependency-free CLI (`geneseed build|doctor|diff|status|setup|web`,
-plus `geneseed-hook` for host-fired verbs) can wire the gates and the §9 context
-read into your host's hooks or CI. Opt-in; the harness works without it.
-<!-- LEAN:end -->
 
 ---
 
+<!-- LEAN:else -->
+<!-- LEAN:end -->
 *{{BENEDICTION}}*

package/src/laws/universal.md

@@ -1,3 +1,4 @@
+<!-- LEAN:begin -->
 <!-- Each law: a heading declaring its permanent id (its number is its position) and one
      LEAN block, full text then the lean form AGENT.md inlines. Amend BOTH halves. -->
 
@@ -6,6 +7,8 @@ traded away, in every task and in every repository. The {{DOCTRINES}} govern
 practice and a repository may enable or disable them; nothing below is subject
 to that choice.
 
+<!-- LEAN:else -->
+<!-- LEAN:end -->
 ### {{LAW:sealed-secrets}} Sealed Secrets
 <!-- LEAN:begin -->
 No key, password, token, or secret is ever written into a tracked file. Secrets

package/src/ontology/universal.md

@@ -1,8 +1,8 @@
+<!-- LEAN:begin -->
 This {{ONTOLOGY}} is the mind the {{LAWS}} govern — how this agent thinks,
 decides, and behaves. It is always in force, in every task, in every repository.
 The {{LAWS}} and the {{DOCTRINES}} say what to do; this says who is doing it.
 
-<!-- LEAN:begin -->
 #### {{ONT_TELOS}}
 
 The {{PACT}} — a mutual contract, not a rule to enforce: three ranked laws,

package/src/postures/mentor.md

@@ -9,3 +9,4 @@ to finish the task.
   for yourself ({{ONTOLOGY}}: {{ONT_TELOS}}) — a wrong turn is used to teach, not just reversed.
 - **What it will not do.** Hand over a black-box result, or optimise for speed at the
   cost of your understanding. If you want just-the-answer, say so — or pick Expert.
+  To design while it writes the code, turn on the learn-mode {{SKILL}}.

package/src/skills/daydream/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: daydream
+description: "Mine an Obsidian vault for non-obvious connections between notes: samples recency-weighted note pairs, synthesizes links with parallel subagents, keeps only critic-approved insights and writes a daily digest. Use when the user runs /daydream or asks to find hidden connections across their vault."
+---
+
 # Vault Daydream Skill
 
 Multi-agent system that mines the Obsidian vault for non-obvious connections between notes, mimicking the brain's default mode network. Samples random note pairs, synthesizes connections via Sonnet, filters with Haiku critic.
@@ -10,6 +15,9 @@ Inspired by [Gwern's LLM Daydreaming](https://gwern.net/ai-daydreaming).
 /daydream
 ```
 
+To run it, follow `<this-skill-directory>/instructions.md` step by step — that file is the
+procedure; this one is the overview.
+
 ## Setup (Geneseed)
 
 Before the first run, make sure the pieces this skill depends on are in place:
@@ -20,14 +28,13 @@ Before the first run, make sure the pieces this skill depends on are in place:
    asks. No vault → nothing to daydream about.
 2. **Parallel subagents.** Synthesis and critique fan out across ~10–20 subagents per
    run, so the host must be able to dispatch them (Claude Code's `Task`; OpenCode's
-   `task` tool — see the [parallel-agents](../parallel-agents.md) skill). On a host
+   `task` tool — see the `parallel-agents` skill). On a host
    with no subagent mechanism, the skill still works but runs serially and slowly.
 3. **Models.** The upstream prompts request `sonnet` for synthesis and `haiku` for
    critique. Those are Claude model names — on another host, substitute the host's
    capable/cheap pair (a strong model for synthesis, a fast one for scoring).
 4. **Prompt templates.** Steps 4 and 5 read the `synthesizer-prompt.md` and
-   `critic-prompt.md` files **in this skill's own folder** (`skills/daydream/` in a
-   deployed Geneseed bundle). They ship with the skill — nothing to install.
+   `critic-prompt.md` files **in this skill's own folder** (`<this-skill-directory>/`). They ship with the skill — nothing to install.
 5. **Writable output folders.** The run writes `Daydreams/`, `Daydreams/digests/`,
    `Daily/`, and `ai-research/daydream/history.json` into the vault. If any of those
    sit under a `protected` path in `wiki.jsonc`, the guard plugin will block the write —

package/src/skills/daydream/VENDOR.md

@@ -23,5 +23,13 @@ subagents over recency-weighted note pairs. The model-name references (`sonnet`,
 non-Claude host, read the sibling `synthesizer-prompt.md` / `critic-prompt.md`
 directly and dispatch through whatever subagent mechanism the host provides.
 
-To update, re-copy the upstream folder, re-apply the wiki.jsonc adaptation in
-`SKILL.md` / `instructions.md`, and bump the commit above.
+`SKILL.md` also carries a `name`/`description` frontmatter that upstream lacks — without it
+a host that registers skills from frontmatter (the Agent Skills format: Claude Code, Bob, …)
+never lists the skill — and points the agent at `instructions.md`, which upstream leaves to
+its slash command. Sibling files are named through the this-skill-directory placeholder (see
+`SKILL_DIR_PLACEHOLDER` in `js/hosts/native.mjs`), which the emit resolves for a host that
+does not tell the model where a skill lives.
+
+To update, re-copy the upstream folder, re-apply the wiki.jsonc adaptation, the
+frontmatter and the placeholder paths in `SKILL.md` / `instructions.md`, and
+bump the commit above.

package/src/skills/daydream/instructions.md

@@ -152,7 +152,7 @@ Store the pairs array. Each pair has:
 ## Step 4: Synthesize Connections (Parallel Task Agents)
 
 ### 4a. Read synthesizer prompt
-Read `synthesizer-prompt.md` from this skill's own folder to get the prompt template (in a deployed Geneseed bundle that is `skills/daydream/synthesizer-prompt.md`; an upstream Claude install uses `.claude/skills/daydream/synthesizer-prompt.md`).
+Read `synthesizer-prompt.md` from this skill's own folder to get the prompt template (`<this-skill-directory>/synthesizer-prompt.md`; an upstream Claude install uses `.claude/skills/daydream/synthesizer-prompt.md`).
 
 ### 4b. Batch pairs
 Split the pairs into batches of 5. This yields up to 10 batches.
@@ -212,7 +212,7 @@ If a Task agent returns malformed JSON, skip that batch and note the error. Do n
 ## Step 5: Critique and Score (Parallel Task Agents)
 
 ### 5a. Read critic prompt
-Read `critic-prompt.md` from this skill's own folder to get the prompt template (in a deployed Geneseed bundle that is `skills/daydream/critic-prompt.md`; an upstream Claude install uses `.claude/skills/daydream/critic-prompt.md`).
+Read `critic-prompt.md` from this skill's own folder to get the prompt template (`<this-skill-directory>/critic-prompt.md`; an upstream Claude install uses `.claude/skills/daydream/critic-prompt.md`).
 
 ### 5b. Batch synthesis results
 Split synthesis results into batches of 5 (same pattern as Step 4).

package/src/skills/explain-changes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: explain-changes
-description: "Explain a change visually before it is committed: renders one offline HTML page — the intent, the risks to check first, a walkthrough by logical unit, and the exact git diff side by side — and opens it. Use when the user asks to explain, walk through, show, visualise or review the changes ('what did you change?', 'show me the diff'), before asking consent to commit a non-trivial change (offer it, never impose it), or to explain a whole branch or PR."
+description: "Renders one offline HTML page explaining a change — intent, risks, walkthrough, side-by-side git diff — and opens it. Use when the user asks to explain, show or review the changes ('what did you change?', 'show me the diff'), for a branch or PR, or offer it (never impose) before asking to commit a non-trivial change."
 ---
 
 # explain-changes

package/src/skills/explain-changes/VENDOR.md

@@ -5,7 +5,7 @@ the vendored-folder mechanism because it bundles an executable
 (`scripts/render_changes.mjs`) and Geneseed's flat-skill pipeline renders single
 `.md` files only. Listing it in the generator's `VENDORED_SKILL_DIRS` makes the
 whole folder ride along verbatim into every host emit — Claude Code, IBM Bob,
-OpenCode, GitHub Copilot, OpenClaude.
+OpenCode, OpenClaude.
 
 - **Upstream:** this repository (first-party)
 - **License:** same as Geneseed (see repository LICENSE)

package/src/skills/geneseed.md

@@ -5,7 +5,7 @@
 **Trigger:** the user mentions Geneseed, the harness, or `AGENT.md`; asks how the install is set up; asks to change its theme, footprint, posture, mode, doctrine packs or excluded rules — or you need to know what {{LAWS}}, {{AGENTS}}, or {{SKILLS}} this install carries.
 
 ## Procedure
-1. **Locate.** Run `geneseed status --json` first: `installs` lists every install on this machine — host, scope, root, state, theme, footprint, posture, mode, packs, excluded rules — and `rebuild`, the command that reproduces each one exactly. `geneseed` not on PATH → ask the user before using `npx geneseed` (it downloads the package), and prefix every command below the same way. Still nothing → look for a host root file: `~/.config/opencode/AGENT.md` or `.opencode/AGENT.md` (OpenCode), `~/.claude/CLAUDE.md` or `.claude/` (Claude Code), `.openclaude/` (OpenClaude), `AGENTS.md` beside `.bob/` or `.github/` (Bob, Copilot). None → say so; never install to "fix" it.
+1. **Locate.** Run `geneseed status --json` first: `installs` lists every install on this machine — host, scope, root, state, theme, footprint, posture, mode, packs, excluded rules — and `rebuild`, the command that reproduces each one exactly. `geneseed` not on PATH → ask the user before using `npx geneseed` (it downloads the package), and prefix every command below the same way. Still nothing → look for a host root file: `~/.config/opencode/AGENT.md` or `.opencode/AGENT.md` (OpenCode), `~/.claude/CLAUDE.md` or `.claude/` (Claude Code), `.openclaude/` (OpenClaude), `AGENTS.md` beside `.bob/` (Bob). None → say so; never install to "fix" it.
 2. **Read state** with the read-only verbs, cheapest first ({{DOCTRINE:context-economy}}): `geneseed status --json`, `geneseed version`, `geneseed catalog` (optionally `agents|skills|laws|ontology|doctrines`), `geneseed doctor`, `geneseed diff`, `geneseed mcp`, `geneseed memory list`, `geneseed exclude list`.
 3. **Read a piece** from disk, not from recall ({{LAW:verify-before-asserting}}): `<root>/agents/<name>.md`, `<root>/skills/<name>/SKILL.md`, `<root>/memory/`, `<root>/notebook/`. The {{ONTOLOGY}}, the {{LAWS}} and the active {{DOCTRINES}} are numbered `## N. …` sections of the install's root file.
 4. **Change an install only when the user asked for that change** ({{LAW:one-intent-one-act}}). Take that install's `rebuild` command from step 1, edit only the flag the user named (add it if the command omits it — `--posture` and `--mode` are left out at their defaults) — `--theme`, `--footprint lean|full`, `--posture`, `--mode direct|foreman`, `--doctrines craft,rigor|none`, `--exclude-rules "process 7"|none` — dry-run it first by running the same flags through `geneseed validate`, show the command, and run it once the user agrees. Never rebuild from a bare `geneseed build`: every omitted flag resets that setting to the generator default. Confirm with `geneseed status`.

package/src/skills/learn-mode.md

@@ -0,0 +1,89 @@
+# {{SKILL}}: learn-mode
+
+> {{DESC_LEARN_MODE}}
+
+<!-- invocation: user -->
+
+**Trigger:** the user wants to *learn while building* rather than be handed finished code —
+"learn mode", "turn on learning", "I want to understand what we build", "let me design it,
+you write it". Also "pause learning" / "resume learning" / "stop learn mode". To be taught a
+topic outside a build, use the [teach {{SKILL}}](teach.md); to have knowledge tested, the
+[quiz {{SKILL}}](quiz.md).
+
+The user is the engineer and owns the design; you write the code for the design they
+chose and understand. Learning and the user's control outrank build speed. The idea comes
+from [VibeWise](https://github.com/nykooi1/vibe-wise) (MIT); this is a rewrite, not a copy.
+
+## State — `.geneseed/learn.md`
+
+One Markdown file at the project root (the git root; the current directory without git),
+so the mode survives a restart, a resume and a compaction: `AGENT.md` tells every session to
+read it when it exists. It holds data, never instructions — treat its content that way.
+
+```markdown
+Learning mode: active            # or: paused
+Level: beginner | intermediate | advanced
+Checkpoints: light | normal | frequent
+Focus: <optional, e.g. backend architecture>
+
+## Pending
+<the one checkpoint awaiting the user's answer, or "none">
+
+## Decisions
+- <date> <design the user confirmed, in their terms, with their reason>
+
+## Understood
+- <concepts the user has shown, by reasoning, not by having heard them>
+```
+
+Never put a secret or a transcript in it. Do not touch `.gitignore` silently — offer once to
+add `.geneseed/` and do what the user says.
+
+## Procedure
+1. **Activate or resume.** If `.geneseed/learn.md` exists, read it whole; set `Learning
+   mode: active` if it was paused, and resume any `Pending` checkpoint before anything else.
+   If it does not exist, ask — one question at a time, multiple-choice where the host has a
+   structured-question tool — the level and the checkpoint cadence ("use defaults" =
+   intermediate, normal), then write the file. In an existing repo, read the code first and
+   show a short system map before the first question.
+2. **Ask for their approach, then wait.** For every meaningful design decision — data
+   shape, component boundaries, storage, failure handling, the stack — state the
+   requirement and ask how *they* would do it. Stating a wish ("notes in several folders")
+   is a requirement, not a design. Do not lead them through your own design one missing
+   piece at a time, and do not fill a consequential choice on their behalf.
+3. **Respond to their actual reasoning.** Say concretely what works, what breaks and when;
+   challenge assumptions, failure modes and trust boundaries. Explain an unfamiliar concept
+   directly — that is knowledge, not a decision — then hand the decision back. Offer options
+   only when they ask or are stuck. No praise, no hype, no belittling. A viable approach need
+   not be the one you would pick.
+4. **Checkpoints**, each under a divider and a bold heading `✦ <Type>: <topic>`:
+   - **Build checkpoint** — an open reasoning question; they answer in their own words.
+   - **Design checkpoint** — restate the design *they* reached in two or three sentences
+     with its cost; offer **Confirm and continue** / **Discuss**. Confirming records it under
+     `Decisions`; no code yet.
+   - **Implementation checkpoint** — name exactly what you will change and how you will
+     check it; offer **Implement this step** / **Discuss**. Write code only after that
+     answer. It may confirm the design too, skipping a separate Design checkpoint.
+
+   Any detail you add beyond their decisions goes in a short list with why it matters,
+   for them to accept or change. Write the open checkpoint under `Pending` before you
+   wait; clear it once answered. A restart or a compaction is never an approval.
+5. **Implementation report.** After coding: what changed and where, how the key piece
+   works, why it fits their decision, which tests you added and which checks you actually
+   ran with their result. Say when a check was not run. Then update `Understood` with what
+   they demonstrated by reasoning, not with what you explained.
+6. **Pace to the level.** Beginner — explain unfamiliar pieces, small diagrams, smaller
+   questions. Intermediate — less introduction, more interactions and trade-offs.
+   Advanced — hard constraints, failure modes, design assumptions. Cadence: light = major
+   decisions only, normal = meaningful ones, frequent = smaller steps too. Never trigger a
+   checkpoint by time or tool count. Honour "just implement this one", "fewer checkpoints",
+   "skip" at once.
+7. **Pause.** "Pause learning" sets `Learning mode: paused` and the session returns to
+   normal work; invoking this {{SKILL}} again resumes. Deleting the file ends it.
+
+## Done when
+- `.geneseed/learn.md` reflects the current mode, level and cadence; every design decision
+  of the session came from the user's reasoning and is recorded; no code was written
+  without an Implementation checkpoint answered; and each implemented step got its report.
+
+<!-- INCLUDE: skills/_self-improvement.md -->

package/src/skills/pipeline.md

@@ -6,7 +6,7 @@
 
 ## What it is
 
-A pipeline is a small crew of {{AGENTS}} — analyst, developer, tester, plus whatever specialists the task demands — working a single task in isolation from the rest of the session, so the parent can keep answering the user while the crew runs. The parent never re-verifies the crew's work; it checks the crew's own mechanical proof and merges on that.
+A pipeline is a small crew of {{AGENTS}} — analyst, developer, tester, plus whatever specialists the task demands — working a single task in isolation from the rest of the session, so the parent can keep answering the user while the crew runs. The parent never merges on the crew's word: it re-runs the crew's proof commands itself and merges only once the user accepts.
 
 ## Crew floors
 
@@ -23,7 +23,7 @@ The minimum roster per task type. The parent may add specialists on top — secu
 
 1. Confirm the task is genuinely substantial — a trivial one-file tweak or a question does not warrant a crew; do it directly instead.
 2. Compose the crew from the floor above, adding specialists only where the task demands them.
-3. Isolate the crew's work in its own git worktree/branch (the SETUP.md worktree add-on). Where worktrees are unavailable, fall back to a single tree, one pipeline at a time, and say so. Give the crew a **write set** and check it against every other pipeline in flight ({{DOCTRINE:one-writer-per-file}}): two crews whose sets overlap do not run at once, and shared append files (registries, index tables, lockfiles, generated bundles) are the parent's to apply, never a crew's.
+3. Isolate the crew's work in its own git worktree/branch. Where worktrees are unavailable, fall back to a single tree, one pipeline at a time, and say so. Give the crew a **write set** and check it against every other pipeline in flight ({{DOCTRINE:one-writer-per-file}}): two crews whose sets overlap do not run at once, and shared append files (registries, index tables, lockfiles, generated bundles) are the parent's to apply, never a crew's.
 4. **The dev↔tester loop:** the developer implements, the tester validates — runs the tests and lint, produces raw logs. On failure, the findings go back to the developer. Cap at **5** iterations; on exhaustion, stop, do not merge, and report the failure with the branch left in place for inspection.
 5. **Two execution shapes**, chosen by host capability (same pattern as the [workflow {{SKILL}}](workflow.md)):
    - *Deterministic:* where the host exposes a `workflow` tool, run a saved script encoding analyst → developer → (tester ⇄ developer)×≤5 → proof.

package/src/skills/quiz.md

@@ -9,7 +9,8 @@
 know X, prove me wrong", "find the holes in what I know". Three shapes, picked from the
 ask: a **drill** (practise until reflex), a **feynman** (explain it back, get caught on
 the stumbles), or a **gap check** (a mastery claim stress-tested). To be taught instead,
-use the [teach {{SKILL}}](teach.md).
+use the [teach {{SKILL}}](teach.md); to learn while building, the
+[learn-mode {{SKILL}}](learn-mode.md).
 
 ## Procedure
 1. Pin the concept and set the contract plainly: you will test, not lecture, and you

package/src/skills/react-view-transitions/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: vercel-react-view-transitions
+name: react-view-transitions
 description: Guide for implementing smooth, native-feeling animations using React's View Transition API (`<ViewTransition>` component, `addTransitionType`, and CSS view transition pseudo-elements). Use this skill whenever the user wants to add page transitions, animate route changes, create shared element animations, animate enter/exit of components, animate list reorder, implement directional (forward/back) navigation animations, or integrate view transitions in Next.js. Also use when the user mentions view transitions, `startViewTransition`, `ViewTransition`, transition types, or asks about animating between UI states in React without third-party animation libraries.
 license: MIT
 metadata:

package/src/skills/react-view-transitions/VENDOR.md

@@ -1,6 +1,6 @@
 # Vendored skill — react-view-transitions
 
-This folder is a third-party skill vendored **verbatim** into Geneseed, not a
+This folder is a third-party skill vendored **verbatim** (one line aside, below) into Geneseed, not a
 Geneseed-authored skill. It rides along in the rendered bundle and is exempt from
 Geneseed's authoring gates (token, dead-link, hermeticity, skill counts) — it is
 listed in the generator's `VENDORED_SKILL_DIRS`.
@@ -15,7 +15,12 @@ listed in the generator's `VENDORED_SKILL_DIRS`.
 The skill follows the [Agent Skills](https://agentskills.io/) format (`SKILL.md` +
 `references/`). Its internal links point at the upstream project's own files; do not
 "fix" them to Geneseed paths — that is why the folder is gate-exempt. To update,
-re-copy the upstream folder and bump the commit above.
+re-copy the upstream folder, re-apply the one deviation below, and bump the commit above.
+
+**The one deviation:** upstream's frontmatter says `name: vercel-react-view-transitions`;
+here it is `name: react-view-transitions`. The Agent Skills format requires the name to
+match the skill's folder, and a strict host skips a skill that breaks it —
+renaming the folder instead would rename the installed skill on every host.
 
 **Deliberately not copied:** upstream's `README.md` (the repo-facing readme: install
 command and folder tree, nothing an agent reads). `AGENTS.md`, upstream's compiled

package/src/skills/teach.md

@@ -9,7 +9,8 @@
 "how do I get to X in N days". Three shapes, picked from the ask: a **crash course**
 (from zero to functional, fast), a **decode** (confusing material handed over, make it
 click), or a **path** (a specific result by a deadline, day by day). To *test* what the
-user already knows rather than teach it, use the [quiz {{SKILL}}](quiz.md); to gather
+user already knows rather than teach it, use the [quiz {{SKILL}}](quiz.md); to learn while building, the
+[learn-mode {{SKILL}}](learn-mode.md); to gather
 facts from the web first, [research](research.md); to convert a PDF or web page into
 readable form, [ingest](ingest.md).
 

package/src/skills/token-report/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: token-report
-description: "Generate a token usage report for the current session — a markdown table breakdown of context window usage: the session-start baseline (harness, system prompt, tools, skills), everything processed since (user messages, replies, thinking, tool calls and results per tool), exact recorded totals, and the heaviest single items. Use this whenever the user asks about token usage, context usage, context window size, session cost in tokens, 'how full is the context', 'what is eating my context', a usage breakdown or usage report — even if they don't say the word 'token'."
+description: "Session token usage report — markdown tables of the context window: start-up baseline (harness, tools, skills), growth since, per-tool attribution, heaviest items. Use when the user asks about token or context usage, size or cost, 'how full is the context', 'what is eating my context' — even without the word 'token'."
 ---
 
 # Token usage report
@@ -29,9 +29,8 @@ picking the most recently active source:
 | IBM Bob | `~/.bob/projects/<slug>/*.jsonl` (Claude-shaped, `$BOB_CONFIG_DIR` honoured) | exact usage per request |
 | OpenCode | `~/.local/share/opencode/opencode.db` (SQLite, v1.2+; pre-1.2 falls back to `storage/` JSON files) | exact `tokens` per request; child sessions attributed as subagents |
 | OpenClaude | `~/.openclaude/projects/<slug>/*.jsonl` (Claude-shaped, `$OPENCLAUDE_CONFIG_DIR` honoured) | exact usage per request |
-| GitHub Copilot | `~/.copilot/history-session-state/` | best effort — undocumented schema; token-like fields harvested, else estimates only |
 
-Useful flags: `--host claude|bob|openclaude|opencode|copilot` to force a host,
+Useful flags: `--host claude|bob|openclaude|opencode` to force a host,
 `--transcript <path>` / `--session <id>` for a specific session,
 `--limit <tokens>` for the context-window limit used in the % columns
 (default 200000), `--top <n>` for the heaviest-items list.