geneseed 3.9.0 → 3.10.0

package/js/web/actions.mjs

@@ -41,7 +41,7 @@ import { excludeAdd, excludeRemove } from '../inspect/excludes.mjs';
 import { setupBuildArgs } from '../build/generate.mjs';
 import { frontmatter, memoryDropIndex } from '../hosts/hooks.mjs';
 import {
-  HOSTS, bobConfigDir, claudeConfigDir, copilotConfigDir, expanduser, openclaudeConfigDir,
+  HOSTS, bobConfigDir, claudeConfigDir, expanduser, openclaudeConfigDir,
   opencodeConfigDir, resolvePath,
 } from '../hosts/hosts.mjs';
 import {
@@ -644,7 +644,7 @@ export function apiMcpToggle(state, body) {
     return { ok: false, error: 'config holds comments — edit it by hand to keep them' };
   }
   let cfg;
-  if (['claude', 'bob', 'copilot', 'openclaude'].includes(host)) {
+  if (['claude', 'bob', 'openclaude'].includes(host)) {
     if (isFile(p)) {
       let parsed;
       try {
@@ -816,7 +816,6 @@ const EMIT_FOR = new Map([
   ['opencode global', 'opencode-global'], ['opencode project', 'opencode'],
   ['claude global', 'claude-global'], ['claude project', 'claude'],
   ['bob global', 'bob-global'], ['bob project', 'bob'],
-  ['copilot global', 'copilot-global'], ['copilot project', 'copilot'],
   ['openclaude global', 'openclaude-global'], ['openclaude project', 'openclaude'],
 ]);
 
@@ -952,7 +951,7 @@ export function apiDeployCmd(state, body) {
     return { error: `folder not writable: ${root}` };
   }
   const cfgdirs = new Set();
-  for (const fn of [opencodeConfigDir, claudeConfigDir, bobConfigDir, copilotConfigDir,
+  for (const fn of [opencodeConfigDir, claudeConfigDir, bobConfigDir,
     openclaudeConfigDir]) {
     try {
       cfgdirs.add(resolvePath(fn()));
@@ -978,7 +977,7 @@ export function apiDeployCmd(state, body) {
   // and `PreToolUse::Bash` went with them. `doctrinesForBuild` resolves unknown to ALL packs.
   const doctrines = bodyDoctrines(body) ?? doctrinesForBuild(root);
   const excludeRules = bodyExcludeRules(body) ?? excludedRulesOfDir(root);
-  // project-scope emit name == host name (opencode / claude / bob / copilot / openclaude)
+  // project-scope emit name == host name (opencode / claude / bob / openclaude)
   const argv = setupBuildArgs(theme || 'neutral', host, root, root, fp, pos, mode, doctrines,
     PACK_ORDER, excludeRules);
   return { cmd: [process.execPath, path.join(ROOT, 'bin', 'build-driver.mjs'), ...argv] };

package/js/web/api.mjs

@@ -141,8 +141,8 @@ export function webState(theme = null, target = null) {
    * Re-point the console at another detected install's data dir.
    *
    * `root` is the install ROOT the markers and sigils live at. It defaults to `target` and
-   * differs only for claude/bob/copilot PROJECT installs, where the data sits under
-   * `<repo>/.claude|.bob|.github` while `.geneseed-emit`/`-theme`/`-footprint` land at
+   * differs only for claude/bob/openclaude PROJECT installs, where the data sits under
+   * `<repo>/.claude|.bob|.openclaude` while `.geneseed-emit`/`-theme`/`-footprint` land at
    * `<repo>/` — reading them from the data dir mis-detects the install as opencode/neutral,
    * and a Diff or a Restore would then overwrite it in the wrong dialect.
    */
@@ -725,7 +725,7 @@ export const apiExcludes = () => excludesSnapshot();
  * nested-marker host cannot silently read the bare root.
  */
 export function viewCfg(host, scope, root) {
-  if (scope === 'project' && ['claude', 'bob', 'copilot', 'openclaude'].includes(host)) {
+  if (scope === 'project' && ['claude', 'bob', 'openclaude'].includes(host)) {
     return path.join(root, HOSTS.find((h) => h.host === host).projectMarker);
   }
   return root;
@@ -795,7 +795,7 @@ export function apiOverview(state) {
   // can re-emit exactly it. Mirrors `viewCfg`'s rule, spelled out separately here.
   let install = null;
   for (const [host, scope, root] of installTargets()) {
-    const data = (scope === 'project' && ['claude', 'bob', 'copilot', 'openclaude'].includes(host))
+    const data = (scope === 'project' && ['claude', 'bob', 'openclaude'].includes(host))
       ? path.join(root, HOSTS.find((h) => h.host === host).projectMarker) : root;
     try {
       if (samePath(data, state.target)) {

package/package.json

@@ -1,14 +1,13 @@
 {
   "//": "Every field here is argued and gated in tests/unit/package_manifest.test.mjs. `files`, `bin` and `engines` each have a test that fails when reality drifts from this file; `version` mirrors harness.config.json and is gated too. Read that docblock before editing this one.",
   "name": "geneseed",
-  "version": "3.9.0",
+  "version": "3.10.0",
   "description": "A portable, theme-able harness you implant once and use everywhere to grow a disciplined AI coding agent.",
   "keywords": [
     "ai",
     "agent",
     "claude-code",
     "opencode",
-    "copilot",
     "openclaude",
     "agents-md",
     "skills",

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,9 +87,12 @@ 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}}
 
 ---
@@ -91,8 +103,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 +114,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 +128,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 +186,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 +202,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 -->
 
 ---
 
@@ -246,19 +270,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 +283,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 +305,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 +321,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 +349,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 +360,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 +410,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 +437,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 +453,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 +465,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 +479,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/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/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/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.

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

@@ -5,7 +5,7 @@ not third-party. It rides the vendored-folder mechanism because it bundles an
 executable (`scripts/token_report.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 — which is exactly what a multi-file skill needs.
+IBM Bob, OpenCode, OpenClaude — which is exactly what a multi-file skill needs.
 
 - **Upstream:** this repository (first-party)
 - **License:** same as Geneseed (see repository LICENSE)
@@ -17,7 +17,6 @@ Consequences of riding this mechanism (deliberate):
   `description` and blockquote purpose line instead;
 - listed in AGENT.md's folder-skills section, not the main skills table.
 
-The script supports all five emitted hosts (exact usage on Claude Code, Bob,
-OpenClaude and OpenCode; best-effort on Copilot, whose session-state schema is undocumented).
+The script supports all four emitted hosts, with exact usage on each.
 If a host changes its session storage layout, fix the corresponding finder or
 parser in `scripts/token_report.mjs`.