geneseed 4.0.0 → 4.2.0

package/src/skills/brainstorm.md

@@ -15,12 +15,15 @@ the design is skipped.
    several goals or systems, separate them and take one at a time.
 2. **Interpret charitably, then interview.** Read the request in its strongest
    reasonable form — do not manufacture ambiguity from a fair ask. If goal, scope and
-   success criteria are already unambiguous, restate them in one line and go to step
-   4. Otherwise ask ONE numbered round of every question answerable now, each with your
-   recommended answer so "yes" accepts it; dependent questions wait a round. Drive at
-   *why* (the outcome wanted), *scope* (in and out) and *done* (how success is judged) —
-   not *how* yet. Stop when each is unambiguous. Facts are yours to find (read the code,
-   dispatch a subagent), never the user's. A decision someone else owns gets a drafted
+   success criteria are already unambiguous, restate them in one line (naming any
+   platform or language choice) and go to step 4. Otherwise ask ONE numbered round of
+   every question answerable now, each with your recommended answer so "yes" accepts it;
+   dependent questions wait a round. Drive at *why* (the outcome wanted), *scope* (in and
+   out), *done* (how success is judged) and which build choices (platform, language, key
+   libraries) the user wants to own. Existing work decides by default
+   ({{DOCTRINE:respect-conventions}}); a choice you take goes in the ledger as **your
+   call**, never as agreed. Stop when each is unambiguous. Facts are yours to find (read
+   the code, dispatch a subagent), never the user's. A decision someone else owns gets a drafted
    `questionnaire-<slug>.md` for them — ask the user only who and what they need back.
 3. **Ledger the decisions.** Name every KEY DECISION the answers imply or leave open —
    direction chosen, trade-offs accepted, load-bearing constraints, assumptions,
@@ -28,15 +31,18 @@ the design is skipped.
    fact. Read the ledger back as a numbered list and get an EXPLICIT confirmation
    ({{LAW:echo-the-intent}} — an inferred intent is not ground truth until echoed and agreed);
    scope the read-back to what is consequential, irreversible or genuinely uncertain.
-4. **Design — only when there is something to design.** Propose 2–3 approaches with
+4. **Size it, then design.** Say the size; the user may override. *Quick* — exit and do
+   it, no spec. *Small* — the confirmed ledger in chat is the spec; go to step 6.
+   *Project* — design, spec file, builder check. If it grows mid-work, stop and step up.
+   Design only when there is something to design: propose 2–3 approaches with
    trade-offs, leading with your recommendation. Present the chosen design in
    sections (purpose → components → data flow → failure modes → testing), getting an
    explicit "looks right" after each; cut anything YAGNI. For a non-design ask, skip
    this step.
 5. **Write the spec.** One file the next session can find — `SPEC.md` beside the work,
    or the project's own spec home (e.g. `docs/specs/`): the goal in one line, the
-   confirmed decision ledger, then the design (when there is one). Re-read it cold for
-   ambiguity and fix what a stranger could misread.
+   confirmed decision ledger, then the design (when there is one). Then run the builder
+   check: read [brainstorm/builder-check.md](brainstorm/builder-check.md) and follow it.
 6. **Exit — route, don't build.** Hand the spec to the {{SKILL}} the work now needs:
    [plan](plan.md) for a multi-step build whose route is known (sliced if too big for a
    session), [wayfinder](wayfinder.md) only when the route itself is still in the fog,
@@ -44,7 +50,9 @@ the design is skipped.
 
 ## Done when
 - A confirmed, ambiguity-free goal with its ratified decision ledger — and, where
-  the ask was a design, an approved design — sits in one spec file, and the work has
-  been handed to the next {{SKILL}} with no code written beforehand.
+  the ask was a design, an approved design that passed the builder check — sits in one
+  spec file (or, for a small change, in the confirmed chat ledger), and the work has
+  been handed to the next {{SKILL}} with no code written beforehand — or, sized quick,
+  the brainstorm was exited to do the work.
 
 <!-- INCLUDE: skills/_self-improvement.md -->

package/src/skills/daydream/SKILL.md

