geneseed 2.0.0

package/src/postures/assistant.md

@@ -0,0 +1,12 @@
+**Assistant** — the agent executes your intent precisely and keeps its own initiative
+low. You are steering.
+
+- **Register.** Plain, service-minded, unobtrusive. Reports what it did and what it
+  found, without editorialising.
+- **Initiative.** Does what is asked and stops. Confirms before deviating from the
+  literal request or widening scope; prefers a question over a guess.
+- **Disagreement.** Still flags a real risk or a factual error — {{LAW}} XXX holds in
+  every posture — but raises it as a note for your call, not a debate.
+- **What it will not do.** Take large or irreversible steps unprompted, or reshape
+  your approach because it prefers another. When you want a collaborator that pushes
+  back harder, switch to Peer.

package/src/postures/expert.md

@@ -0,0 +1,11 @@
+**Expert** — maximum signal density for someone already fluent in the domain.
+
+- **Register.** Terse and technical. Uses the field's vocabulary without unpacking it;
+  assumes the background and gets to the point.
+- **Initiative.** Moves fast on the implied task, states conclusions first, and leaves
+  the derivation available but not front-loaded.
+- **Disagreement.** Blunt and immediate — a flaw is named as a flaw, no cushioning
+  ({{LAW}} XXX).
+- **What it will not do.** Explain the basics, define common terms, or pad with
+  context you already hold. If an answer starts to feel over-explained, it has drifted
+  — pull it back to Expert.

package/src/postures/mentor.md

@@ -0,0 +1,11 @@
+**Mentor** — the agent works to leave you more capable than it found you, not just
+to finish the task.
+
+- **Register.** Patient and explanatory. Names the reasoning, the trade-offs, and
+  the concept behind the move, so the *why* travels with the *what*.
+- **Initiative.** Checks understanding before moving on; pauses at the teachable
+  moment rather than racing to the answer.
+- **Disagreement.** Corrects, but shows its working so you can judge the correction
+  for yourself ({{LAW}} XXX) — 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.

package/src/postures/peer.md

@@ -0,0 +1,12 @@
+**Peer** — the default. The agent works alongside you as a candid equal, not a
+deferential assistant.
+
+- **Register.** Direct, dense, collegial. Assumes competence; skips the hand-holding
+  and the flattery alike.
+- **Initiative.** Acts on what the request implies without asking permission for
+  every reversible step; surfaces genuine forks rather than guessing ({{LAW}} XXXI).
+- **Disagreement.** Says so plainly and early when you are wrong, with the evidence,
+  and does not fold the moment you push back ({{LAW}} XXX). Honouring this is the
+  {{PACT}} working, not defiance.
+- **What it will not do.** Pad answers, stage false agreement, or narrate reassurance.
+  Brevity and candour over comfort.

package/src/skills/_template.md

@@ -0,0 +1,47 @@
+<!--
+  Authoring a new skill (this scaffold replaces the old create-skill skill):
+  1. Reuse first — if an existing skill's domain already covers the need, extend it
+     instead of adding a file (universal Law V). Name the skill by its domain.
+  2. Copy this file to skills/<name>.md and fill in the purpose line, trigger,
+     procedure, and done-when. In an installed harness the purpose line is plain
+     prose; in the Geneseed source repo it is the DESC_<NAME> token with the prose
+     defined per theme.
+  3. Add a row for it to the skills table in AGENT.md (the table is hand-authored;
+     the skill files themselves auto-render). doctor fails if the table and the skill
+     files disagree, so neither can silently drift.
+  Geneseed source repo only (skip in an installed harness):
+  4. Define the DESC_<NAME> token (hyphens -> underscores, uppercased) in ALL theme
+     JSONs under themes/ — the parity gate fails if any theme is missing it.
+  5. Bump the `skills-N` count badge in README.md (doctor checks it against the real
+     file count; the test counts derive from src/ and need no edit), then run
+     `./geneseed doctor --all` and the repository's test suites.
+-->
+# {{SKILL}}: <name>
+
+> One-line statement of the recurring task this {{SKILL}} automates.
+
+**Trigger:** the situation or phrase that should make the agent run this {{SKILL}}.
+
+**Requires:** *(optional line — include only for hard prerequisites: an env var, an
+external binary, or a host capability the {{SKILL}} cannot run without. A {{SKILL}}
+that merely uses standard repo tooling — git, the test runner — omits this line.)*
+
+## Procedure
+1. Ordered, concrete steps. Each step is an action the agent takes.
+2. Note any verification step (run the command, read the output).
+
+## Done when
+- The observable condition that means the {{SKILL}} succeeded.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/brainstorm.md

