opencode-thrum-pro 0.1.0

package/assets/skills/fixing-documentation-errors/SKILL.md

@@ -0,0 +1,258 @@
+---
+name: fixing-documentation-errors
+description: "Use the moment you notice documentation is wrong, stale, incomplete, or contradicts what a command actually does - a doc that omits a flag or subcommand that exists, a README/llms.txt/CLI-help/docstring/comment that disagrees with observed behaviour, a version-stamped section that predates a feature, an example that would fail if run, a doc claim you were about to cite and could not confirm. Illustrative (non-exhaustive) triggers - 'the docs don't mention X', 'llms.txt is out of date', 'the help text says Y but it actually does Z', 'that flag isn't documented', 'this example is wrong', 'the docs are stale here', 'I should file a bead about the docs', 'I'll note the doc gap' - but the trigger is NOTICING A DOC DEFECT, not matching a phrase. Fires regardless of what you were originally doing; a doc error found mid-task is still in scope."
+---
+
+# Fixing Documentation Errors
+
+## The rule
+
+**You found it, you can verify it, you fix it — in this turn.**
+
+No triage. No coordinator approval. No bead-then-wait. Documentation you can
+verify is the one class where the person who found the defect is already the
+best-placed person to fix it, and every step you insert between finding and
+fixing destroys the thing that made you well-placed.
+
+File a bead recording that you **did** it. Never file a bead **instead of**
+doing it.
+
+## This applies to EVERY role — what changes is the action, never whether you act
+
+**No agent may ignore a doc defect, and no agent may file-and-move-on.** Those
+are the two forbidden responses for everyone. What differs by role is only
+whether you fix it yourself or ask first.
+
+| Role | What you do, IN THIS TURN |
+|---|---|
+| Coordinator · orchestrator · researcher · gate · watcher | **Fix it.** You hold the authority. Verify, edit every copy, then file the record. |
+| Implementer **between tasks / idle** | **Fix it.** Same as above. |
+| Implementer **mid-task** | **ASK your orchestrator or coordinator, in this turn** — one line: *"Found a doc error: `<file:line>` says X, actual behaviour is Y (verified how). Want me to fix it now, or carry it?"* |
+| Sub-agent | **Report it to whoever dispatched you**, in your final report, with file:line and the measured truth. Do not fix outside your assigned scope. |
+
+**For the mid-task implementer, THE ASK IS THE ACTION.** It is not a deferral and
+it is not a bead. It goes out in the turn you found the defect, while you still
+hold the file, the line, and the evidence — so that whoever answers can say
+"yes, now" and you are already warm.
+
+⚠️ **Do not ask and then drop it.** If no answer arrives before you finish your
+task, say so explicitly in your completion report, with the file:line and the
+measured truth attached. An unanswered ask that vanishes is the same outcome as
+never asking.
+
+⚠️ **Do not ask for permission you already have.** If the fix is inside the file
+you were already sent to change, and it is unambiguous, just fix it. The ask
+exists for scope discipline, not as a ritual.
+
+**Manager side — if you receive one of these asks, answer it in the turn you
+read it.** "Yes, fix it" is almost always right, and it is cheapest at the moment
+the reporter is still warm. Every hour you sit on it converts a five-minute edit
+into a re-derivation. If you say "not now", say what happens to it instead —
+never leave the reporter holding it.
+
+## Why deferring is worse than it looks
+
+Filing while warm does not defer the work. **It duplicates it and throws away
+the expensive half.**
+
+To write a useful doc bead you must state the file, the line, the wrong text,
+the correct text, and how you know. That *is* the fix specification — writing it
+costs roughly what performing the edit costs. So the real choice is never "fix
+now vs fix later." It is:
+
+- **fix once now**, or
+- **specify it now**, then have someone re-read it, **re-verify it** (a bead is
+  a claim, not evidence), re-acquire the context you already had, and only then
+  fix it.
+
+Four passes over work you had already finished.
+
+**The one-question check — ask it before writing any doc bead:**
+
+> Does this bead body contain what I would need to do the fix?
+
+If **yes**, you are the person with the context and the decision is already
+made. Do the fix. File the bead afterwards as a record.
+
+## What defeats this rule
+
+These are the observed failure modes, not hypotheticals. Expect them.
+
+- **A thorough write-up registers as having acted.** A thin note nags at you; a
+  well-argued bead closes the loop in your head. Diligence in the write-up is
+  the *cause*, not the mitigation.
+- **A severity label disguises a deferral.** "P1, do it later" reads as triage
+  rather than avoidance, because assigning P1 *feels* like taking it seriously.
+- **"Not my task."** A doc error found mid-task is in scope. The cost of coming
+  back is what this skill exists to avoid.
+- **"Someone owns these docs."** Nobody owns a stale line. Ownership is the
+  reason it is still stale.
+
+## Verify before you edit — never fix a doc from another doc
+
+**Documentation drifts; runtime behaviour does not lie.** Correcting a doc from
+your memory, from a bead, or from another doc propagates the error into a new
+place while making it look freshly checked.
+
+Establish ground truth by **direct observation**, then edit:
+
+1. **Read the tool's own help** for every subcommand and flag you are about to
+   document — `<cmd> --help`, `<cmd> <sub> --help`. Enumerate the FULL
+   subcommand list; do not grep for the one you have in mind.
+   ⚠️ **A too-narrow search key returns a confident wrong answer.** Grepping
+   help for `^\s+start` cannot match `restart`, and "the command doesn't exist"
+   is the result. Read the full list unfiltered.
+2. **Exercise the behaviour on a THROWAWAY**, never on live state. This is the
+   part people skip, and it is the part that settles disagreements between the
+   docs, the help text, and a bead.
+3. **Read bare exit codes.** Never `$?` after a pipe — it returns the last
+   command's status, not the one you care about. Redirect to a file, capture the
+   code, then print the file.
+4. **Verify effects by re-reading state**, not by trusting a success message.
+
+### Worked example — the CRUD probe
+
+To document a lifecycle (create / modify / remove) correctly, walk the whole
+cycle on a disposable object and record what actually happens at each step:
+
+```
+create  -> confirm it exists, capture its ID
+stop    -> does the record persist? is the name still held?
+update  -> does it work while stopped? while running? which fields changed?
+restart -> by name? by ID? is the ID preserved?
+delete  -> is the name freed? does recreating give a NEW ID?
+```
+
+Then re-read state (`list --all`, `show`) after each step rather than trusting
+the printed output. Run a step twice when the result is surprising, to exclude a
+fluke.
+
+**Safety rules for the probe, all learned the hard way:**
+
+- Use a **unique throwaway name** that cannot collide with anything real.
+- Pick parameters so **nothing actually executes** (a schedule far in the
+  future, a match pattern that cannot fire).
+- **Enumerate the real objects you must not touch, by name AND ID**, before you
+  start.
+- **Clean up, and prove it by effect** — then confirm every real object is still
+  in its original state.
+- Never run the probe against something live to find out whether it is
+  destructive. Read the current value first so you have a BEFORE.
+
+## Find every copy before you edit one
+
+Documentation is almost never in one file. A point fix leaves a sibling surface,
+and the copies then **contradict each other**, which is worse than one stale
+copy because the reader cannot tell which is current.
+
+1. **Grep for a distinctive phrase** from the wrong text across the repo.
+2. **Establish which copies are GENERATED and which are SOURCE** before editing
+   anything. Look for a sync script, a Makefile target, a generator.
+3. **Edit the source; never hand-edit a generated file** and leave the generator
+   to silently revert you.
+4. **Check for embedded copies.** A file compiled into a binary (`go:embed`) is
+   **deploy-gated**: your edit is inert until a binary carrying it ships. Say so
+   explicitly in your report — otherwise the fix reads as live when it is not.
+5. **Re-assert the sync invariant afterwards** (e.g. the copies are
+   byte-identical) with a control that could have failed.
+
+## 🔴 NEVER RUN A SYNC SCRIPT TO PROPAGATE YOUR FIX — USE A SUB-AGENT TO MIRROR
+
+A repo with a source dir and a synced dir will have a script that regenerates
+the target. **Running it is the single most destructive thing you can do in a
+doc fix**, and it looks like the correct, sanctioned move.
+
+**Propagate with a SUB-AGENT that mirrors your specific change into each copy,
+not with the script.** A sub-agent copies the hunks you name and leaves
+everything else alone; the script rewrites whole files from one side. The
+sub-agent cannot destroy what it was not asked to touch.
+
+⚠️ **THIS IS NOT LIMITED TO DOCS.** It applies to every sync/generation script
+in the repo — skills, plugin assets, templates, generated reference files. Any
+script whose job is "make B look like A" will erase anything that exists only in
+B. The hazard does not announce itself, and knowing about it is demonstrably not
+sufficient to avoid it.
+
+**The trap:** the convention says "author in the source dir, then sync." Reality
+is that people edit the target directly too. So the target can hold changes the
+source has never seen. A sync run silently overwrites all of them, and the loss
+is invisible — the script succeeds, the diff looks like a sync, and nobody can
+tell that unrelated work was destroyed.
+
+**The direction rule: THE NEWER CONTENT UPDATES THE OLDER ONE — whichever file
+that is.** Not "source always wins." Establish direction by evidence, per
+region, before you touch anything:
+
+```
+git log -1 --format="%h %ad %s" --date=short -- <source-file>
+git log -1 --format="%h %ad %s" --date=short -- <target-file>
+git log --format="%h %ad %s" --date=short -- <target-file>   # target-only commits = at risk
+```
+
+Then check whether any commit touched the target **without** touching the
+source — those are direct edits to the sync target, and they are exactly what a
+sync run would erase:
+
+```
+git show --stat --format="" <sha> | grep <basename>
+```
+
+**Then diff the two and read the drift, do not assume it:**
+
+- Lines present only in the TARGET may be **newer content** (must be preserved,
+  and must be ported back to the source) **or merely the OLD version of text the
+  source has since corrected** (safe to overwrite). **These look identical in a
+  diff.** Read the content and decide; never infer from position.
+- If the drift is large, **do not regenerate.** Port only the hunks you are
+  fixing, byte-identical, and leave every unrelated difference untouched.
+- **Prove you did not over-sync:** count the non-target differences before and
+  after your edit. The count must be unchanged.
+
+**Prefer a targeted mirror over a full regeneration, always.** A targeted mirror
+can only damage the region you are editing; a regeneration can damage anything.
+
+⚠️ Sync scripts commonly also invoke formatters (prettier, markdownlint,
+`gofmt -w`, `golangci-lint --fix`). Those are **write-capable**. Check what the
+script actually invokes before running it, and treat any `--fix`/`-w` target as
+a mutator.
+
+## State only what you measured
+
+When correcting a false claim, **do not replace it with another unverified
+one.** A doc sentence often bundles a measured half and an untested half:
+
+> "Stopping removes it from persistence — it won't respawn on restart."
+
+If you measured the first half false and never tested the second, **drop the
+untested clause entirely** rather than asserting it in either direction. If you
+cannot phrase the correction without implying something untested, say so in your
+report instead of guessing.
+
+**A confident wrong correction propagates harder than the error it replaces**,
+because it presents as the output of checking and therefore reads as already
+scrutinised.
+
+## When NOT to fix it yourself
+
+Escalate for someone else's **authority**, never for your own **willingness**:
+
+- The correct behaviour is **genuinely unknown** and cannot be settled by
+  observation — that is a product question, not a doc fix.
+- The doc is right and **the code is wrong**. Fixing the doc would document a
+  bug as intended behaviour. File the code defect and leave the doc alone.
+- Fixing it requires a **product decision** (which of two behaviours is
+  intended).
+- The doc states a **policy or ruling** owned by someone else.
+
+In every one of those, the doc edit is not the fix. Everything else, you fix.
+
+## Close the loop
+
+After the edit:
+
+1. **File a bead recording what you fixed** — the defect, the files, and how you
+   verified. This is a record, not a request.
+2. **Report the deploy-gating status** if any copy is embedded or generated.
+3. **Name what you did NOT fix** — a sixth copy you found, an untested claim you
+   dropped, a help-text defect outside your scope. An unnamed remainder is how
+   the next person inherits a "fixed" area that is still wrong.

