---
name: plan-todo
description: Write a delegation-ready plan and atomic task checklist in .selesai/tasks/.
disable-model-invocation: true
---

# Delegation-ready plan and todo

Produce two artifacts at the repository root:
- `.selesai/tasks/plan.md`: the authoritative PRD and handoff context.
- `.selesai/tasks/todo.md`: executable assignments referencing that context.

Plan only. Writing these files does not authorize implementation, delegation, live API calls, or editing user configuration.

## 1. Establish the handoff boundary

Inspect existing target files and the working tree before writing. For the requested change, locate behavior, callers, configuration, tests, packaging, and documentation. Verify source pointers against current files. Capture user agreements separately from proposals and unknowns; ask only about decisions that block a useful plan. If a few reads can answer a question now, answer it in plan.md instead of creating a discovery task.

If the repository root is ambiguous, resolve it before choosing output paths. If existing artifacts describe different work, ask before replacing them. Preserve unrelated edits and untracked files.

**Done:** every affected subsystem has a verified reading lead, and every unresolved decision is labeled with its owner or next evidence-gathering action.

## 2. Write plan.md as the source of truth

Keep these sections, omitting sections that genuinely do not apply:

1. **Outcome and agreements:** problem, requested behavior, fixed names/contracts, scope, non-goals, and compatibility/removal policy.
2. **Current context:** behavior to preserve, exact source paths/symbols, relevant architecture, constraints, and work already present in the tree.
3. **Proposed design:** ownership boundaries, changed interfaces/data flow, risks, and explicit decisions still open. Do not promote a suggestion into a user agreement.
4. **Acceptance and validation:** observable success/failure conditions; exact known commands; checks requiring credentials, spending, permissions, or external evidence. Label unverified commands rather than inventing them.
5. **Handoff:** reading order, integration owner, shared-file rules, and evidence each worker must return.
6. **Findings and decisions:** write `None yet.` The implementer records accepted discovery results, decisions, and interface changes here during execution. A discovery result is recorded as a one-line summary and a link to its findings file.

Include enough context that an executor needs no chat history, but still must inspect authoritative source. Do not paste entire source files or repeat task-level instructions here.

**Done:** a fresh executor can identify the outcome, constraints, affected systems, and release gates without guessing; each factual claim has source evidence or an uncertainty label.

## 3. Write todo.md as atomic assignments

Give tasks stable IDs (`T01`, `T02`, …) and unchecked boxes. Each task records:

- **Action:** one independently checkable result, not a vague phase such as “implement the refactor.”
- **Scope:** owned files/modules and relevant reading leads.
- **Dependencies:** prerequisite IDs, or `none`.
- **Acceptance:** a binary, observable completion condition.
- **Validation:** command or inspection proving that condition.

Split tasks that combine separately verifiable results or unrelated ownership boundaries. Do not split a coherent edit into mechanical keystrokes.

Each task is executed by an agent with an isolated context. What one agent reads is lost to the next unless it is written down, so do not plan exploration as a task by default:
- Put the exploration a task needs into that task. Start its Action with the facts to confirm before editing, each with a reading lead, and the stop condition, for example “Confirm that X holds at `path:symbol`. If it does not, stop and report.”
- Create a separate discovery task only when its answers change the plan itself (which tasks exist, an interface, or a user decision), or feed two or more downstream tasks in different lanes. Do not create discovery tasks such as “explore A”, “explore B”, and “explore C”.

A discovery task must name the questions it answers and the downstream task IDs its findings refine, not merely “understand the code.” Its output is the file `.selesai/tasks/findings/T0N.md`, named for its own ID. For each question, the file gives the answer with `path:line` evidence. For each downstream task, it gives reading leads. Its acceptance is that file, checked by the implementer and linked from plan.md under Findings and decisions. Mark each downstream task that depends on those answers as provisional until that discovery task is accepted, and add the findings file to its reading leads.

Do not add tasks for execution mechanics, such as choosing the writer model, building a lane board, creating worktrees, or launching writers. The implementer owns those.

Organize dependency waves. Parallelize only disjoint ownership; assign shared manifests/configuration and final integration to one owner. A move/rename must land before tasks using the new paths. Keep implementation tasks blocked behind unresolved contract decisions.

Reference plan.md for shared requirements instead of copying them. Each task is assigned with only plan.md, its own entry, and the findings files of its accepted prerequisites, so give each task its own reading leads. Add this worker report contract once: task IDs, changed files, acceptance evidence, validation results, blockers, downstream interface changes, and plan updates (findings, needed decisions, and proposed corrections to plan.md or downstream tasks).

Both files stay current during execution: the implementer checks boxes, adds `Result:` or `Status:` lines under tasks, refines provisional tasks, and fills Findings and decisions.

**Done:** every task has scope, prerequisites, acceptance, and validation; every plan acceptance condition is covered; no parallel assignments require concurrent edits to the same file.

## 4. Audit the pair and stop

Read both files as if the conversation were unavailable. Check paths, task IDs/dependencies, interface names, ownership conflicts, preservation of existing work, and consistency with user agreements. Remove duplicated requirements, speculative design presented as fact, stale context, and instructions that add no task-specific behavior.

Use proportional detail: enough to execute an assigned task, not a transcript or encyclopedic PRD. Keep rationale in plan.md and task mechanics in todo.md so each meaning has one authoritative home.

When relocating an existing pair from `tasks/`, compare destination contents first. Move only the requested files if the destination is absent or identical; otherwise ask before overwriting. Leave unrelated task documents untouched and update active references to the new paths.

**Done:** both artifacts exist at `.selesai/tasks/plan.md` and `.selesai/tasks/todo.md`, links/dependencies resolve, and each task can be assigned by ID with these two files. Report the paths and blockers; do not start implementation.