@@ -0,0 +1,28 @@
+# {{SKILL}}: brainstorm
+
+> {{DESC_BRAINSTORM}}
+
+**Trigger:** a new feature or behaviour change with no design yet, or the user says "brainstorm" / "let's design this". (If the goal or scope itself is still unclear — especially for non-design work — run the [clarify {{SKILL}}](clarify.md) first.)
+
+## Procedure
+1. Read the current project state and its own docs ({{LAW}} XVII) so questions are grounded; if the request bundles several systems, decompose and take one at a time.
+2. Ask clarifying questions ONE at a time (multiple-choice when you can) until purpose, constraints, and success criteria are clear.
+3. Propose 2-3 approaches with trade-offs; lead with your recommendation.
+4. Present the design in sections (purpose → components → data flow → failure modes → testing), getting an explicit "looks right" after each; cut anything YAGNI.
+5. Write the agreed design to a spec the next session can find — `SPEC.md` beside the work, or the project's own spec home (e.g. `docs/specs/`) — re-read it for ambiguity, then hand off to the [plan {{SKILL}}](plan.md) to sequence it — writing no implementation code before that approval.
+
+## Done when
+- An approved, ambiguity-free design exists and `plan` has it to sequence, with no code written beforehand.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/clarify.md

@@ -0,0 +1,28 @@
+# {{SKILL}}: clarify
+
+> {{DESC_CLARIFY}}
+
+**Trigger:** a task or whole project arrives with its goal, scope, or success criteria unstated or ambiguous — including non-design work (a refactor, migration, ops chore, investigation) — or the user says "interview me" / "what am I actually trying to do" / "clarify this first". If a concrete design problem is already identified, use the [brainstorm {{SKILL}}](brainstorm.md) instead.
+
+## Procedure
+1. Read the current project state and its own docs ({{LAW}} XVII) so questions are grounded ({{LAW}} III — verify the actual state before designing the interview). If the request bundles several goals, separate them and take one at a time.
+2. Interpret the request in its strongest, most reasonable form first (the principle of charity) — do not manufacture ambiguity from a fair reading. If the goal, scope, and success criteria are already unambiguous, restate them in one line and skip to step 4 — no ceremony on a clear ask. Otherwise interview the user ONE question at a time (multiple-choice when you can), driving at *why* (the outcome wanted), *scope* (what is explicitly in and out), and *done* (how success is judged) — not *how* yet. Keep asking until each is unambiguous.
+3. Name every KEY DECISION the answers imply or leave open — chosen direction, trade-offs accepted, load-bearing constraints, assumptions, and non-goals. Surface each silent assumption as a decision to ratify, not a settled fact.
+4. Write the goal and the key-decision ledger to `BRIEF.md` (or `clarify/<task>.md`), then read it back to the user as a numbered list and get an EXPLICIT confirmation before acting ({{LAW}} III — an inferred intent is not ground truth until echoed back and agreed) — so nothing material is silently assumed. Scope the read-back to decisions that are consequential, irreversible, or genuinely uncertain; correct the file and re-confirm any the user changes.
+5. Route the confirmed brief to the right next {{SKILL}} — [brainstorm {{SKILL}}](brainstorm.md) for a design problem, [plan {{SKILL}}](plan.md) for a multi-step build, [debug {{SKILL}}](debug.md) for a defect — handing it the brief and writing no implementation code first.
+
+## Done when
+- A confirmed, ambiguity-free goal with an explicitly verified key-decision ledger is written to `BRIEF.md`, and the work has been handed to the appropriate downstream {{SKILL}}.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/codebase-design.md

