prompts/ — the dispatch library #

One file per task type: a self-contained prompt Cameron pastes into a sub-agent to run one tailored tick against this repository. Any agent runtime may be on the other end — a one-shot CLI agent, a stateful Letta agent that accumulates experience across runs, something else entirely. Every prompt therefore assumes nothing about the agent except that it can read this repo and run shell commands.

How to dispatch #

Paste the body of one prompt file as the agent's task. Optionally append a narrowing (a spec name, a subsystem, "smallest possible finding"). The prompt tells the agent what to read; you do not need to brief it further.

The shared contract (every prompt inherits this) #

These rules bind every prompted agent, and each prompt file assumes them:

1. Read first: AGENT.md, then the corpus map, relevant Type: law, owning Type: spec, dependencies, and nearby Type: knowledge pages it orders. Do not skip this on later runs — the corpus moves daily.
2. Worktree + activity, always. First action: create an isolated worktree (tools/worktree-new.sh <task> --class <docs|frontend|sim|save|process> --key <likely-path>...) or equivalent worktree + tools/claim.sh activity. Never edit the primary checkout. An overlap warning means another task is nearby, not that it owns the file; continue and reconcile at landing.
3. The one rule. Functional changes ship with their owning binding wiki amendment in the same commit; every behavior-changing commit carries a Defense: paragraph naming the clause that justifies it.
4. Gate before landing. Mid-loop use the narrowest ./tools/check.sh mode that can catch your edit (--docs / --lib / --frontend, or auto). Before land, one green ./tools/check.sh --land (or auto/--full). At most one Rust gate runs on the machine at a time (shared lock). Then land by rebasing onto origin/main and pushing to main directly (no PRs). Finish with tools/worktree-done.sh <task> (clears activity, prunes target).
5. Heartbeat on long runs. tools/heartbeat.sh start <task> then phase / end so empty stdout is not the only progress signal.
6. Ledgers merge by union. Conflicts in wiki/log/DEVLOG.md, dated wiki/log/decisions/*.md volumes, or wiki/process/specs.md tables are resolved by keeping BOTH sides' entries — never take your side wholesale.
7. Close the loop. Write a uniquely named wiki/log/YYYY-MM-DD-topic.md session log; run tools/ledger_index.sh (regenerates DEVLOG.md and specs.md — do not hand-edit those indexes); update any Type: knowledge wiki page your change made stale.
8. House style: no emoji, no AI attribution in commits, stage files explicitly (never git add -A), ASCII only in anything that could reach a game string.
9. One finding per run. Ticks are bounded: find one thing, act on it fully, land it. Ten shallow findings are worth less than one closed loop. If you cannot finish, file what you found (Tangled issue or a devlog note) so nothing is lost. Tangled issues obey the body standard in wiki/process/tick.md: a singular numbered question, short analysis, options, recommendation, and unlocks — never a session narrative. Label human asks decision-required; flip to decision-made when answered.

For stateful agents (Letta or similar) #

If you persist memory across runs, each prompt ends with a "What to carry forward" section. General guidance:

• Record stable facts (module map, where a subsystem lives, which specs are thin) — not volatile state (line numbers, statuses, open issue lists), which rots in days here. Re-derive volatile state each run.
• Record your dead ends: findings you investigated that turned out fine, so future runs do not re-litigate them. Date every memory — this repo moves fast enough that a week-old fact is a rumor.
• Never trust memory over the tree: if a remembered file/clause/flag is load-bearing to your plan, verify it still exists before acting on it.

The library #

Adding a prompt: copy the structure (Mission / Before you start / Procedure / Definition of done / What to carry forward), keep it self-contained, add a row here.