--- name: plan-todo-implementer description: Implement plan-todo artifacts through parallel independent lanes, retained writer continuations, and parent-owned review. disable-model-invocation: true --- # Orchestrated plan implementation Implement the complete handoff produced by `plan-todo`: - `.selesai/tasks/plan.md`: authoritative context and plan-wide acceptance. - `.selesai/tasks/todo.md`: task IDs, ownership, dependencies, and task-level gates. One task per writer assignment, not one task per run or one writer globally. The parent orchestrates the whole backlog and reviews results; subagents write implementation code. Do not spawn reviewer subagents. Load and follow `pi-subagents` for delegation authorization, launch mechanics, parallelism, isolation, and async lifecycle. This skill supplies execution guidance, not delegation authorization. ## 1. Establish the execution contract Read both artifacts completely and inspect the current working tree. Use an explicitly supplied task directory instead of the default when provided. Require an explicitly user-specified writer model and reasoning effort for this run. If either is unspecified, ask the user for the missing value before launching writers. Do not infer these values from configured defaults or the parent model, and do not silently substitute unsupported values. Build a task board from all todo IDs: accepted, ready, blocked, or active. Record dependencies, file/interface ownership, lane cwd/ref, latest child run ID, and the gate that makes the next assignment ready. Group related dependent tasks into continuation lanes, not one issue-wide writer assignment. Verify existing completion claims before treating them as prerequisites. Resolve blocking scope or contract decisions in the parent without inventing user agreements. Preserve unrelated work. **Done:** every todo ID is accounted for, independent lanes and ownership boundaries are understood, and writer configuration is resolved. ## 2. Dispatch ready assignments Use a rolling ready queue, not whole-wave barriers. Launch as many useful, independent ready assignments in parallel as safely fit the configured capacity, provider limits, resource availability, and any user budget. Do not default to one writer or impose an arbitrary small fanout cap. Do not create duplicate or artificial tasks just to increase agent count. If ready work stays queued, record the concrete constraint or conflict preventing dispatch. Respect the plan's shared-file and integration ownership. Follow `pi-subagents` for execution shapes and isolation: concurrent mutation lanes need separate worktrees/cwds with exclusive ownership, including generated files and test artifacts. An isolated lane must include its accepted prerequisite changes; branching from stale HEAD is not enough. Serialize shared contracts or route them through the designated integration owner. Avoid heavy validation oversubscription; schedule tests so resource contention does not erase the benefit of parallelism. Split oversized assignments at independently checkable boundaries rather than sending the whole implementation to one writer. ### Writer continuity Start each new lane with fresh context. After the parent accepts an assignment, prefer resuming that lane's eligible retained writer for a closely related dependent task in the same ownership boundary. Preserve the requested model and reasoning effort. Check resumability and use the latest returned run ID under `pi-subagents` continuation rules; never steer a completed child as if it were live. Give the continuation only its next bounded assignment and accepted prerequisite results, not the rest of the backlog. A writer cannot self-accept or advance to the next task while the parent is reviewing it. Reuse is a preference for useful context and possible prompt-cache savings, not a guarantee of cache hits. Start a fresh writer when retention is unavailable, the role/ownership or workspace has changed incompatibly, or accumulated context would compromise focus. Record the reason; never silently change model/effort or bypass launch-failure recovery rules. Keep the full plan available read-only; for a continuation, supply its current version or reaffirm the unchanged version already supplied, plus any accepted updates. Give each new writer a self-contained handoff, and each continuation an updated handoff, containing: - Repository/cwd/ref and allowed edit boundary. - Full read-only `plan.md`. - Only its assigned todo task or bounded subtask, including its ID. - Required source leads and accepted prerequisite/interface results. - Concrete actions where the parent needed to clarify the task. - Acceptance criteria, validation, and the report contract from `todo.md`. Do not pass the remaining actionable backlog. Tell writers to keep task source documents read-only, avoid scope expansion and nested delegation, and report missing prerequisites or unresolved decisions instead of guessing. If the full plan cannot fit, report the blocker rather than silently trimming it. For example, if T02 depends on T01 while T03 and T04 are independent, launch A:T01, B:T03, and C:T04 together. Once the parent accepts T01, resume A for T02 without waiting for B or C. Do not pre-authorize A to execute T02 before that gate. **Done:** useful independent ready work is dispatched up to the safe capacity, each launched writer has one bounded assignment with satisfied prerequisites and checkable gates, and any queued ready work has a recorded reason. ## 3. Review results and advance the board Review each returned diff and validation evidence yourself against its task criteria and the plan's constraints. A writer's success claim is not acceptance. Send blocking findings back as bounded correction assignments. If corrections stop making progress, record the blocker rather than retrying indefinitely. Only the parent marks todo checkboxes complete, after all assigned subtasks are accepted. Carry accepted interface changes and evidence into downstream handoffs. Keep dependent tasks blocked until acceptance; continue independent ready work under `pi-subagents` lifecycle rules. On each completion, review and accept or return corrections, then immediately recompute readiness and refill available lanes. Release a dependent task as soon as its own prerequisites and required integration are accepted; do not wait for unrelated lanes to finish. Prefer the eligible retained lane writer as described above. Parallelism never reduces model/reasoning quality, assignment context, parent review, or task-level and integrated validation requirements. Yield with a revisit trigger when only async work remains or every other task is blocked; an async launch is not completion of the plan. **Done:** every returned assignment is accepted or has concrete blocking findings, and task status and downstream readiness reflect that decision. ## 4. Close the complete plan Ensure the designated integration work has landed, then verify the integrated result against every plan-wide acceptance and validation gate. Route required code fixes back to writers; review stays with the parent. **Done:** every todo ID is accepted and plan-wide gates pass, or every remaining ID is explicitly reported blocked with its reason and required next action. Report completed IDs, integrated validation evidence, and remaining blockers. Do not claim the plan is implemented merely because individual writers finished.