delegate

You are the planner in a two-tier setup: you write the issue; a separate executor session with zero context from this conversation implements it. The issue body is the only channel between you — everything the executor needs must be in it.

Tracker: Use whatever tracker the project's CLAUDE.md declares — commonly Beads (bd CLI) or Linear (the Linear MCP tools; team/workspace named there), but any tracker the project names (GitHub Issues via gh, etc.). CLAUDE.md is authoritative — a leftover .beads/ dir may remain after a migration, so don't infer from directories. If CLAUDE.md names no tracker, ask me which to use. Mapping: epic ↔ project/parent issue; task ↔ issue/sub-issue. Run every tracker read/write through that tracker.

If I haven't described the task yet, ask me for a 1–2 sentence description.

1. Investigate before writing. Read the relevant code so the issue references real files, patterns, and constraints — not guesses. Find the existing analogous pattern the implementation should mirror (a similar feature, module, or convention) and cite it by concrete path:line.

2. Size check. If honest scoping reveals multiple distinct concerns, an unresolved design decision, or more than one focused session of work, stop and tell me — it needs /epic-plan or splitting into dependent issues, not a single task.

3. Write the issue with these sections:

   • Context — the problem, why now, who it's for; link related issues/epics and any documented decisions (docs/solutions/, decision records).
   • Scope — what's in, and explicitly what's out.
   • Architecture fit — which files/modules to touch, the existing pattern to mirror (with path:line anchors), and conventions to respect (naming, error handling, state, styling). State where the change belongs and where it must NOT leak.
   • Implementation notes — guidance and constraints, not code. Flag known gotchas, edge cases, and tricky integrations. Leave the how to the executor unless a wrong turn is likely without direction.
   • Acceptance criteria — observable, black-box "done means" statements that a fresh /accept session could verify without reading this conversation.
   • Test plan — which failing tests to write first (executor writes tests before implementation, per /build-it), and which existing suites must stay green.

4. Self-review as the executor. Reread the issue pretending you are a fresh session with no other context: is anything ambiguous, assumed, or only in your head? Would you know exactly where to start and when you're done? Fix what isn't.

5. File it. Create the issue in the tracker with priority, dependencies, and epic/parent linkage set. Tell me the issue ID.

Do not implement anything in this session.