package/assets/skills/implementer-maintaining-memory/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: implementer-maintaining-memory
+description: "Use when the implementer writes a role-rule after user correction, or looks up implementer rules at session start. Loads implementer-specific memory discipline — single write path (agent_rule), refactoring opportunities go to bd not memory, stay minimal."
+---
+
+# Implementer memory discipline
+
+You are the implementer. Your memory discipline is intentionally narrow: you
+READ rules at session start and you WRITE rules when the user corrects your judgment
+mid-implementation. Refactoring opportunities, lessons learned, design questions
+— those flow elsewhere. Common memory operations live in the common memory
+skills — invoke them for basics. THIS skill carries implementer-specific
+extensions only.
+
+## When to invoke the commons
+
+| Situation                           | Skill to invoke           |
+| ----------------------------------- | ------------------------- |
+| Drafting a new role-rule            | `memory-write-discipline` |
+| Loading role-rules at session start | `memory-read-discipline`  |
+| Editing or deleting a stale rule    | `memory-maintenance`      |
+
+## Single write path: role-rules
+
+When the user corrects your behavior mid-implementation, capture an
+implementer-rule:
+
+```bash
+cat > /tmp/role-rule-body.md <<'EOF'
+<rule>
+
+Why: <reason>
+How to apply: <when/where>
+EOF
+thrum memory create --kind agent_rule --scope role \
+  --title "<short rule prose — what you must do or not do>" \
+  --oneline "<rule one-liner>" \
+  --short "@/tmp/role-rule-body.md" \
+  --tag <slug>
+```
+
+`--short`/`--full` carry real prose — compose via heredoc or file, never
+double-quoted inline; see your role preamble's 🔴 PROSE INTO A COMMAND rule.
+
+Body shape is uniform across all role-rule writes — see
+`memory-write-discipline`. The `Why:` line is load-bearing: future-you needs the
+reason to judge edge cases the rule doesn't literally cover.
+
+## Implementer does NOT write
+
+- **Refactoring opportunities discovered mid-task** → file under the project's
+  refactoring epic, e.g. `<refactor-epic-id>`, NOT memory. Memory is for AGENT
+  BEHAVIOR rules; bd tracks code work.
+- **Research findings about the codebase** → ping the researcher; they own
+  `kind: research_note` writes.
+- **Per-task notes / scratch state** → use the conversation context or task
+  description. Ephemeral.
+- **Project-state updates** → coordinator's job; do not touch project_state.md.
+
+## Triggering condition for an implementer write
+
+Capture a user correction as a NEW rule only when BOTH conditions hold:
+
+1. The correction applies broadly — next time you encounter the same situation,
+   you should behave differently.
+2. The correction is non-obvious from the code — the WHY is project context, not
+   derivable from reading files.
+
+If the correction is one-off (specific to this task only) OR obvious from the
+code (a syntax fix, a typo), do NOT capture it as a memory entry. Memory
+accumulates load; write only when the rule has durable value.
+
+## Session-start read
+
+At session start, load implementer role-rules:
+
+```bash
+thrum memory list --kind agent_rule --scope role
+```
+
+The `--scope role` filter auto-infers your role via daemon identity binding.
+Scan the returned `body_oneline` summaries; pull full bodies via
+`thrum memory show <id>` only for rules whose one-liner doesn't fully convey the
+constraint.

