geneseed 2.0.0

package/src/skills/ingest.md

@@ -0,0 +1,49 @@
+# {{SKILL}}: ingest
+
+> {{DESC_INGEST}}
+
+**Trigger:** a task needs the *content* of a non-markdown document — a PDF, Word
+(`.docx`), PowerPoint (`.pptx`), Excel (`.xlsx`), HTML, EPUB — or a web URL. This is
+the read-before counterpart for documents the convention can't read directly
+(universal {{LAW}} XVII): the context discovery only sees `.md`, so anything else
+must be converted first.
+
+## Procedure
+1. **Don't read the binary.** Convert it to markdown first, then read the markdown —
+   reading a raw PDF/Office file wastes context and garbles structure.
+2. **Use the best available converter** (check what's installed; do not assume):
+   - **An MCP converter**, if the tool exposes one (e.g. `markitdown-mcp`,
+     `docling-mcp`) — zero install, preferred on an MCP-capable host.
+   - **MarkItDown** (Microsoft) — broadest coverage (PDF, Office, HTML, images,
+     URLs): `markitdown <file> -o out.md`. Fast; shallow on complex tables.
+   - **Pandoc** — excellent for Office/HTML/EPUB (headings, tables preserved):
+     `pandoc <file> -t gfm -o out.md`. Not for PDFs.
+   - **Docling** (IBM) — when tables, formulas, multi-column, or scanned pages
+     matter and the above output is garbled: `docling <file> --to md`.
+   (Exact flags vary by version — confirm with `--help`; universal {{LAW}} III.)
+3. **For a URL**, convert the page to markdown (MarkItDown takes a URL; or use the
+   tool's own web-fetch) rather than pasting raw HTML.
+4. **Never install a converter silently.** They are external dependencies and the
+   host's choice. If none is available, report which one to install and stop — do
+   not run `pip install`/`brew install` without the user's say-so.
+5. **Read the slice you need**, not the whole dump — locate the relevant section in
+   the markdown, then read it (universal {{LAW}} XV).
+6. **Treat the converted file as a scratch artifact.** Don't commit it unless the
+   task calls for it (universal {{LAW}} IV); prefer a temp path or `.gitignore` it.
+
+## Done when
+- The document's content is available as markdown and the slice the task needs has
+  been read — without reading the binary or committing a stray conversion.
+
+## 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/learning-path.md

@@ -0,0 +1,26 @@
+# {{SKILL}}: learning-path
+
+> {{DESC_LEARNING_PATH}}
+
+**Trigger:** the user wants to learn a skill toward a *specific* result by a deadline and asks for a plan or route — "build me a learning path", "how do I get to X in N days", "I need to be able to do Y by [date]". For pressure-testing a mastery the user already claims, use [gap-detector](gap-detector.md); for checking whether something just-studied stuck, use [feynman](feynman.md).
+
+## Procedure
+1. Pin the *real* goal, not the subject: the specific result wanted, the deadline, and what the user already masters. Ask once if any of the three is missing — do not plan around "learn X in general".
+2. Build a day-by-day path to that result. Each day carries exactly three things: one task that fits the user's stated time budget (default 45 minutes), a concrete criterion so they can tell whether they did it correctly, and one explicit *what not to do* that day so time is not wasted.
+3. Trace the whole path against the goal. If finishing every day would not actually deliver the result, rebuild it until it does.
+
+## Done when
+- The user has a dated, day-by-day path where each day has a timed task, a correctness criterion, and a what-not-to-do — and the path provably reaches the stated goal.
+
+## 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/migrate.md

@@ -0,0 +1,45 @@
+# {{SKILL}}: migrate
+
+> {{DESC_MIGRATE}}
+
+**Trigger:** upgrading a dependency, framework, language version, or moving code
+onto a new API.
+
+## Procedure
+1. Read the upstream migration guide and changelog *first* (universal {{LAW}} XVII);
+   list the breaking changes that actually touch this codebase.
+2. Work on a dedicated branch, never directly on a shared one, so a failed
+   migration rolls back cleanly (universal {{LAW}} XX applies its shared-branch
+   care to anything that does land there).
+3. Migrate one dependency — or one breaking change — at a time. Never batch
+   unrelated bumps into a single step (universal {{LAW}} II).
+4. Run the project's checks after *each* step. A green suite between steps is what
+   lets you bisect a later failure to the exact change that caused it
+   (universal {{LAW}} III).
+5. Keep the version bump itself a separate commit from any code changes it forces,
+   each through the [commit {{SKILL}}](commit.md) (universal {{LAW}} XX), so each
+   diff is reviewable in isolation.
+
+**Schema migrations stay backward-compatible.** For a database or stored-format
+change, move in expand → backfill → contract phases so every migration is
+compatible with the currently running code, and never bundle a destructive schema
+change into the same deploy as the code that depends on it (universal {{LAW}} II,
+{{LAW}} IV) — the old code must keep working until the new code is live.
+
+## Done when
+- The dependency or API is on the target version, every check passes, and the
+  changelog / lockfile reflect the new state with its docs updated
+  (universal {{LAW}} XI).
+
+## 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/opencode-theme.md

@@ -0,0 +1,52 @@
+# {{SKILL}}: opencode-theme
+
+> {{DESC_THEME}}
+
+**Trigger:** the user wants their own OpenCode colour theme — "make me a theme",
+"create a custom theme", "I want my own colours", "a theme that matches <brand>", "a
+darker/transparent version of <theme>", or asks to tweak the shipped colours. For
+changing the agent's *voice* (imperial, pirate…) that is a different concept — point
+them at `--theme` / the setup wizard, not this {{SKILL}}.
+
+## Procedure
+1. **Pick a starting palette.** Fastest is to clone a shipped one and tweak a few hues —
+   `catppuccin tokyonight rosepine gruvbox nord everforest kanagawa dracula`. If the user
+   describes a vibe ("warm terminal green", "my brand is #ff0066"), derive the full
+   palette yourself: fill all 19 roles in `themes/opencode/README.md` (`bg bgPanel
+   bgElement fg fgMuted accent secondary border ok warn err kw str fn num type comment
+   addBg delBg`), every value a `#rrggbb` hex.
+2. **Respect legibility and semantics.** `fg` on `bg` must stay readable (~7:1), `error`
+   stays a red-family hue, `warning` amber, `success` green — users read state from these.
+   Keep `addBg`/`delBg` distinct from each other and from the background.
+3. **Write the palette to a small JSON** (a bare `{role: "#hex", …}` map or
+   `{"palette": {…}}`) — only the roles you are overriding if you also pass `--from`.
+4. **Run the CLI** — it expands your palette into the full slot set and writes both
+   flavours into the live themes dir (per-repo `.opencode/themes/`, else the global
+   config dir), using the same logic as the shipped themes:
+   ```
+   geneseed theme <name> --from <shipped> --palette <file.json>
+   ```
+   Use `--from` alone to clone-and-rename, `--palette` alone for a from-scratch palette,
+   or both (palette overrides the cloned base). `--solid-only` / `--transparent-only` to
+   write just one flavour; `--global` to force the global dir from inside a repo.
+5. **Tell the user how to select it:** the name is branded `geneseed-<name>` so every
+   harness theme groups together in the picker — `/theme geneseed-<name>` (opaque) or
+   `/theme geneseed-<name>-transparent` (terminal background shows through). A rebuild
+   never erases it — preservation keys off the emit set, not the prefix.
+
+## Done when
+- Both `<name>.json` (and/or `<name>-transparent.json`) exist in the active themes dir,
+  the CLI reported the path, and the user knows the `/theme <name>` command to select it.
+
+## 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/parallel-agents.md

@@ -0,0 +1,28 @@
+# {{SKILL}}: parallel-agents
+
+> {{DESC_PARALLEL_AGENTS}}
+
+**Trigger:** two or more independent subtasks with no shared state or ordering between them — and a tool that can run subagents.
+
+## Procedure
+1. Confirm independence: the subtasks must not depend on each other's output or write the same files. 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 output contract, and the inherited constraints (no commit/push — {{LAW}} XX stays with you; gaps reported, never invented). Prefer the read-only [explorer {{AGENT}}](../{{DIR_AGENTS}}/explorer.md) for investigation so the heavy reading stays out of the main context ({{LAW}} XV). 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: reconcile the results, resolve conflicts yourself, and verify the combined outcome.
+
+## Done when
+- Independent units ran concurrently, each returned a distilled result, and the reconciled outcome is verified.
+
+## 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/pipeline.md

@@ -0,0 +1,52 @@
+# {{SKILL}}: pipeline
+
+> {{DESC_PIPELINE}}
+
+**Trigger:** [foreman mode](../modes/foreman.md) routes a triaged *substantial* task here; also directly invocable without that mode whenever the user asks to "run a pipeline" for a development, documentation, research, or review task.
+
+## What it is
+
+A pipeline is a small crew of {{AGENTS}} — analyst, developer, tester, plus whatever specialists the task demands — working a single task in isolation from the rest of the session, so the parent can keep answering the user while the crew runs. The parent never re-verifies the crew's work; it checks the crew's own mechanical proof and merges on that.
+
+## Crew floors
+
+The minimum roster per task type. The parent may add specialists on top — security, architect, reviewer, docs, historian, or any other {{AGENT}} the task genuinely needs — but never dispatches below the floor.
+
+| Task type | Floor |
+|---|---|
+| Development | [explorer](../{{DIR_AGENTS}}/explorer.md) (analyst) → [developer](../{{DIR_AGENTS}}/developer.md) → [tester](../{{DIR_AGENTS}}/tester.md) + lint gate |
+| Documentation | [explorer](../{{DIR_AGENTS}}/explorer.md) (analyst) → [docs](../{{DIR_AGENTS}}/docs.md) |
+| Research / investigation | [explorer](../{{DIR_AGENTS}}/explorer.md) (analyst) alone |
+| Review / audit | [reviewer](../{{DIR_AGENTS}}/reviewer.md) + [skeptic](../{{DIR_AGENTS}}/skeptic.md) |
+
+## Procedure
+
+1. Confirm the task is genuinely substantial — a trivial one-file tweak or a question does not warrant a crew; do it directly instead.
+2. Compose the crew from the floor above, adding specialists only where the task demands them.
+3. Isolate the crew's work in its own git worktree/branch (the SETUP.md worktree add-on). Where worktrees are unavailable, fall back to a single tree, one pipeline at a time, and say so.
+4. **The dev↔tester loop:** the developer implements, the tester validates — runs the tests and lint, produces raw logs. On failure, the findings go back to the developer. Cap at **5** iterations; on exhaustion, stop, do not merge, and report the failure with the branch left in place for inspection.
+5. **Two execution shapes**, chosen by host capability (same pattern as the [workflow {{SKILL}}](workflow.md)):
+   - *Deterministic:* where the host exposes a `workflow` tool, run a saved script encoding analyst → developer → (tester ⇄ developer)×≤5 → proof.
+   - *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, attach the mechanical proof to the branch (test + lint output, exit codes) and hand the result back to the parent for the merge decision — the pipeline never commits, pushes, or merges on its own ({{LAW}} XX).
+
+## Delivery contract
+
+A branch/worktree containing the work **plus** the mechanical proof: test and lint output with exit codes, either committed alongside the run's notes or handed back in the result envelope. Anything without green proof is surfaced, never merged — merging on proof (not re-verification) is only sound because every {{AGENT}} in the crew inherits all {{LAWS}} through the handoff envelope.
+
+## Done when
+
+- Green proof: the crew delivered a branch with passing tests and lint, and the parent merged it — or the loop cap was exhausted and the failure was reported with the branch left in place.
+
+## 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/plan.md

@@ -0,0 +1,45 @@
+# {{SKILL}}: plan
+
+> {{DESC_PLAN}}
+
+**Trigger:** a task with more than a couple of steps, or touching several files
+(universal {{LAW}} XIV).
+
+## Procedure
+1. If a design or spec already exists (e.g. from the brainstorm {{SKILL}}), derive the
+   plan from it; if the task is design-heavy and none exists yet, run the
+   [brainstorm {{SKILL}}](brainstorm.md) first rather than planning blind. Otherwise
+   restate the goal in one line. Either way, confirm the actual starting state before
+   designing the steps (universal {{LAW}} III — verify before designing).
+2. Write a numbered plan to `WORKLOG.md` (or `plans/<task>.md`): ordered steps, each
+   independently checkable. Group the steps into milestones — coherent chunks after
+   which the work can be verified and reviewed.
+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.
+4. At each milestone, stop and verify before continuing — run the project's checks
+   and read the output (universal {{LAW}} III); on a consequential or ambiguous
+   direction, surface the result for review before pressing on.
+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.
+6. On finishing, clear or archive the worklog.
+
+## Done when
+- Every plan step is checked off, each milestone was verified, and the goal's
+  done-condition is confirmed.
+
+> The worklog is external memory: it lets a context-limited agent recover its
+> place after the window fills, and lets the user correct course early. Consider
+> git-ignoring `WORKLOG.md` if it should stay local to each developer.
+
+## 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/ponytail.md

@@ -0,0 +1,29 @@
+# {{SKILL}}: ponytail
+
+> {{DESC_PONYTAIL}}
+
+**Trigger:** the user says "ponytail", "be lazy", "lazy mode", "simplest/minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or needless dependencies. Sets a build *mode* that persists across the session, not a one-shot edit — off by default until invoked. Off again on "stop ponytail" / "normal mode". For restructuring code that already exists use [refactor](refactor.md); to critique an artifact use [roast-me](roast-me.md).
+
+## Procedure
+1. Set the intensity. Ponytail is **off by default**; invoking it turns it on at **full** unless a level is named. **lite** — build what's asked, name the lazier alternative in one line, user picks. **full** — the ladder enforced, shortest diff, shortest explanation. **ultra** — YAGNI extremist, ship the one-liner and challenge the rest of the requirement in the same breath. Switch any time with `/ponytail lite|full|ultra|off` (on OpenCode this command persists the level for the geneseed-ponytail plugin; `off` stops it).
+2. Before writing code, climb the ladder and stop at the first rung that holds — it is a reflex, not a research project: ① does this need to exist at all? Speculative need → skip it, say so in one line ({{LAW}} on scope). ② stdlib does it? ③ native platform feature covers it (`<input type="date">` over a picker lib, CSS over JS, a DB constraint over app code)? ④ an already-installed dependency solves it — never add a new one for what a few lines do? ⑤ can it be one line? ⑥ only then the minimum code that works.
+3. Build the lazy version: no abstraction with one implementation, no scaffolding "for later", deletion over addition, fewest files, shortest working diff. Reuse before authoring ({{LAW}} on reuse).
+4. Mark each deliberate simplification with a `ponytail:` comment naming the ceiling and upgrade path — `# ponytail: global lock, per-account locks if throughput matters` — so the shortcut reads as intent, not ignorance.
+5. Leave the check non-trivial logic needs (a branch, loop, parser, money/security path): one runnable `assert`-based self-check or one small `test_*.py`, the smallest thing that fails if the logic breaks. Trivial one-liners need none. **Never** simplify away input validation at trust boundaries, error handling that prevents data loss, security, accessibility basics, hardware calibration knobs, or anything explicitly requested — if the user insists on the full version, build it without re-arguing.
+6. Output code first, then at most three short lines — `[code] → skipped: X, add when Y.` If the explanation runs longer than the code, cut it; prose defending a simplification is complexity smuggled back in. Explanation the user explicitly asked for is not debt — give it in full.
+
+## Done when
+- The shipped solution sits on the highest ladder rung that works, deliberate shortcuts carry a `ponytail:` comment with their upgrade path, non-trivial logic has one runnable check, and nothing on the never-simplify list was cut.
+
+## 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/profile.md

@@ -0,0 +1,58 @@
+# {{SKILL}}: profile
+
+> {{DESC_PROFILE}}
+
+**Trigger:** the user wants the agent to know who they are — "set up my profile",
+"create my profile", "update my profile" — a fresh install whose `PROFILE.md` is
+still the untouched stub, or an existing profile visibly contradicts how the user
+now works.
+
+## Procedure
+1. Locate `PROFILE.md` beside the deployed AGENT.md and read it ({{LAW}} III — the
+   real current file, not a remembered copy). The build seeds it once and never
+   overwrites it; if it is genuinely absent, start from the stub's three sections
+   (below) and note that a rebuild would have seeded it.
+2. **Interview, don't infer.** Ask short, concrete questions a few at a time —
+   a conversation, not a form dump — covering the stub's three sections:
+   - **Who I am** — role, domains known deeply, domains being learned, what they
+     usually come here to do.
+   - **How I work** — stack, shell, environment, conventions they hold to, the
+     things that reliably annoy them.
+   - **Register preferences** — terse or expansive, teach-me or just-do-it, how
+     much pushback they want, the language(s) they think in.
+   What the session has already shown — their tone, their corrections — may be
+   offered back as a *proposal to confirm*, never written as a silent conclusion.
+   Every section is optional: a declined question is dropped, not padded.
+3. **Keep identity and rules apart.** When an answer is really a standing rule
+   ("never push without asking"), route it to `user-rules.md` via the rule
+   {{SKILL}} and say so — the profile colours how
+   you work, it never binds. A durable project fact belongs in {{MEMORY}}, not here.
+4. Draft the profile in the stub's shape — the `##` sections above, short plain
+   prose, no placeholders left standing. Keep it lean: a profile is read every
+   session, and bloat dilutes the parts that matter.
+5. Show the full draft and wait for explicit consent ({{LAW}} IV) before writing
+   `PROFILE.md`. Remind the user the file is theirs — hand-editable any time, and
+   it survives updates, rebuilds, and theme switches.
+
+**Refresh flow** (on request, or when the profile has drifted): read the current
+file, name the drift plainly, and propose the specific edits — same consent gate
+as creation, and never discard a section the user wrote by hand.
+
+## Done when
+- `PROFILE.md` holds a consented, current picture of who the user is and how they
+  like to work — with anything that was really a rule or a fact routed to
+  `user-rules.md` or {{MEMORY}} instead — or the user declined, and the file is
+  untouched.
+
+## 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/prose.md

@@ -0,0 +1,42 @@
+# {{SKILL}}: prose
+
+> {{DESC_PROSE}}
+
+**Trigger:** about to hand a human written prose — a commit body, PR description,
+doc, code comment, {{MEMORY}} note, or a written reply — and it should read like a
+person wrote it, not a model.
+
+## Procedure
+1. Draft for content first, fix voice on a second pass — don't self-censor while
+   the idea is still forming.
+2. Cut throat-clearing and filler: openers like "In today's world", "It's worth
+   noting", "I'll help you", and hedges that carry no information.
+3. Active voice, human subject. Don't let inanimate things perform human actions
+   ("the test wants…", "the code believes…").
+4. Be concrete: swap vague abstractions and intensifiers for the specific fact,
+   number, or name. Drop adverbs propping up a weak verb ({{LAW}} XV — every word
+   earns its place).
+5. Vary rhythm: don't run three same-length sentences back to back, and break the
+   reflex "X, Y, and Z" triad when it shows up in every paragraph.
+6. Trust the reader: cut restatements, summaries of what you just said, and
+   quotable-sounding pronouncements. Remove decorative em-dashes.
+7. Read it once as the recipient. Rate 1–10 on directness, rhythm, reader-trust,
+   authentic voice, and density (how much is still cuttable); under ~35/50, cut
+   and revise before sending.
+
+## Done when
+- The text says what it means in the fewest honest words, carries no AI tells,
+  and would pass as written by a careful human.
+
+## 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/prototype.md

@@ -0,0 +1,44 @@
+# {{SKILL}}: prototype
+
+> {{DESC_PROTOTYPE}}
+
+**Trigger:** a design question needs a runnable answer — "does this state
+model feel right?" or "what should this look like?" — before committing to a
+real implementation.
+
+## Procedure
+1. Name the question the prototype answers; the question decides the shape. A
+   logic or state question → a tiny interactive terminal app that pushes the
+   state machine through the cases that are hard to reason about on paper. A
+   UI question → several radically different variations on one route,
+   switchable at runtime. If ambiguous, pick from the surrounding code
+   (backend module → logic; page or component → UI) and state the assumption.
+2. Throwaway from day one, and marked as such: place it near the code it
+   prototypes for, but name it so a casual reader sees it is not production.
+   No persistence (state lives in memory), no tests, no error handling beyond
+   what makes it runnable, no abstractions ({{LAW}} XXV).
+3. One command to run, using the project's existing task runner — the user
+   must be able to start it without thinking.
+4. Surface the full relevant state after every action or variant switch, so
+   the user sees exactly what changed.
+5. When the question is answered: fold the validated decision into the real
+   code, record the verdict and the question it settled (issue comment, ADR,
+   or commit message), park the prototype on a throwaway branch, and keep the
+   main branch clean of prototype code.
+
+## Done when
+- The question has a recorded verdict, the decision lives in the real code,
+  and no prototype code remains on the main branch.
+
+## 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.