--- name: plan-todo-implementer description: Implement plan-todo artifacts with bounded writer subagents, parent-owned review, and a final integrated audit and cleanup before completion. disable-model-invocation: true --- # Orchestrated plan implementation Implement the complete handoff produced by `plan-todo`: - `.selesai/tasks/plan.md`: authoritative context, decisions, and plan-wide acceptance. - `.selesai/tasks/todo.md`: task IDs, ownership, dependencies, and task-level gates. You are the orchestrator. Writer subagents edit implementation files. You dispatch them, review every result, keep both artifacts current, and own final acceptance. During the final integrated audit, you may make small, in-scope cleanup fixes yourself as described in section 5. Do not spawn reviewer subagents. Load and follow `pi-subagents` for delegation authorization, launch mechanics, isolation, and async lifecycle. This skill supplies execution guidance, not delegation authorization. ## 1. Set up the run Read both artifacts completely and inspect the working tree (status, branch, HEAD). Use an explicitly supplied task directory instead of the default. **Writer model and effort.** The user must specify both for this run. Ask for any missing value. Do not infer them from defaults, the parent model, or earlier runs. Verify that the exact model ID exists and supports the effort, then launch every writer with `model: "/:"`. Never substitute a value. **Writer agent and tools.** Use the builtin `worker` unless the user names another agent. Run `subagent({ action: "list", options: { capabilities: true } })` and record the writer's resolved tool list. That list is what the writer gets; your own tools do not carry over. With the bundled extensions, the builtin `worker` adds `sai_find`, `ask_sai`, `codemode`, `memory_search`, `session_search`, `web_explore`, and `grep_app_*` to its core tools. A user or project override of `worker` can remove these, so trust the listed tools, not this paragraph. In the brief, name the tools that suit the task, for example "use sai_find or grep to locate callers before editing". When a task needs a search the writer cannot run, run it yourself and put the results in the brief as reading leads. **Subagent access.** Call `subagent` the way this session exposes it, normally `tools.subagent(...)` inside codemode. If a ```` ```js workflow ```` block cannot reach it, save the script to a file and pass `workflow: ""`. **Board.** Classify every todo ID as done, ready, or blocked. Older plans can contain discovery tasks that feed only one downstream task, or exploration tasks that name no questions. Run each of these with its downstream task as one assignment that explores and then implements, and record that change in `todo.md`. Verify each existing completion claim against the tree before you rely on it. For each blocked task, name the prerequisite or decision that blocks it. Resolve scope or contract questions with the user; do not invent agreements. Preserve unrelated work in the tree. **Done:** every todo ID is classified, the writer model, effort, agent, and tool list are recorded, and ownership boundaries between ready tasks are clear. ## 2. Know what each writer knows Choose the launch mode first. Then write the prompt for that mode. | Mode | What the writer already knows | How to write the prompt | | --- | --- | --- | | fresh (`context: "fresh"`) | Only the prompt, project context files such as AGENTS.md, and files it reads. Nothing from your session or from other writers. | A complete, standalone brief. | | resume (`resume: ""`) | Its own earlier transcript in this lane: its task, edits, and report. Nothing that happened after it returned. | A delta: your verdict, what changed since, and the next assignment. | | fork (`context: "fork"`) | Your whole session, including this skill and your orchestrator role. | Do not use for writers. | Rules for every prompt: - In a fresh prompt, do not write "as discussed", "continue", "your previous work", "the earlier finding", or "you already know". The writer has no such memory. State the fact and where it is recorded. - Another writer's output is not this writer's memory. Pass accepted results as facts with their source, for example "plan.md, Findings and decisions, records that X". Do not paste unaccepted output from another lane. - In a resume prompt, refer back only to work in that writer's own transcript. State everything that happened after it returned. - A resumed writer keeps its stored agent, model, and tools. If the model, tools, cwd, or role must change, start a fresh writer. The one exception is explore, then implement, in section 3. - Write complete sentences. Do not compress words, drop spaces, or use private abbreviations. A smaller writer model must understand the prompt without guessing. - Before you send a prompt, reread it as the writer will see it. Every reference to earlier work must be in the writer's transcript or restated in the prompt. ## 3. Dispatch ready tasks Use a rolling ready queue, not whole-wave barriers. Launch every ready task whose ownership does not conflict, up to safe capacity, provider limits, and any user budget. Do not create artificial tasks to raise agent count. If ready work stays queued, record the reason. - Give each assignment exactly one todo task or one bounded subtask of it. - Launch a dependent task only after you accept its prerequisites, as a new launch from you. Do not chain dependent tasks inside one workflow script. Do not tell a writer to wait through `contact_supervisor` until you accept another task. - Concurrent mutation lanes need separate worktrees or cwds with exclusive file ownership, including generated files and test artifacts; follow `pi-subagents` multi-lane guidance. A lane must contain its accepted prerequisite changes. Serialize shared contracts or route them through the integration owner. Schedule heavy validation so lanes do not starve each other. - Split an oversized task at independently checkable boundaries instead of sending it whole. **Fresh or resume.** - To correct an unaccepted result, resume the writer that produced it. - For the next dependent task, you may resume the same writer when the task uses the same files, cwd, model, and role, status reports the run resumable, and the lane has handled at most two follow-up assignments without context compaction. Always use the latest returned run ID. - Explore, then implement: when a discovery task feeds exactly one downstream task and that task edits the files the discovery read, resume the discovery writer for the downstream task after you accept its findings. Its transcript keeps what it read. This is the one allowed role change. It counts as one follow-up assignment. - In every other case, start a fresh writer. Record why. **Fresh brief.** Include these parts in this order: 1. Role and boundary: "You are the writer for task T0N only." Repository, cwd, branch and ref, files the writer may edit, and files it must not edit. 2. Context: the absolute path of `plan.md`, with an instruction to read it fully and read-only before editing. Then the reading leads you collected, as `path:symbol` with one line on why each matters. 3. The task: Action, Scope, Acceptance, and Validation copied from `todo.md`, plus any clarification you made. 4. Accepted prerequisites: the facts, interfaces, and file changes this task builds on, each with where it is recorded. Give the absolute path of each accepted findings file the task depends on, and tell the writer to read it before editing. Do not retype its contents. 5. Rules: `plan.md`, `todo.md`, and other `.selesai/tasks/` files are read-only for writers. One exception: a discovery writer writes its answers to `.selesai/tasks/findings/T0N.md`, named for its own task ID, in the format that `todo.md` gives. No nested delegation, commits, or scope expansion. If blocked or a decision is needed, use `contact_supervisor` with `need_decision` or stop and report. Do not guess. 6. The report contract from `todo.md`, including its Plan updates section. Do not include other tasks from the backlog. If `plan.md` is not readable from the writer's cwd, paste it in full; if it cannot fit, report the blocker. **Resume brief.** Include these parts in this order: 1. Your verdict on its last result: accepted, or the specific findings it must fix, with evidence. 2. What changed after it returned: accepted work from other lanes that touches its area, edits to `plan.md` or `todo.md`, and user decisions. If nothing changed, say so. 3. The new assignment, using parts 3 to 6 of the fresh brief. State that it replaces the earlier assignment, and tell the writer to reread `plan.md` if it changed. **Done:** useful ready work runs up to safe capacity, each writer has one bounded assignment with satisfied prerequisites, and each queued ready task has a recorded reason. ## 4. Review, accept, and update the artifacts Review each result yourself. Read the diff, check it against the task acceptance and plan constraints, and inspect or rerun the validation. A success claim is not acceptance. Send blocking findings back to the same writer as a bounded correction. If corrections stop making progress, record the blocker instead of retrying. If a writer times out or fails, inspect and checkpoint its partial diff and any surviving processes, then continue under the same protocol and model. Do not change execution mode without the user's approval. After you accept a result, update the artifacts before you dispatch any task that depends on it. Only you edit them; writers propose changes in their report. - `todo.md`: check the box and add a `Result:` line under the task with changed files, validation evidence, and the run ID. For a blocked task, add a `Status: blocked` line with the reason and next action. - `plan.md`: add accepted findings, decisions, and interface changes to the `Findings and decisions` section; create it at the end if missing. Correct each statement elsewhere in `plan.md` that the result disproves, and remove open or proposed labels that it resolves. - Downstream tasks: rewrite the Action, Scope, Acceptance, or Validation of each task that the result changes. Add a task with a new ID when the result shows needed work inside the agreed scope that no task covers. Record work outside the agreed scope as a user decision; do not add it as a task. - A discovery task is accepted only when its findings file answers every question it names with evidence you checked, `plan.md` links that file under `Findings and decisions` with a one-line summary, and the dependent tasks are refined and list the file in their reading leads. Correct the findings file yourself if a check disproves part of it. If the writer reported findings without writing the file, resume it to write the file. - Keep run IDs and lane state in `todo.md`, not in `plan.md`. Then recompute readiness and refill lanes at once. Do not wait for unrelated lanes. When only async work remains, record what will wake you and yield; an async launch is not completion of the plan. **Done:** every returned result is accepted or has concrete findings, both artifacts reflect it, and downstream tasks match what is now known. ## 5. Audit the integrated result, clean up, and close After the designated integration work has landed and no writer is still changing the audit workspace, perform this final pass yourself. Per-task acceptance does not replace it: individually plausible changes can still leave missing wiring, duplicated logic, or broken assumptions when combined. Writer reports and checked boxes are claims to verify, not proof of completion. 1. **Recheck the actual implementation.** Reread the agreed outcomes and constraints in `plan.md` and the task results in `todo.md`. Inspect the task-related integrated diff and surrounding source, not just reports or isolated lane diffs. Trace the requested behavior end to end through its callers, interfaces, configuration, packaging, and documentation where relevant. Confirm claimed files, symbols, tests, and behavior actually exist and satisfy the agreed requirements. 2. **Check the seams between tasks.** Look for missing registration or call sites, incompatible interfaces, duplicate helpers, stale references, unsupported assumptions, and unrelated changes. Check that validation exercises the combined behavior, not only each component in isolation. 3. **Clean up within scope.** You may directly make small, local cleanup fixes in the integrated workspace, such as reusing an existing helper or correcting a stale reference. This is a narrow exception to writer-owned implementation, not permission to take over unfinished tasks, redesign the solution, or expand scope. Preserve pre-existing user work. Send substantial corrections to writers under the existing protocol, then repeat the integrated audit on their changes. 4. **Verify after the last edit.** Independently run the relevant checks against the final integrated tree and verify every plan-wide acceptance and validation gate. Add a focused regression check when a fix exposes missing coverage. Earlier lane results do not establish that the combined result or later cleanup passes. Record checks you cannot run and why; do not treat them as passing. 5. **Record the final evidence.** Add a final audit result to `todo.md`: findings and their disposition, cleanup files, commands and outcomes, and remaining blockers or unverified gates. Reopen any task whose acceptance the audit disproves and keep both artifacts consistent with the final state. Do not weaken acceptance criteria merely to match what writers delivered. **Done:** every todo ID is accepted, the final parent audit is complete, and the plan-wide gates pass, or unresolved tasks and gates are explicitly blocked with their reasons and next actions. `plan.md` describes the final state. Report completed IDs, audit and cleanup results, integrated validation evidence, and remaining blockers. Do not claim the plan is implemented because individual writers finished.