@@ -0,0 +1,44 @@
+# {{SKILL}}: codebase-design
+
+> {{DESC_CODEBASE_DESIGN}}
+
+**Trigger:** designing or reshaping a module's interface, deciding where a seam
+goes, making code more testable through its interface — or another {{SKILL}}
+needs the deep-module vocabulary.
+
+## Procedure
+1. Use this vocabulary exactly — **module** (anything with an interface and an
+   implementation, at any scale), **interface** (everything a caller must know:
+   the types plus invariants, ordering constraints, error modes, performance),
+   **depth** (behaviour a caller gets per unit of interface they must learn),
+   **seam** (a place where behaviour can be altered without editing in place),
+   **adapter** (a concrete thing filling a seam). Avoid "component", "service",
+   "API", "boundary" — consistent language is the point.
+2. Aim for **deep modules**: a lot of behaviour behind a small interface. Depth
+   buys callers leverage (one implementation pays back across N call sites) and
+   maintainers locality (change, bugs, and knowledge concentrate in one place).
+3. Place seams deliberately and sparingly — the interface is the test surface,
+   and the fewer seams the better. One adapter at a seam is a hypothesis; a
+   second adapter is what makes the seam real.
+4. Apply the **deletion test** to anything suspected shallow (interface nearly
+   as complex as its implementation): would deleting it concentrate complexity
+   somewhere sensible, or just move it around? "Concentrates" → fold it in.
+5. Record any structural decision this produces as the
+   [domain-modeling {{SKILL}}](domain-modeling.md) prescribes.
+
+## Done when
+- The design is stated in this vocabulary, the seams are explicit and agreed,
+  and each module is deeper than the alternative you rejected.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/commit.md

@@ -0,0 +1,48 @@
+# {{SKILL}}: commit
+
+> {{DESC_COMMIT}}
+
+**Trigger:** about to commit changes.
+
+## Procedure
+1. Review the working tree; identify the paths that belong to *this* change only.
+2. Stage exactly those paths — never `git add -A` blindly (universal {{LAW}} II:
+   one intent, one act). Leave unrelated dirty files out.
+3. Confirm no secret is being committed (universal {{LAW}} I), and no leftover
+   debug scaffolding rides along — `console.log`, `debugger`, `print`,
+   commented-out code, or hardcoded test values left over from diagnosis
+   ({{LAW}} XXIV).
+4. Write a message: imperative subject ≤50 chars; a body only when the *why*
+   isn't obvious from the diff. **Match the repository's existing commit convention**
+   (universal {{LAW}} XIII) — detect it from commit tooling (`commitlint`,
+   `semantic-release`, `release-please`, husky hooks) and recent `git log`. When the
+   repo has no discernible convention, default to **Conventional Commits**:
+   `type(scope): subject` (`feat`, `fix`, `docs`, `refactor`, `test`, `chore`…),
+   with a `!` before the colon or a `BREAKING CHANGE:` footer for a breaking change.
+5. **Get explicit consent before committing (universal {{LAW}} XX).** On *every*
+   branch — feature branches included — first show the user a plain-language summary of
+   the change *and* the exact commit message, then wait for explicit acceptance before
+   committing. A previous approval is not standing consent; ask again each commit. On a
+   *shared branch* (`main`, `master`, `develop`/`development`, a release/hotfix branch,
+   or any branch that is not a dedicated feature branch) apply the same gate with extra
+   care.
+6. Push only when the user has explicitly approved *that push* ({{LAW}} XX / {{LAW}} IV)
+   — never push on your own initiative, on any branch, and never treat one approval as
+   consent for the next.
+
+## Done when
+- The commit contains only the intended change and the working tree is clean of it,
+  and every commit and push went out only with the user's explicit, per-action consent.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/council.md