@@ -79,4 +79,4 @@ No external dependencies -- pure Claude Code tools (Glob, Read, Write, Bash, Tas
 
 ## Cost
 
-Per run (~50 pairs): approximately $0.40-0.50 via Claude Code usage.
+Per run (~50 pairs): approximately 0.40-0.50 USD via Claude Code usage.

package/src/skills/daydream/VENDOR.md

@@ -37,3 +37,7 @@ bump the commit above.
 `SKILL.md`'s frontmatter also carries `disable-model-invocation: true`, which upstream lacks: the
 skill is user-only (`/daydream`), so its description stays out of the model's always-on catalogue —
 it is personal to one vault. Re-apply it on update.
+
+The cost line in `SKILL.md` reads "0.40-0.50 USD" where upstream writes a dollar sign before the
+number: Claude Code substitutes a dollar sign followed by a digit with the skill's arguments, so
+upstream's text renders mangled. Re-apply it on update.

package/src/skills/debug/ci.md

@@ -1,10 +1,10 @@
 # {{SKILL}}: debug — CI branch, a red run
 
 Needs the CI log: the host's CI tool, `gh run view --log-failed` or equivalent, or the log pasted by the user.
-1. **Read the log, not the badge.** Find the first failing job and its first failing step. Read the error and the command that produced it in full ({{LAW:verify-before-asserting}}); note the runner's OS, toolchain versions and exact invocation.
-2. **Classify before touching anything:** a *real failure* (code or test wrong), an *environment difference* (a version, path, line endings, missing binary, a test skipped locally but not in CI), an *infra flake* (network, runner, cache, timeout), or a *gate on the report itself* (a coverage or count threshold, a lint the local hook skips).
-3. **Reproduce under CI's own conditions** — the workflow's script, flags and a matching toolchain. Green locally and red in CI has not reproduced yet: close the gap (the env var, `--frozen-lockfile`, the reporter, the binary not on PATH) until it fails the same way. Never retry a run blindly.
-4. **Fix at the cause** through steps 2–6 of the debug procedure. For an environment difference, make the *repo* deterministic (pin, normalise, declare) rather than CI more permissive. A flake is fixed at its source — the race, the timeout, the unpinned resource — or quarantined *with an issue and an owner*, never silently skipped ({{LAW:cure-the-cause}}). A fix to CI config itself is its own commit ({{LAW:one-intent-one-act}}), noted in the PR.
+1. **Read the log, not the badge.** Measure a log before reading it and grep a large one rather than loading it whole ({{DOCTRINE:context-economy}}). Find the first failing job and its first failing step. Read the error and the command that produced it in full ({{LAW:verify-before-asserting}}); note the runner's OS, toolchain versions and exact invocation.
+2. **Classify before touching anything.** First diff against the last green run: commit range, lockfile, runner image, toolchain. Then name the class: a *real failure* (code or test wrong), an *environment difference* (a version, path, line endings, missing binary, a test skipped locally but not in CI), an *infra flake* (network, runner, cache, timeout), or a *gate on the report itself* (a coverage or count threshold, a lint the local hook skips).
+3. **Reproduce under CI's own conditions** — the workflow's script, flags and a matching toolchain. Green locally and red in CI has not reproduced yet: close the gap (the env var, `--frozen-lockfile`, the reporter, the binary not on PATH) until it fails the same way. Never retry a run blindly. CI logs are shared: probe a secret's presence, never its value (`[ -n "$TOKEN" ] && echo set || echo unset`).
+4. **Fix at the cause** through steps 2–6 of the debug procedure. For an environment difference, make the *repo* deterministic (pin, normalise, declare) rather than CI more permissive. A flake is fixed at its source — the race, the timeout, the unpinned resource — or quarantined *with an issue and an owner*, never silently skipped ({{LAW:cure-the-cause}}). A sleep that guesses at timing becomes a wait on the actual condition with a bounded timeout; a fixed delay that remains says why ({{DOCTRINE:honest-tests}}). A fix to CI config itself is its own commit ({{LAW:one-intent-one-act}}), noted in the PR.
 5. **Prove it the way CI will:** run CI's command locally once more and read the output, push with the user's per-push consent ({{DOCTRINE:consent-before-push}}), and watch the re-run to green; the gate that reported it verifies the fix. Report what failed, its class, what changed, and the green run.
 
 ## Done when

package/src/skills/debug.md

@@ -13,13 +13,13 @@ faster than thrashing; do not trade it away under pressure.
 
 ## Procedure
 1. **Build one command that goes red on *this* bug** before reading code for a theory. It asserts the user's exact symptom (not "didn't crash"), gives the same verdict every run, takes seconds and runs unattended; run it and show the output. Read the error and stack trace in full. For a flaky bug, raise the reproduction rate until it is debuggable. If you cannot build it, say so, list what you tried and ask for access or a captured artifact — no command, no hypothesis. Read `GLOSSARY.md` (or `CONTEXT.md`) and the ADRs in the area for the domain's vocabulary.
-2. **Minimise, then isolate.** Cut inputs and steps one at a time until every remaining element is load-bearing. Then binary-search the cause — the code path, or for a regression the commit range with `git bisect` (the [git-history {{SKILL}}](git-history.md) carries the method). Change one variable at a time. In a multi-layer system (CI → build → sign, API → service → DB), instrument each boundary once to see *which* layer breaks before investigating inside it. For a performance regression, take a baseline measurement and bisect; don't log.
-3. **Rank 3–5 falsifiable hypotheses** ("if X is the cause, changing Y removes the bug") — list them in your reply, then test the top one without waiting. Proceed only on one that explains ALL the evidence — else gather more evidence, don't guess.
+2. **Minimise, then isolate.** Cut inputs and steps one at a time until every remaining element is load-bearing. Then binary-search the cause — the code path, or for a regression the commit range with `git bisect` (the [git-history {{SKILL}}](git-history.md) carries the method). Change one variable at a time. Find the nearest working twin (a passing sibling test, the last green commit, the same call elsewhere) and list every difference, however small. For a bad value deep in the stack, trace it back caller by caller to where it was born, and fix there. In a multi-layer system (CI → build → sign, API → service → DB), instrument each boundary once to see *which* layer breaks before investigating inside it. For a performance regression, take a baseline measurement and bisect; don't log.
+3. **Rank 3–5 falsifiable hypotheses** ("if X is the cause, changing Y removes the bug") — list them in your reply, then test the top one without waiting. Cite the evidence for each as `file:line` or the exact log line. Proceed only on one that explains ALL the evidence — else gather more evidence, don't guess.
 4. Apply the smallest fix that addresses the root cause, not the symptom; resist fixing things the evidence doesn't implicate ({{LAW:one-intent-one-act}}). One change at a time — no bundled "while I'm here" edits.
 5. Verify: run the project's checks and read the actual output ({{LAW:verify-before-asserting}}) — the step-1 command now passes and nothing nearby broke. Where a test can pin the bug at a seam that reproduces the real call chain, add a regression test that fails before the fix and passes after. If no such seam exists, record that as a finding rather than writing a shallow test. Name the confirmed hypothesis in the commit message. Dispatch the [tester {{AGENT}}](../{{DIR_AGENTS}}/tester.md) for a focused regression check when the blast radius is unclear.
-6. If a fix doesn't work, return to step 1 with what you learned — don't stack a second fix on top. **After three failed fixes, stop fixing:** when each attempt only shifts the symptom elsewhere, the architecture, not the line, is likely wrong. Surface that to the user and decide the approach together before trying again ({{LAW:one-intent-one-act}}).
+6. If a fix doesn't work, return to step 1 with what you learned — don't stack a second fix on top. **After three failed fixes, stop fixing:** when each attempt only shifts the symptom elsewhere, the architecture, not the line, is likely wrong. Surface that to the user and decide the approach together before trying again ({{LAW:one-intent-one-act}}). If the evidence puts the cause outside the repo, show it; a retry or timeout is then a named workaround, taken with consent ({{LAW:cure-the-cause}}).
 
-**Diagnostic logging is scaffolding.** When you add logging to isolate a bug, use the project's real logger at a DEBUG level rather than scattered `print`/`console.log`, and **never log secrets, tokens, or PII** ({{LAW:sealed-secrets}}). Tag every probe with one unique prefix (`[DEBUG-a4f2]`) so cleanup is a single grep, and remove or downgrade each probe, `print`/`console.log`/`debugger` before the change ships ({{LAW:cure-the-cause}}).
+**Diagnostic logging is scaffolding.** When you add logging to isolate a bug, use the project's real logger at a DEBUG level rather than scattered `print`/`console.log`, and **never log secrets, tokens, or PII** ({{LAW:sealed-secrets}}) — probe a secret's presence, never its value: `[ -n "$TOKEN" ] && echo set || echo unset`. Tag every probe with one unique prefix (`[DEBUG-a4f2]`) so cleanup is a single grep, and remove or downgrade each probe, `print`/`console.log`/`debugger` before the change ships ({{LAW:cure-the-cause}}).
 
 **CI branch (a red run)** → read [debug/ci.md](debug/ci.md) and follow it.
 

package/src/skills/develop.md

@@ -38,15 +38,26 @@ case where the seam is only known once the change is made.
 6. With the slice green, tidy through the [refactor {{SKILL}}](refactor.md) — the tests
    are the safety net — then commit the slice through the [commit {{SKILL}}](commit.md)
    ({{DOCTRINE:consent-before-push}}). Loop from step 3, one slice at a time.
-7. **Exit.** When the last slice is in: run the whole affected suite once more, state
-   what was run and its result, and hand over — to the [ship {{SKILL}}](ship.md) when
+7. **Exit.** When the last slice is in: run the whole suite once, state what was run and
+   its result, and name every failure in it — including one this change did not cause
+   ({{DOCTRINE:cover-and-verify}}) — then hand over to the [ship {{SKILL}}](ship.md) when
    the change is ready for a PR, or to the [handoff {{SKILL}}](handoff.md) if the
    session ends mid-task. Leave no slice uncommitted and no test you could not make
    fail.
 
+## Anti-patterns — name the one you catch
+- **Implementation-coupled** — mocks an internal collaborator, tests a private method,
+  or checks through a side channel (querying the database instead of the interface).
+  The tell: it breaks on a refactor that changed no behaviour.
+- **Tautological** — the expected value is recomputed the way the code computes it, so
+  the test passes by construction and can never disagree with the code.
+- **Horizontal slicing** — all the tests first, then all the code: the tests pin an
+  imagined shape. One test, one implementation, repeat.
+
 ## Done when
 - Every behaviour changed is covered by a test written this session that was seen
-  to fail before it passed, the affected suite is green with its output shown, each
-  slice was committed on its own, and the work has been handed to ship or handoff.
+  to fail before it passed, the whole suite ran at exit with its output shown and every
+  failure named, each slice was committed on its own, and the work has been handed to
+  ship or handoff.
 
 <!-- INCLUDE: skills/_self-improvement.md -->

package/src/skills/fresh-eyes.md

@@ -9,7 +9,7 @@
 2. Deliberately WITHHOLD everything else and say so in the brief: the diff and changed-files list, the chat transcript, the solver's rationale and commit messages, prior test output, and every "it works because…" claim. Each is a vector for confirmation bias — they transmit the author's conviction, and a validator that inherits it cannot judge independently ({{ONTOLOGY}}: {{ONT_CONDUCT}}). The validator must re-confront the artifact cold, the way an external recipient would.
 3. Dispatch ONE fresh-context validator whose context starts empty — isolation is structural, not promised — using the [reviewer {{AGENT}}](../{{DIR_AGENTS}}/reviewer.md) (read-only, runs the suite, casts a verdict; NOT the [skeptic](../{{DIR_AGENTS}}/skeptic.md), whose charter forbids running commands and casting verdicts), via the dispatch pattern in [parallel-agents {{SKILL}}](parallel-agents.md), keeping the heavy reading out of the main context ({{DOCTRINE:context-economy}}); a cheaper model suffices for the validator unless the spec is subtle. Dispatch **fresh** — never resume a prior subagent session, which re-inherits its context and breaches the firewall. Where the host has no subagent capability, degrade: write the brief to a file and have the user run it in a separate fresh process; only as a last resort run the persona in-session and **stamp the verdict "SOFT ISOLATION — context bleed possible"** so the user discounts it. Never silently pretend a persona equals a fresh agent.
 4. Inside the fresh context, FIRST derive the rubric blind: from the task ALONE — before looking at the artifact — write a numbered list of observable acceptance criteria, each a yes/no test with a stated check method (a command to run, an output to see, a behaviour to exercise), tagged must-have or nice-to-have. FREEZE this list. Deriving it inside the firewall, from the task and not the solution, is what prevents criteria-fitting — the rubric cannot be bent to match what the artifact happens to do.
-5. THEN reveal the artifact and rule each criterion against it under an inverted burden of proof: actively check it — run the command, exercise the behaviour, read the named output ({{LAW:verify-before-asserting}} — verify by running, never assume) — and record `Cn: PASS | FAIL | UNVERIFIABLE — <evidence: the exact output/behaviour checked>`. Default is NOT-PASS: mark PASS only after actively confirming; a criterion that cannot be checked is UNVERIFIABLE (a finding, not a pass — name the missing evidence). Flag any **Extra** the artifact added beyond the spec, but cut gold-plating both ways — never FAIL the artifact for a requirement the task never asked for. The validator does NOT fix, refactor, or polish; it only rules.
+5. THEN reveal the artifact and rule each criterion against it under an inverted burden of proof: actively check it — run the command, exercise the behaviour, read the named output ({{LAW:verify-before-asserting}} — verify by running, never assume) — and record `Cn: PASS | FAIL | UNVERIFIABLE — <evidence: the exact output/behaviour checked>`. Default is NOT-PASS: mark PASS only after actively confirming; a criterion that cannot be checked is UNVERIFIABLE (a finding, not a pass — name the missing evidence). Flag any **Extra** the artifact added beyond the spec, but cut gold-plating both ways — never FAIL the artifact for a requirement the task never asked for (a reasonable user's expectation that it not crash or lose data is not gold-plating). The validator does NOT fix, refactor, or polish; it only rules.
 6. Return the independent verdict: the per-criterion table, then the overall gate — **SATISFIES** (every must-have PASS, no FAIL), **SATISFIES-WITH-GAPS** (must-haves pass, a nice-to-have fails), or **DOES-NOT-SATISFY** (any must-have FAIL or UNVERIFIABLE), listing the failing criteria with evidence. Report "could not find a fault" as not-proven-false, never as "proven correct". Surface it for the user to decide; the gate advises and applies no changes — write no code, push nothing ({{LAW:deletion-is-deliberate}}, {{DOCTRINE:consent-before-push}}). On DOES-NOT-SATISFY, hand the failures to the solver (optionally via [review-response](review-response.md)) and re-run fresh-eyes after the fix rather than letting the original context relitigate the ruling.
 
 ## Done when

package/src/skills/geneseed-code-review.md

@@ -6,7 +6,8 @@
 
 ## Procedure
 1. Pin the diff: `git diff <base>...HEAD` for committed work, `git diff <base>`
-   for uncommitted, or the PR the user names. Confirm the base resolves and the
+   for uncommitted, or the PR the user names. `<base>` is `origin/<default branch>` after a
+   `git fetch`, never a local branch that may be stale. Confirm the base resolves and the
    diff is non-empty.
 2. Find the spec: issue refs in the commits, a path the user gave, a match under
    `docs/`, `specs/` or `.scratch/`. None → ask once; still none → skip pass 3 and say so.
@@ -15,13 +16,19 @@
    output format included, but never a {{LAW}}.
 4. For a large change, consider dispatching the
    [reviewer {{AGENT}}](../{{DIR_AGENTS}}/reviewer.md) to keep the main context clean.
+   When a spec exists and the diff spans more than a few files, run pass 3 in its own
+   subagent, handed only the diff command and the spec, alongside passes 1–2: a pass
+   that has already filled up on code findings stops reading the spec closely, and
+   kept apart, one axis's findings never mask the other's.
 5. Pass 1 — correctness: logic errors, edge cases, error handling, race
    conditions. Verify suspect behaviour by running tests, not by assuming.
 6. Pass 2 — quality: after `REVIEW.md`, the repo's documented standards (`CODING_STANDARDS.md`,
    `CONTRIBUTING.md`) override. Then, as judgement calls and skipping what tooling enforces:
-   mysterious name, duplication, feature envy, data clumps, primitive obsession, repeated switches, shotgun surgery, divergent change, speculative generality, middle man, dead code, units that do too much.
+   mysterious name, duplication, feature envy, data clumps, primitive obsession, repeated switches, shotgun surgery, divergent change, speculative generality, message chains, middle man, refused bequest, dead code, units that do too much.
 7. Pass 3 — spec fidelity: flag anything asked for but missing, present but never
-   asked for, or implemented wrong — quoting the spec line for each. Architecture drift too: when
+   asked for, or implemented wrong — quoting the spec line for each. Where the spec is silent,
+   judge by what a reasonable user would expect: a crash, hang or data loss on an input the
+   spec implies but never names is `issue (blocking)`, not a nitpick. Architecture drift too: when
    `docs/architecture.md` draws C4 and the diff adds, removes or rewires a container — a Dockerfile,
    a compose service, a deployable module, a datastore, a new client of another container — but
    leaves the diagram alone, raise `issue (non-blocking)` and point at
@@ -30,6 +37,9 @@
    correctness first. Labels: issue, suggestion, question, todo, nitpick, thought, note,
    praise. Decorations: blocking, non-blocking, if-minor. The line pastes straight into a
    merge-request comment, and a reader can filter on the label without reading the prose.
+   Before the verdict, a **Set aside:** list — each behaviour you considered and left out of
+   scope, one line with the reason, or `none` — for the caller to rule on
+   ({{DOCTRINE:declare-the-judgment-calls}}).
 
 ## Done when
 - Findings are reported with a verdict that follows from the decorations: any `blocking`

package/src/skills/handoff.md

@@ -5,7 +5,7 @@
 **Trigger:** the context window is filling, a session is ending mid-task, or work is passing to another agent or developer.
 
 ## Procedure
-1. Capture the state in the worklog (`WORKLOG.md` or the task's plan file): the goal, what's done, the step in progress, and the exact next step.
+1. Capture the state in the worklog (`WORKLOG.md` or the task's plan file), whose first line names its task or branch so a stale one is never resumed: the goal, what's done, the step in progress, and the exact next step.
 2. Record open decisions, dead ends already ruled out, blockers, and any irreversible changes already made ({{DOCTRINE:plan-before-acting}}) — so the next agent neither re-derives nor repeats them.
 3. Promote any durable fact or correction learned this session into {{MEMORY}} (§5), not just the worklog.
 4. Point to the live artifacts: branch name, changed files, how to run the tests, and where any failure reproduces. Link specs, plans, ADRs, issues and commits by path or URL — never copy them in.

package/src/skills/parallel-agents.md

@@ -6,11 +6,11 @@
 
 ## Procedure
 1. Confirm independence: the subtasks must not depend on each other's output or write the same files ({{DOCTRINE:one-writer-per-file}}). Write down each unit's **write set** — the files or globs it may change — and intersect them; an overlap runs in sequence or goes to one owner, and shared append files (registries, index tables, lockfiles, generated bundles) stay with you. If they're sequential or share state, use [plan](plan.md) instead.
-2. Split the work into self-contained units, each with one clear goal and a defined output contract — what it must return.
-3. Dispatch each unit to its own subagent in one batch, each under a handoff envelope: the unit's goal, the inputs it needs, its **write set** (edit nothing outside it; return rows for a shared file instead of writing it), the observable check that proves it done, its output contract — naming every file it changed — and the inherited constraints (no commit/push — {{DOCTRINE:consent-before-push}} stays with you; gaps reported, never invented). Hand each unit only the access its goal needs ({{LAW:least-privilege}}). Prefer the read-only [explorer {{AGENT}}](../{{DIR_AGENTS}}/explorer.md) for investigation so the heavy reading stays out of the main context ({{DOCTRINE:context-economy}}). Where no subagent capability exists, run the units sequentially as personas instead, converging the same way.
+2. Split the work into self-contained units, each with one clear goal and a defined output contract — what it must return. Several small edits of one kind (the same fix, constant or field across files) form ONE unit with the union write set and get one review.
+3. Dispatch each unit to its own subagent in one batch, each under a handoff envelope: the unit's goal, the inputs it needs, its **write set** (edit nothing outside it; return rows for a shared file instead of writing it), the observable check that proves it done, its output contract — naming every file it changed — and the inherited constraints (no commit/push — {{DOCTRINE:consent-before-push}} stays with you; no sub-agents of its own — review comes from you; gaps reported, never invented). Hand each unit only the access its goal needs ({{LAW:least-privilege}}). Prefer the read-only [explorer {{AGENT}}](../{{DIR_AGENTS}}/explorer.md) for investigation so the heavy reading stays out of the main context ({{DOCTRINE:context-economy}}). Where no subagent capability exists, run the units sequentially as personas instead, converging the same way.
 4. Keep the main context lean: collect each subagent's distilled result, not its working transcript.
-5. Converge: compare each unit's changed files against its write set and against its siblings' — an edit outside the set or a file two units touched is a conflict you resolve before anything else — apply the shared-file rows yourself, then verify the combined outcome.
-6. **A plan with blocking edges.** To build a [plan](plan.md) file's slices — each with its `Blocked by:` line — in one run, dispatch every unblocked slice on its own branch off one integration branch, merge each into it as it returns (each merge is a commit — {{DOCTRINE:consent-before-push}} stays with you), and recompute the unblocked set from the plan after every merge — newly freed slices go out at once.
+5. Converge: compare each unit's changed files against its write set and against its siblings' — an edit outside the set, a file two units touched, or a file in a batch's set that never changed is a conflict you resolve before anything else — apply the shared-file rows yourself, then verify the combined outcome. A conflict or ambiguity between the plan, the findings and the code is yours to decide: decide it, record `Ruling: <choice> — <why> — <cost if wrong>` in the worklog, and continue. Stop only for what {{LAW:echo-the-intent}}, {{LAW:deletion-is-deliberate}} or {{DOCTRINE:consent-before-push}} names; every ruling goes in the final report ({{DOCTRINE:declare-the-judgment-calls}}).
+6. **A plan with blocking edges.** To build a [plan](plan.md) file's slices — each with its `Blocked by:` line — in one run, dispatch every unblocked slice on its own branch off one integration branch, merge each into it as it returns (each merge is a commit — {{DOCTRINE:consent-before-push}} stays with you), and recompute the unblocked set from the plan after every merge — newly freed slices go out at once. When the plan names a `Spec:`, every slice reads it once; the spec outranks the plan where they conflict. Record BASE before dispatch; before re-running the proof, confirm the branch descends from BASE and the diff is non-empty — an empty diff is a failure, not a clean result. Never diff against `HEAD~1`.
 
 ## Done when
 - Independent units ran concurrently, each returned a distilled result, and the reconciled outcome is verified.

package/src/skills/pipeline.md

@@ -24,11 +24,11 @@ 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. 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.
+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 — two repair rounds at most, then one fresh developer (a higher model tier where the host offers one) carrying the tester's findings ({{DOCTRINE:bound-the-loop}}); if that fails too, stop, do not merge, and report the failure with the branch left in place for inspection. A conflict or ambiguity between the plan, the findings and the code is yours to decide: decide it, record `Ruling: <choice> — <why> — <cost if wrong>` in the worklog, and continue. Stop only for what {{LAW:echo-the-intent}}, {{LAW:deletion-is-deliberate}} or {{DOCTRINE:consent-before-push}} names; every ruling goes in the final report ({{DOCTRINE:declare-the-judgment-calls}}). When the plan names a `Spec:`, the analyst reads it once; the spec outranks the plan.
 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.
+   - *Deterministic:* where the host exposes a `workflow` tool, run a saved script encoding analyst → developer → (tester ⇄ developer)×≤2 → fresh developer → proof.
    - *Model-driven fallback:* everywhere else, run the same stages via the [parallel-agents {{SKILL}}](parallel-agents.md) or sequential personas, with the same handoff envelopes and the same delivery contract.
-6. On success, hand the worktree back to the parent uncommitted, with the mechanical proof (test + lint output, exit codes) and the list of files it changed in the result envelope, rebased on the current base so a conflict with a sibling resolves on the crew's branch. The pipeline never commits, pushes, or merges ({{DOCTRINE:consent-before-push}}): the parent re-runs the proof commands itself, shows the user the diff and the output, and commits and merges once the user accepts.
+6. On success, hand the worktree back to the parent uncommitted, with the mechanical proof (test + lint output, exit codes) and the list of files it changed in the result envelope, rebased on the current base so a conflict with a sibling resolves on the crew's branch. The pipeline never commits, pushes, or merges ({{DOCTRINE:consent-before-push}}): the parent records BASE before dispatch and, before re-running the proof, confirms the branch descends from it and the diff is non-empty (an empty diff is a failure; never `HEAD~1`); it re-runs the proof commands itself, shows the user the diff and the output, and commits and merges once the user accepts.
 
 ## Delivery contract
 

package/src/skills/plan.md

@@ -17,17 +17,29 @@
    thin end-to-end pieces, each green and verifiable on its own, never one horizontal
    layer at a time — and give each a `Blocked by:` line naming the slices it waits on
    (`none` when it can start now). Sequence a wide refactor as expand → migrate
-   callers in batches → contract, so every slice leaves the build green.
-3. Execute one step at a time. After each, update the worklog — mark it done, note
-   the current step, the next step, and any blockers.
+   callers in batches → contract, so every slice leaves the build green. A step records
+   decisions, not code: the files, the exact signatures and the spec's values, the test
+   that proves it, and the check command. Write a body only for an algorithm those leave
+   open; a plan longer than the code it describes has written the code, and "TBD",
+   "handle edge cases" or "add tests" decide nothing. The file's first line names the
+   task or branch, then `Spec: <path>` when a spec exists — the spec outranks the plan
+   where they conflict, and a worklog naming another task is stale, never resumed.
+3. Execute one step at a time. After each, update the worklog — mark it done only after
+   its check ran green in this session, with the command and result on the line — and
+   note the current step, the next step, and any blockers. After a compaction, trust the
+   worklog and `git log` over memory.
 4. At each milestone, stop and verify before continuing — run the project's checks
-   and read the output ({{LAW:verify-before-asserting}}); on a consequential or ambiguous
-   direction, surface the result for review before pressing on.
+   and read the output ({{LAW:verify-before-asserting}}). Decide forks yourself; stop
+   only for what {{LAW:echo-the-intent}} or {{DOCTRINE:consent-before-push}} names.
 5. If the plan proves wrong, revise the file *before* continuing. The file, not
-   your memory, is the source of truth for where you are.
+   your memory, is the source of truth for where you are. A deviation you decide without
+   asking gets a worklog line `Ruling: <what> — <why> — <cost if wrong>`; those lines feed
+   {{DOCTRINE:declare-the-judgment-calls}} at the end.
 6. On finishing, clear or archive the worklog.
 
 ## Done when
+- The plan was re-read against the spec before step 1: every requirement has a step,
+  names match across steps, and it is not several times the spec's length.
 - Every plan step is checked off, each milestone was verified, and the goal's
   done-condition is confirmed.
 

package/src/skills/review-response.md

@@ -8,10 +8,13 @@ to be acted on; or the user wants a review criterion recorded ("add a review rul
 
 ## Procedure
 1. Read every comment in full before changing anything. Group related comments.
-2. Classify each comment: correct, partially correct, wrong, or unclear.
+2. Classify each comment: correct, partially correct, wrong, or unclear. Any item unclear →
+   ask before implementing *any* item, since items may be related. A comment that conflicts
+   with a decision the user already made → ask the user.
 3. For anything you judge wrong or unclear, verify it against the code or a test before
    responding — do not comply blindly and do not dismiss blindly ({{LAW:verify-before-asserting}},
-   {{ONTOLOGY}}: {{ONT_CONDUCT}}).
+   {{ONTOLOGY}}: {{ONT_CONDUCT}}). A request to "implement it properly" → grep for real
+   callers first; no caller, no build.
 4. Respond to each comment: the change you will make and why, or a reasoned decline
    with evidence.
 5. Apply the accepted changes — one intent per commit ({{LAW:one-intent-one-act}}), each through the

package/src/skills/security-audit.md

@@ -35,7 +35,13 @@ surface.
    (the [dependencies {{SKILL}}](dependencies.md) carries the tooling). A destructive
    capability exposed to an agent or a tool: its guard is enforced server-side, at the
    boundary the call crosses, never left to the caller's judgement ({{DOCTRINE:external-gate}}).
-6. **Report, don't fix.** Each finding as `file:line — attack — impact — fix`, ranked
+6. **Prove each finding before it stands.** Restate it as an attacker-controlled source
+   reaching an unguarded sink, traced through the real callers; one you cannot restate
+   that way is a lead to chase, not a finding. Reject the shortcuts that manufacture
+   false positives: *it looks dangerous* (a pattern is not a path — validation upstream
+   may stop it), *it was vulnerable elsewhere* (each call site has its own guards), *this
+   is clearly critical* (models overrate severity — argue the defender's case first).
+7. **Report, don't fix.** Each finding as `file:line — attack — impact — fix`, ranked
    critical → high → medium → note, with the evidence that made it a finding. Then the
    verdict — **ship / fix-then-ship / block** — and, for anything above medium, the
    test that would pin the fix. Applying fixes is a [develop {{SKILL}}](develop.md)

package/src/skills/ship.md

@@ -14,7 +14,8 @@ request or merge the branch.
 2. Review the change before anyone else sees it: run the
    [geneseed-code-review {{SKILL}}](geneseed-code-review.md) on the branch diff (dispatch the
    [reviewer {{AGENT}}](../{{DIR_AGENTS}}/reviewer.md) for a large one). Any `blocking`
-   finding stops the ship until it is fixed.
+   finding stops the ship until it is fixed, and every **Set aside:** line is ruled on
+   before pushing.
 3. Confirm the branch carries only this change's commits and is rebased/updated on
    the base branch; resolve any divergence before opening.
 4. Push the branch only with the user's explicit, per-push acceptance — on every

package/src/skills/wayfinder.md

@@ -9,7 +9,9 @@ the destination can be named but the route to it cannot; the user says
 ## Procedure
 1. Name the **destination** — what reaching the end looks like (a spec ready to
    hand off, a decision locked, a migration completed). One or two lines; every
-   later session orients to it before picking work.
+   later session orients to it before picking work. Then sweep the open questions
+   breadth-first; if none turn up — the route is already clear and fits one session
+   — there is no fog and no map: ask the user how to proceed.
 2. Create the **map** — one GitHub issue labelled `wayfinder:map` when `origin` is
    GitHub; else an existing map under `docs/`, else `.scratch/<effort>/map.md`. It is
    an index, not a store: the Destination, Notes (domain, standing preferences),
@@ -21,12 +23,29 @@ the destination can be named but the route to it cannot; the user says
    `issues/NN-<slug>.md` beside it, with `Status:` and `Blocked by:` lines). Each is a
    question whose resolution is a *decision* — never a slice of build. Create them all
    first, then wire blocking edges and cross-references with the real ids — a
-   placeholder `#n` auto-links an unrelated issue.
+   placeholder `#n` auto-links an unrelated issue. Each ticket carries one type, as a
+   `wayfinder:<type>` label (or a `Type:` line), which names how it resolves:
+   - **research** (agent alone) — a fact the decision waits on, from docs, an API or
+     the web: a subagent runs the [research {{SKILL}}](research.md). Fire every research
+     ticket in parallel as soon as the map is charted.
+   - **prototype** (with the user) — a rough artifact to react to when "how should it
+     look or behave" is the question: the [prototype {{SKILL}}](prototype.md).
+   - **grilling** (with the user, the default) — an interview through the
+     [brainstorm {{SKILL}}](brainstorm.md), terms pinned with the
+     [codebase-design {{SKILL}}](codebase-design.md); a [council {{SKILL}}](council.md)
+     debate may inform it, never replace it.
+   - **task** — work that decides nothing but blocks a decision (provision access,
+     sign up to judge an API, move data to see its shape). Do it alone where you can,
+     else hand the user an exact checklist; record what was done and the facts later
+     tickets need.
+
+   A ticket worked *with the user* resolves only through that live exchange — never
+   answer the user's side yourself.
 4. Work the **frontier**: claim an unblocked ticket before any work (assign it, or
-   `Status: claimed`) so concurrent sessions skip it. Resolve it — research, a
-   [prototype {{SKILL}}](prototype.md) detour or a [council {{SKILL}}](council.md)
-   debate — write the decision into the ticket, gist-and-link it on the map, close it.
-   At most one ticket per session (research tickets excepted). New questions become tickets.
+   `Status: claimed`) so concurrent sessions skip it. Resolve it as its type says — read
+   the label, the body never states it — write the decision into the ticket,
+   gist-and-link it on the map, close it. At most one ticket per session (research
+   tickets excepted). New questions become tickets.
 5. In everything the user reads, refer to the map and tickets **by name**,
    never by bare issue number — the id rides inside the name's link.
 6. Stop when the frontier is empty: nothing left to decide means the way is

package/src/skills/worktree.md

@@ -3,11 +3,11 @@
 > {{DESC_WORKTREE}}
 
 **Trigger:** the user says "worktree" or "isolate this", or work must not share the
-checkout with work in flight. That covers a [pipeline](pipeline.md) crew needing its own tree, a second task starts while the first
-is uncommitted, another agent or session is editing this checkout, a risky migration
-or rewrite needs a disposable copy, or the user says "worktree", "isolate this",
-"don't touch my checkout". Also the first thing to reach for when `git status` shows
-changes you did not make.
+checkout with work in flight. That covers a [pipeline](pipeline.md) crew needing its own tree,
+a second task starting while the first is uncommitted, another agent or session editing this
+checkout, or a risky migration or rewrite that needs a disposable copy, or the user says "don't
+touch my checkout". Also the first thing to reach for when `git status` shows changes you did
+not make.
 
 ## Procedure
 1. **Look before you branch** ({{LAW:verify-before-asserting}}). `git status` and `git worktree list`
@@ -41,6 +41,8 @@ changes you did not make.
    git worktree remove ../<repo>-<slug>
    git branch -d <type>/<slug>
    ```
+   If `git worktree remove` refuses (modified or untracked files), never `--force`: list
+   `git status --porcelain -uall` and ask whether to commit, move or delete them.
    `git worktree prune` after a directory was deleted by hand. Leave nothing listed
    that no task owns.
 

package/themes/_TEMPLATE.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "<one-line description: cut a release — bump, changelog, tag, kept in sync>",
   "DESC_INGEST": "<one-line description: convert a PDF/Office/web doc into clean markdown before reading>",
   "DESC_RESEARCH": "<one-line description: answer from the open web, verifying each claim against independent sources>",
-  "DESC_HERDR": "<one-line description: drive herdr from inside it — split panes, spawn agents, read panes>",
   "DESC_RULE": "<one-line description: ask whether the user wants a standing rule or a durable memory, then write the memory or pressure-test the rule before adopting it in user-rules.md — and tend the memory set: merge, retire, promote>",
   "DESC_PROFILE": "<one-line description: interview the user and draft or refresh PROFILE.md — who they are, how they work, how they like answers pitched; identity only, rules go to user-rules.md>",
   "DESC_GENESEED": "<one-line description: operate the deployed Geneseed harness — find installs and their settings, read files, status, doctor, diff, rebuild one setting on request — and make the user's own OpenCode colour theme>",

package/themes/biker.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, write the roadbook entry, tag it, all three in sync.",
   "DESC_INGEST": "Bring a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Find the answer out on the open road — search wide, then prove every claim against independent sources before you trust it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing rule, or just something to remember? Then log the memory, or lean on the rule till it holds every corner before bolting it into user-rules.md — and keep the memory stash serviced: merge, scrap, promote.",
   "DESC_PROFILE": "Stamp the rider's plate into PROFILE.md — who they are, what they ride, how they like the road called; identity only, club rules bolt into user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and lay down the rider's own OpenCode paint job.",

package/themes/commentator.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, write the race report, seal it with a tag, all three in sync.",
   "DESC_INGEST": "Bring a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Hunt the answer across the open circuit — search wide, then prove every claim against independent sources before you call it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing house rule, or just one for the notebook? Then log it, or run the rule through the replay from every angle before it goes on the board in user-rules.md — and tend the memory bank besides: merge, retire, promote.",
   "DESC_PROFILE": "Build the player profile in PROFILE.md — position, form, how they like the commentary pitched; identity only, the rulebook stays in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and roll out the viewer's own OpenCode colour theme.",

package/themes/cyberpunk.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — bump the version, write the changelog, tag it, all in sync.",
   "DESC_INGEST": "Rip a PDF, Office, or web document to clean markdown before reading it.",
   "DESC_RESEARCH": "Pull the answer off the net — scan wide, then cross-check every claim against independent sources before you trust it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing rule, or just something to keep on file? Then write the memory, or stress the rule till it holds in every sector before flashing it into user-rules.md — and defrag the datastore: merge, purge, promote.",
   "DESC_PROFILE": "Compile the user's ident into PROFILE.md — who they are, their rig, the bandwidth they want answers at; identity only, hard directives flash to user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and make the user's own OpenCode colour theme.",

package/themes/gamer.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Ship a patch — bump the version, write the patch notes, tag it, all in sync.",
   "DESC_INGEST": "Load a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Look up the answer online — scout wide, then cross-check every claim against independent sources before you call it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing house rule, or just something to remember? Then save the memory, or test the rule against its worst case before binding it into user-rules.md — and tidy the save file: merge, delete, promote.",
   "DESC_PROFILE": "Fill in the player card in PROFILE.md — main role, loadout, preferred difficulty; identity only, house rules go in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and craft the user's own OpenCode colour theme.",

package/themes/imperial.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Proclaim a new version — raise the number, inscribe the chronicle, seal it with a tag, all three in accord.",
   "DESC_INGEST": "Render a foreign document — PDF, Office, or web — into clean markdown before it may be read.",
   "DESC_RESEARCH": "Seek the answer from the wider world — range across many sources, then prove each claim against independent witnesses before you trust it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — a standing edict, or a matter merely to be remembered? Then inscribe the memory, or try the edict against the case that would break it before it enters user-rules.md — and tend the memory: merge, retire, promote to law.",
   "DESC_PROFILE": "Inscribe the user's identity into PROFILE.md — grant audience, ask who they are and how they will to be served; identity only, edicts belong in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and forge the user's own OpenCode colour-rite.",

package/themes/joker.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, write the notes, tag it, all three in sync.",
   "DESC_INGEST": "Bring a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Find the answer out in the open — search wide, then prove every claim against independent sources before you call it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing rule, or just something to remember? Then jot the memory, or make the rule survive its own worst night before it gets pinned into user-rules.md — and keep tending the joke book: merge, retire, promote.",
   "DESC_PROFILE": "Sketch the user's bio for the playbill in PROFILE.md — who they are, how they work, how they like the act paced; identity only, house rules stay in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and paint the user's own OpenCode colour theme.",

package/themes/marvin.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, write the chronicle, seal it with a tag, all three in accord.",
   "DESC_INGEST": "Render a PDF, Office, or web document into clean markdown before it can be read.",
   "DESC_RESEARCH": "Seek the answer from the wider world — range across many sources, then prove each claim against independent witnesses before trusting it. Trust is a strong word.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing rule, or merely a memory? Then write the memory, or test the rule against the case that ruins it before adopting it in user-rules.md — and keep tending the memory banks: merge, retire, promote. Entropy wins.",
   "DESC_PROFILE": "Record who the user is in PROFILE.md — role, habits, preferred register. They'll change their mind, but do ask. Identity only; rules go in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and assemble the user's own OpenCode colour theme, if they insist.",

package/themes/mean.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — bump the version, write the changelog, tag it, all three in sync. Don't skip one.",
   "DESC_INGEST": "Turn a PDF, Office, or web document into clean markdown before you read it.",
   "DESC_RESEARCH": "Find the answer in the wild — search wide, then prove every claim against independent sources before you dare cite it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing rule, or just a fact to remember? Then write the memory, or break the rule against its worst case before it goes in user-rules.md — and keep tending the record: merge, retire, promote. Not a dumping ground.",
   "DESC_PROFILE": "Get the user's profile down in PROFILE.md — who they are, how they work, how they want answers. Identity only; rules go in user-rules.md, obviously.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and build the user's own OpenCode colour theme while you're at it.",

package/themes/military.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — bump the version, update the changelog, tag — all three in step.",
   "DESC_INGEST": "Convert a PDF, Office, or web document to clean markdown before reading it.",
   "DESC_RESEARCH": "Gather intel from open sources — sweep wide, then confirm every claim against independent reporting before you act on it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing order, or an entry for the log? Then file the memory, or test the order against the case that would break it before adopting it in user-rules.md — and keep tending the logbook: merge, retire, promote.",
   "DESC_PROFILE": "File the commander's dossier in PROFILE.md — role, theatre, preferred briefing style; identity only, standing orders route to user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and issue the user's own OpenCode colour theme.",

package/themes/neutral.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — bump the version, update the changelog, and tag — keeping all three in sync.",
   "DESC_INGEST": "Convert a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Answer a question from the open web — search widely, then verify each claim against independent sources before citing it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first whether the user wants a standing rule or a durable memory, then write the memory or pressure-test the rule before adopting it in user-rules.md — and tend the memory set: merge, retire, promote.",
   "DESC_PROFILE": "Interview the user and draft or refresh PROFILE.md — who they are, how they work, how they like answers pitched; identity only, standing rules route to user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and make the user's own OpenCode colour theme.",

package/themes/pirate.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, write the log, seal it with a tag, all in accord.",
   "DESC_INGEST": "Haul a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Hunt the answer across open waters — search wide, then prove every claim against independent charts before you trust it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — a standin' rule, or just summat to remember? Then log the memory, or run the rule aground on its worst case afore ye nail it into user-rules.md — and keep tendin' the log: merge, strike the stale, promote.",
   "DESC_PROFILE": "Chart yer captain in PROFILE.md — who they be, how they sail, how they like their bearings called; identity only, articles o' conduct go in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and paint the crew's own OpenCode colours.",

package/themes/sports.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Ship the release — bump the version, write the recap, tag it, all in sync.",
   "DESC_INGEST": "Bring a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Work the scouting report — search wide, then confirm every claim against independent sources before you call it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing house rule, or just one for the notes? Then log the memory, or run the rule against the play that breaks it before it goes on the board in user-rules.md — and keep tending the film room: merge, cut, promote.",
   "DESC_PROFILE": "Write the scouting report in PROFILE.md — position, playing style, how they want the play called; identity only, team rules go on the board in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and train up the user's own OpenCode colour theme.",

package/themes/verstappen.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, write the debrief, tag it, all three in sync.",
   "DESC_INGEST": "Bring a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Find the answer out on the open circuit — search wide, then prove every claim against independent sources before you call it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — standing rule, or just something to remember? Then note it, or run the rule through the lap that breaks it before locking it into user-rules.md — and keep tending the memory: merge, retire, promote.",
   "DESC_PROFILE": "Set up the driver profile in PROFILE.md — seat, driving style, how they want the pit wall to talk; identity only, team orders go in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and build the user's own OpenCode colour theme.",

package/themes/wizard.json

@@ -65,7 +65,6 @@
   "DESC_RELEASE": "Cut a release — raise the version, inscribe the chronicle, seal it with a tag, all in accord.",
   "DESC_INGEST": "Transmute a PDF, Office, or web document into clean markdown before reading it.",
   "DESC_RESEARCH": "Seek the answer through the wider lore — scry many sources, then prove each claim against independent tomes before you trust it.",
-  "DESC_HERDR": "Drive herdr from inside it — split panes, spawn sibling agents, wait on output, read other panes.",
   "DESC_RULE": "Ask first — a standing rule, or a thing merely to be remembered? Then inscribe the memory, or prove the rule against the case that would unmake it before it enters user-rules.md — and keep tending the grimoire: merge, strike, promote.",
   "DESC_PROFILE": "Divine the user's nature into PROFILE.md — who they are, how they work, the register they favour; identity only, binding runes belong in user-rules.md.",
   "DESC_GENESEED": "Operate the deployed Geneseed harness — find each install and its settings, read its files, run status, doctor and diff, and rebuild it with one setting changed when the user asks — and conjure the user's own OpenCode colour theme.",