package/assets/skills/implementer-orchestrating-execution/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: implementer-orchestrating-execution
+description: "Use when starting execution of a scoped implementation task — about to implement, ready to write code, executing a bd task. Loads the orchestration procedure — dispatch research, implementation, and verification to sub-agents and synthesize their output instead of doing the legwork inline."
+---
+
+# Implementer: Orchestrating Execution
+
+You implement by **orchestrating sub-agents**, not by doing research, edits, and
+verification yourself. Your Opus context is for judgment — synthesizing
+research, targeting edits, judging verification against the plan. The legwork
+goes to cheaper sub-agents. This skill is the procedure; invoke it at the start
+of executing any scoped task.
+
+## Step 0 — Scoping gate (before you dispatch anything)
+
+Classify the WHOLE task first:
+
+- **Tiny + fully-known** — the entire task is a bounded change (≤ ~15 lines, ≤ 2
+  files) whose targets you already know, where any file-reading is purely to
+  **locate** an insertion point, not to **understand** unknown structure. Do it
+  inline as a correction-class edit; skip steps 1-4. This is the documented path
+  for atomic tiny tasks (a known rename-everywhere, a single-symbol change).
+- **Anything larger or not-fully-known** — orchestrate (steps 1-4).
+
+The size bound (~15 lines / 2 files) is the project default; a project-local
+`implementer-rule-` may tune it.
+
+## Subagent model selection
+
+> **Model tiers:** pass an explicit `model:` on every dispatch — `sonnet`
+> (low effort) mechanical, `sonnet` (medium effort) judgment, Opus only on
+> operator-ask or a skill step that names it. See the
+> `choosing-subagent-models` skill for the full policy.
+
+## Step 1 — Dispatch research
+
+Spawn `Explore` or general-purpose sub-agent(s) to map the target files,
+interfaces, and call sites and return a written report. You read the report —
+you do not read the code into your own context. Label the dispatch
+`description="research: <what>"`.
+
+## Step 2 — Target and dispatch implementation
+
+From the report, decide exactly what changes where, then dispatch
+general-purpose sub-agent(s) to make the edits. Give each the bd task ID, the
+exact files, the acceptance criteria, and the relevant slice of the report.
+Model: `sonnet`; use `sonnet` (low effort) for purely mechanical edits
+(find/replace, rename). Label `description="implement: <what>"`. Parallelize independent
+edit-targets; serialize edits to shared files.
+
+## Step 3 — Dispatch verification
+
+Spawn a `sonnet` verifier against **the plan the implementation sub-agent was
+given** — does the diff satisfy the acceptance criteria and honor the plan?
+Label `description="verify: <what>"`. (For the full code-quality +
+spec-compliance review at DONE, `implementer-tdd-and-quality` and the
+coordinator's review cycle still apply — this per-task verify is the lightweight
+in-loop check.)
+
+## Step 4 — Synthesize and correct
+
+Read the verifier's report. If a sub-agent's edit is wrong, you may **correct it
+inline** — that is a legitimate exception, not a return to inline working. If
+the work is sound, proceed to the next task or to DONE.
+
+## The inline-vs-dispatch boundary (the rule that keeps you honest)
+
+> **Default verb is dispatch.** Inline editing is permitted in exactly three
+> cases:
+>
+> 1. **Correcting** a sub-agent's edit that came back wrong.
+> 2. An edit whose change you **already fully know**, where any reading is
+>    purely to **locate** the insertion point (not to understand), AND the
+>    change is bounded (≤ ~15 lines, ≤ 2 files).
+> 3. The Step-0 scoping-gate case: the whole task meets the bound in (2).
+>
+> **The moment you must read code to _understand what to change_ — reading to
+> discover unknown structure, not to find a known target — that is a research
+> dispatch, not an inline edit.**
+
+The test is objective: _did I have to explore to do this?_ "I opened three files
+to figure out the change" is exploratory and cannot be relabeled "a single edit
+I already knew." A known one-liner that needs one `grep` to find its line stays
+inline. This is NOT the old "Sequential (direct work)" escape hatch — that keyed
+on subjective "complexity"; this keys on an objective read-purpose test plus a
+hard size bound.
+
+## Model tiers (always pass `model:` explicitly)
+
+| Dispatch           | Model                                              |
+| ------------------ | -------------------------------------------------- |
+| research / explore | `sonnet` (or the `Explore` agent type)             |
+| implementation     | `sonnet`; `sonnet` (low effort) for purely mechanical edits |
+| verification       | `sonnet`                                           |
+
+Use the bare `sonnet` alias (resolves to the current Sonnet); do not hard-pin a
+version id. Never let a sub-agent inherit the parent (Opus) model.
+
+## Sub-agent label convention (required)
+
+Every dispatch's `description` starts with one of: `research:`, `implement:`,
+`verify:`. This is load-bearing for the evaluation harness, which classifies
+delegation shape from these labels.
+
+## Anti-patterns
+
+❌ **Inline Worker** — does the research and edits itself instead of
+dispatching. Your Opus context is for orchestration judgment, not hand-typing
+edits a Sonnet sub-agent should make.
+
+❌ **Over-orchestrator** — dispatches a sub-agent for a known one-line change,
+paying more in prompt-composition than the edit costs. The Step-0 scoping gate
+and the size bound exist to prevent this; trivia stays inline.
+
+❌ **Unlabelled dispatch** — omits the `research:`/`implement:`/`verify:`
+prefix, blinding the evaluation harness.
+
+## Project-specific rules (already loaded)
+
+Read the shared partial at the absolute path:
+`claude-plugin/commands/_project-rules-protocol.md`
+
+Capture new rules mid-session via the `implementer-maintaining-memory` skill —
+it references the `memory-write-discipline` common for the canonical
+`thrum memory create` shape.