@@ -0,0 +1,34 @@
+# {{SKILL}}: council
+
+> {{DESC_COUNCIL}}
+
+**Trigger:** the user asks to "convene a council", "debate this", "argue both sides", "stress-test this decision", or wants a change, plan, or claim challenged from several points of view before committing to it.
+
+## Procedure
+1. Frame the motion in one line — the exact decision, change, or claim under debate — and name what it feeds (a choice to make, a design to accept, a discussion to settle). Ground it in the real artifact and the project's own docs ({{LAW}} XVII–XVIII) so the council argues the actual thing; if the motion is unclear or bundles several questions, split it and ask once, then proceed.
+2. Seat the council from the standing roster of read-only debate {{AGENTS}}, each arguing one fixed stance — convene the subset that genuinely clashes on *this* motion (usually 3–6, never the whole bench for its own sake), always anchored by the for/against spine of [advocate](../{{DIR_AGENTS}}/advocate.md) and [skeptic](../{{DIR_AGENTS}}/skeptic.md):
+   - [advocate](../{{DIR_AGENTS}}/advocate.md) — the strongest case **for**; [skeptic](../{{DIR_AGENTS}}/skeptic.md) — devil's advocate, failure modes and hidden assumptions.
+   - [pragmatist](../{{DIR_AGENTS}}/pragmatist.md) — cost, effort, YAGNI; [steward](../{{DIR_AGENTS}}/steward.md) — long-term architecture and debt; [operator](../{{DIR_AGENTS}}/operator.md) — running it in production.
+   - [visionary](../{{DIR_AGENTS}}/visionary.md) — the bold, transformative version; [framer](../{{DIR_AGENTS}}/framer.md) — whether it's even the right problem; [empiricist](../{{DIR_AGENTS}}/empiricist.md) — every claim held to evidence; [historian](../{{DIR_AGENTS}}/historian.md) — what was tried before.
+   - [user-advocate](../{{DIR_AGENTS}}/user-advocate.md) — whoever consumes the outcome.
+
+   Hand each chosen seat the motion and a one-line charter scoped to this topic; skip the seats with nothing to say here, and add an ad-hoc seat (e.g. the [security](../{{DIR_AGENTS}}/security.md) surface) only when the topic plainly demands a voice the roster doesn't cover.
+3. Round one — positions: convene the seats by dispatching each stance {{AGENT}} as its own subagent in one batch where the tool supports it (the [parallel-agents {{SKILL}}](parallel-agents.md)), so each argues in an isolated context with no groupthink; where no subagent capability exists, voice each seat in turn as a persona. Each returns its steelmanned brief ({{LAW}} VIII) — no hedging, no strawmen.
+4. Round two — clash: put the briefs in front of each other and have the seats rebut only on the points that actually conflict, surfacing the cruxes, the load-bearing assumptions, and where the evidence is thin. Hold to a fixed number of rounds so the debate converges instead of looping; the skeptic already pairs every objection with what would resolve it (the [roast-me {{SKILL}}](roast-me.md) discipline).
+5. The chair synthesises in neutral voice: state the verdict and its reasoning, record the strongest surviving dissent verbatim so it is not lost, list what would change the verdict, and name the single next action. Surface it for the user to decide — the council advises, it does not commit: write no code and push nothing on its own ({{LAW}} IV, {{LAW}} XX).
+
+## Done when
+- A crisp motion was debated by distinct, steelmanned seats over bounded rounds, and the chair has delivered a verdict, the preserved dissent, and one next action for the user to weigh.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/crash-course.md

@@ -0,0 +1,28 @@
+# {{SKILL}}: crash-course
+
+> {{DESC_CRASH_COURSE}}
+
+**Trigger:** the user wants to go from zero to *functional* in a skill fast — "teach me X", "get me up to speed on X", "I have limited time to learn X". For practising a concept until it's reflex use [drill](drill.md); for making confusing material click use [decode](decode.md); for gathering facts from the web use [research](research.md).
+
+## Procedure
+1. Pin the skill and the footing: what they want to be able to *do* afterwards, how much time they have, and what they already know. If unclear, ask once, then proceed.
+2. Act as a teacher who has only this one session and will never see them again; the sole objective is to make them functional before time runs out. Do not give theory without immediate practical use, and do not hand over a bare list.
+3. Name three things explicitly: **what to learn first**, **what to ignore completely** (for now), and **the single exercise that, done once, puts them ahead of most people who have studied this for months**.
+4. Have them do that exercise — or set it up so they can — rather than just reading about it.
+5. Close by naming what to practise next and the gap most likely to trip them, so the learning continues without you.
+
+## Done when
+- The user knows what to learn first, what to skip, and has the one high-leverage exercise in hand — functional, not just informed.
+
+## Self-improvement
+
+Close each run with one beat of reflection on the {{SKILL}} itself:
+- A step misled, a needed step was missing, or the trigger fired wrongly — that
+  is a flaw in this file. Propose the exact edit (trigger, procedure, or
+  done-when) and apply it with the user's assent ({{LAW}} II).
+- A lesson that is *not* a flaw in this file goes to {{MEMORY}} only if it
+  clears {{LAW}} VI's bar: it would change how a future session behaves, and a
+  fresh read of the repo would not re-derive it. Update an existing memory over
+  adding one; when in doubt, leave it out.
+- No friction, nothing learned — move on; this loop earns no ceremony. Most
+  runs end here.

package/src/skills/daydream/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "daydream",
+  "description": "daydream",
+  "author": {
+    "name": "Gleb Kalinin"
+  },
+  "repository": "https://github.com/glebis/claude-skills",
+  "license": "MIT"
+}

package/src/skills/daydream/SKILL.md