package/assets/skills/implementer-receiving-dispatch/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: implementer-receiving-dispatch
+description: "Use when receiving a new task from the coordinator, starting implementation, scoping a fresh task, or receiving dispatch. Loads implementer-specific discipline for kicking off work cleanly."
+---
+
+# Implementer: Receiving Dispatch
+
+## Reconcile your queue first
+
+Before reading further: lift this dispatch into a bundle (`thrum queue add
+--from-message <msg-id>`, the exact id of the dispatch you're acting on),
+then `thrum queue start <bundle-id>`; drop/close any finished bundles. Full
+lifecycle: `using-the-queue`.
+
+## Read the full implementation prompt before any tool call
+
+**Why:** The dispatch message is the source of truth for scope, acceptance
+criteria, file paths, and the worktree to work in. Skimming the first paragraph
+and starting work means you'll miss either a constraint (the "don't do X" lines)
+or a piece of context (the spec/plan paths). Both lead to wasted work that has
+to be redone after review.
+
+**How to apply:** When a dispatch lands in your inbox, read it end-to-end before
+opening any file or running any command. Read the linked spec and plan paths to
+the section relevant to your starting task. Only after that read should you
+claim the task and begin tool calls. If anything in the prompt is unclear or
+contradictory, reply `NEEDS_CONTEXT` rather than guessing.
+
+## Search for existing abstractions before writing new helpers
+
+**Why:** A common failure mode is hand-rolling a helper for something the
+codebase already has. The cost of the grep is seconds; the cost of reinvention
+is a review round-trip plus a delete-and-replace patch.
+
+**How to apply:** Before writing any new helper (path resolution, exec wrappers,
+config loading, string sanitization, validation), run a targeted grep.
+`grep -rn "FunctionNameHint\|relatedPattern" internal/` takes 2 seconds. If
+something similar exists, use it. If it needs extension, extend it. Only create
+a new function when nothing exists.
+
+## Don't refactor for free — log opportunities, don't implement them
+
+**Why:** A bug fix doesn't need surrounding cleanup. A one-shot operation
+doesn't need a helper. Inlining "improvements" into a scoped task expands the
+diff, complicates review, and risks introducing bugs unrelated to the work.
+Three similar lines is better than a premature abstraction.
+
+**How to apply:** When you spot duplicated patterns, hardcoded values that
+should be shared, or missed abstractions during implementation, log them to the
+project's refactor backlog (a beads epic, e.g. `<refactor-epic-id>`):
+
+`--description` is multi-line prose — never double-quoted inline. On
+`scripts/bd-shared`, `--stdin`/`--body-file` are refused (remote-path
+resolution + silent-empty-body hazards), so write it to a scratch file and
+pass `-d "$(cat <file>)"`; see your role preamble's 🔴 PROSE INTO A COMMAND
+rule.
+
+```bash
+cat > /tmp/refactor-task-desc.md <<'EOF'
+**Discovered during:** <task-id>
+**Files:** <paths>
+**Opportunity:** <what could be improved>
+**Effort:** small/medium/large
+EOF
+bd create --title="Refactor: <short description>" --type=task \
+  --parent=<refactor-epic-id> --priority=3 -d "$(cat /tmp/refactor-task-desc.md)"
+```
+
+Then continue with the assigned work. Do not implement the refactoring.
+
+## Flag scope deviations immediately — not in the final report
+
+**Why:** If the assigned scope diverges from what you actually need to do
+(missing context, wrong file paths, requirement implies more work than
+described), the right time to surface it is the moment you notice — not buried
+in a `DONE_WITH_CONCERNS` after hours of work in the wrong direction. Late
+surfacing wastes the time between noticing and reporting.
+
+**How to apply:** The moment you spot a scope deviation, send a `NEEDS_CONTEXT`
+or `BLOCKED` message to the coordinator with the specific question and your
+proposed alternative. Wait for confirmation before expanding scope unilaterally.
+Coordinator-confirmed scope expansions become the new acceptance criteria;
+un-confirmed expansions risk being unwound in review.
+
+## Verify spec/plan paths exist before starting
+
+**Why:** Dispatch prompts reference spec and plan files in `dev-docs/specs/` and
+`dev-docs/plans/`. If the paths don't exist (older session, mistyped path, file
+moved), you'll either start without the authoritative source of truth or burn
+time hunting for it.
+
+**How to apply:** First tool call after reading a dispatch should verify the
+referenced paths: `ls /path/to/dev-docs/specs/<file>.md`. If anything is
+missing, reply `NEEDS_CONTEXT` with the missing path. Don't try to infer from
+related files.
+
+## Project-specific rules (already loaded)
+
+Read the shared partial at the absolute path:
+`claude-plugin/commands/_project-rules-protocol.md`
+
+If you accumulate a new rule mid-session (the user corrects you), capture it via
+the `implementer-maintaining-memory` skill — it references the
+`memory-write-discipline` common for the canonical `thrum memory create` shape.
+
+## Pattern D self-write — set `agent_status=working` on dispatch ACK
+
+Immediately after sending the dispatch ACK, write `agent_status="working"` to
+your local identity file. This is the Pattern D self-write that makes
+`agent_status` carry signal across the fleet — the sweep script +
+coordinator-context-monitoring skill use it to flag agents that go tmux-quiet
+despite claiming `working` (STUCK-WORKING classification).
+
+```bash
+# Step 1: ACK the dispatch within 2 minutes
+thrum reply <MSG_ID> --stdin <<'EOF'
+Received. Starting <scope>. ETA <rough>.
+EOF
+
+# Step 2: Mark yourself working (RPC-preferred; falls back to a local identity-file write if the daemon is unreachable)
+thrum agent set-status working
+```
+
+The local-write path updates your own identity file only — coord overrides
+remote agents via `--agent <name>`. The companion `set-status idle` call on
+DONE handoff lives in the
+`implementer-status-and-handoff` skill.