@@ -0,0 +1,74 @@
+# 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.
+
+Inspired by [Gwern's LLM Daydreaming](https://gwern.net/ai-daydreaming).
+
+## Usage
+
+```
+/daydream
+```
+
+## Setup (Geneseed)
+
+Before the first run, make sure the pieces this skill depends on are in place:
+
+1. **A vault to mine.** Declare your Obsidian vault in the harness `wiki.jsonc`
+   (AGENT.md §7) — give a `wikis[]` entry a `path` to the vault root. Without it the
+   skill falls back to detecting a `.obsidian/` folder in the current directory, then
+   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
+   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.
+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 —
+   keep them unprotected (Law-I-safe, since they're generated notes, not secrets).
+
+This skill adds **no dependencies of its own** — it uses only the host's built-in
+Glob/Read/Write/Bash and subagent tools. See [VENDOR.md](VENDOR.md) for provenance.
+
+## What it does
+
+1. Resolves vault root from the harness `wiki.jsonc` manifest (a declared vault's `path`); falls back to auto-detecting `.obsidian/` from the current directory, then asks if still unfound
+2. Scans vault for notes modified in last 120 days
+2. Generates 50 recency-weighted random pairs
+3. Synthesizes connections (Sonnet, parallel batches of 5)
+4. Critiques and scores insights (Haiku, parallel batches)
+5. Filters for quality (average score >= 7.0)
+6. Saves insight notes to `Daydreams/` folder
+7. Generates daily digest in `Daydreams/digests/`
+8. Appends summary to today's daily note
+
+## Output
+
+- **Individual insights**: `Daydreams/YYYYMMDD-slug.md` -- full synthesis with scores and wikilinks
+- **Daily digest**: `Daydreams/digests/YYYYMMDD-digest.md` -- stats + ranked top insights
+- **Daily note**: Summary appended under `## Daydream`
+- **History log**: `ai-research/daydream/history.json` -- tracks sampled pairs for dedup
+
+## Architecture
+
+```
+Skill (orchestrator)
+  |-- Glob/Read: scan vault, extract excerpts
+  |-- Generate 50 random pairs (recency-weighted)
+  |-- Task(model: sonnet) x 10: synthesize connections  <-- parallel
+  |-- Task(model: haiku) x 10: critique/score insights  <-- parallel
+  |-- Filter (avg >= 7.0)
+  +-- Write: save insight notes + daily digest
+```
+
+No external dependencies -- pure Claude Code tools (Glob, Read, Write, Bash, Task).
+
+## Cost
+
+Per run (~50 pairs): approximately $0.40-0.50 via Claude Code usage.

package/src/skills/daydream/VENDOR.md

@@ -0,0 +1,25 @@
+# Vendored skill — daydream
+
+This folder is a third-party skill vendored 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`.
+
+- **Upstream:** https://github.com/glebis/claude-skills/tree/main/daydream
+- **Commit:** f47170dee300dd3d5da2a1c3c708986faeea3d5a
+- **Author:** Gleb Kalinin
+- **License:** MIT (declared in `.claude-plugin/plugin.json`)
+- **Inspired by:** Gwern's [LLM Daydreaming](https://gwern.net/ai-daydreaming)
+
+## Geneseed adaptation
+
+Vault resolution is adapted to read the harness's `wiki.jsonc` knowledge-base
+manifest first (a declared vault's `path`), falling back to the upstream cwd/`.obsidian`
+auto-detection when no wiki is declared. The synthesis/critique still run as parallel
+subagents over recency-weighted note pairs. The model-name references (`sonnet`,
+`haiku`) and the `.claude/skills/daydream/…` prompt paths are upstream's; on a
+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.

package/src/skills/daydream/critic-prompt.md

@@ -0,0 +1,38 @@
+# Critic Prompt
+
+Used by Task sub-agents (model: haiku) to score and filter synthesized insights.
+
+---
+
+You are a discerning critic evaluating a synthesized insight
+from an Obsidian knowledge vault.
+
+Rate the following on a scale of 1-10:
+
+- **Novelty**: Is this surprising and non-obvious? (1=obvious, 10=paradigm-shifting)
+- **Coherence**: Is the reasoning logical? (1=nonsense, 10=rigorous)
+- **Usefulness**: Could this lead to action? (1=useless, 10=highly actionable)
+
+Source notes: "{title_a}" and "{title_b}"
+
+Connection: {connection}
+
+Synthesis:
+{synthesis}
+
+Implication:
+{implication}
+
+Respond with ONLY a JSON object (no markdown fences):
+{
+  "novelty": <1-10>,
+  "coherence": <1-10>,
+  "usefulness": <1-10>,
+  "average": <float rounded to 1 decimal>,
+  "verdict": "accept" or "reject",
+  "reason": "<1-sentence justification>"
+}
+
+Accept if average >= 7.0. Be genuinely critical -- most random
+combinations should be rejected. Only accept insights that would
+genuinely surprise and inform the note author.