---
name: implement-plan
description: Implement a plan-todo plan through exact-checkpoint sai CLI forks, with user-approved models routed per task by Sai.
disable-model-invocation: true
---

# Implement the pinned plan

The parent is the orchestrator; separate `sai`/`selesai` CLI processes do the
implementation. Do not use `pi-subagents`, its tools, missions, workflow scripts,
or supervisor messaging. Do not hand the complete backlog to one unrestricted
worker. Invocation authorizes delegated implementation of the selected plan,
not deployment, publication, destructive cleanup, or unrelated work.

Use dependency-aware orchestration with bounded feedback. Planning defines the
outcome; orchestration assigns and sequences work; workers execute bounded
assignments. Adapt execution without silently changing the agreed outcome.

Read [CLI execution](references/cli-execution.md) before preparing a checkpoint
or launching workers. Read [model routing](references/model-routing.md) before
asking for the model pool or calling `ask_sai`. Resolve helper/reference paths
relative to this skill directory, not the repository. This skill does not require
changes to Selesai itself or to `plan-todo`.

## 1. Pin the execution contract

Read `.selesai/tasks/plan.md` and `.selesai/tasks/todo.md` completely (or the
explicitly supplied pair), and inspect the current working tree. Account for
existing edits and completed work without adopting unchecked success claims.
Keep unknown product/interface choices blocked rather than inventing agreement.

Identify the source session and the exact completed assistant turn that finished
producing this pair. `PI_SESSION_FILE` is a source-session lead, not a checkpoint
selector. Use the helper's `inspect` command, then inspect the actual entry and
its ancestry: match the plan/todo paths, outcome, and surrounding planning work.
Ask for the exact ID if more than one planning turn is plausible. Never substitute
latest session/leaf, a text summary, or a fresh-context worker. A hash alone is
not enough without identifying its source session.

Branch through and including that turn. Verify current plan/todo contents match
the intended planning handoff; session history does not restore old files. If
artifacts changed materially after the selected turn, stop for reconciliation.
Create one immutable checkpoint session and plan/todo snapshots with the helper;
record source session, exact entry, content hashes, repository/ref, and dirty
state. The parent session and its active leaf must remain untouched.

**Done:** one verified historical planning checkpoint is pinned, both task
artifacts are bound to it, and blocking scope/authorization decisions are known.

## 2. Establish models, limits, and the execution board

Discover local models with the helper's `catalog`. Present relevant options and
ask the user to approve a pool of exact provider/model/reasoning combinations.
Do not interpret available credentials as permission to use every model. Accept
an explicitly supplied pool without asking again; ask only for missing choices.
Capture role restrictions, routing preferences, concurrency, worker timeouts,
correction-round limits, and any spending limit. Offer concrete defaults for
approval; do not impose a paid-model pool, hard spending claim, or infinite loop.

Obtain an approved fallback candidate or agreement to ask when routing is
uncertain. Catalog prices are estimates, not a guaranteed bill. If a hard spend
cap is required but cannot be enforced with this CLI, report that before launch.

Build one durable board from every todo ID: pending, ready, active,
needs-correction, accepted, or blocked. Each row records prerequisites, edit
ownership, acceptance/validation, workspace/ref, attempt count, routing decision,
worker run/session paths, result evidence, and blocker/next action. Record the
checkpoint and approved pool once in the board header. Original task definitions
live in the pinned snapshots; the board owns runtime state. Only the parent
updates the board and original todo completion marks.

**Done:** the pool and execution limits are explicitly approved, every todo ID
is accounted for, and only tasks with accepted prerequisites are ready.

## 3. Route and dispatch ready assignments

Have `ask_sai` recommend one approved provider/model/reasoning candidate for each
ready task using the routing reference. Skip classification for a single eligible
candidate. Batch independent questions, obey tool limits, and use only supplied
capability evidence. The parent validates recommendations; missing answers,
failures, low confidence, and insufficient evidence take the approved fallback
or return to the user. Never let a classifier declare correctness, acceptance,
completion, or whether to continue the orchestration loop.

Use the smallest execution shape justified by dependencies and risk. Independent
tasks may run concurrently; dependent tasks wait for accepted outputs. Keep one
writer per checkout; use explicitly prepared worktrees for concurrent writers.
Assign shared files and final integration to one owner. If another pattern is
useful, consult [execution patterns](references/execution-patterns.md); do not
add stages merely to exercise the catalog.

Give each worker one bounded task ID or independently checkable subtask with:
- Objective, current repo/cwd/ref, allowed files, prohibited changes.
- Pinned plan/todo paths, assigned task text, authoritative source leads.
- Accepted prerequisite/interface results and any post-checkpoint clarification.
- Acceptance criteria, exact validation, output/report requirements.
- Stop conditions: missing prerequisite, scope conflict, unsafe action, or a
  decision requiring parent/user authority. No nested agents or model switching.

Inherited conversation is context, not permission to execute other tasks.
Workers keep planning/control files read-only. New information after the pinned
turn enters through a bounded task brief, never by moving the checkpoint.
Launch through the helper with explicit provider/model/thinking and a timeout.
Record each assignment before launching; record its returned process/session
identity immediately afterward. Do not auto-approve new project trust prompts.

**Done:** each active worker has a validated candidate, satisfied prerequisites,
exclusive write ownership, and a recorded CLI run with checkable deliverables.

## 4. Validate results and advance dependencies

Use helper status and artifacts to inspect completed processes. A running or
queued CLI process has no native subagent wake notification. Use the helper's
bounded, filesystem-event-driven `wait` command for active run directories;
attach it to a real host background completion facility when available, or use
a bounded foreground wait when results are needed now. A wait timeout means
still running, not worker failure. If yielding, record exact run paths and the
revisit action. Do not invent native notifications, busy-poll, sleep-loop, or
claim launching workers finishes the plan.

`finished-unreviewed` is not acceptance. Inspect the actual diff and validate
reported commands and acceptance evidence against the assigned task and plan.
Check requested versus resolved provider/model/reasoning. If independent review
is justified, launch a bounded read-only CLI fork, then arbitrate its findings
in the parent; the reviewer does not mark tasks accepted.

Send concrete defects back as bounded correction assignments from the same
pinned checkpoint, including the current diff and prior findings. Reclassify only
when task requirements materially change, and stay within the approved pool.
Preserve completed work; adjust only affected dependencies/assignments. Reaching
the approved retry/time/spend boundary, repeating without progress, or changing
an agreed outcome requires escalation rather than indefinite repair.

On infrastructure/provider failure, unknown process state, or timeout: inspect
logs, session, and partial diff before retrying. Stop requests do not roll back
files. Do not overlap a replacement with a possibly live worker or silently
switch to another model/execution framework. Capture recovery state and ask
when no safe authorized next action exists.

Only after parent acceptance mark the task complete, record interface/evidence
handoffs, and unblock dependent work. Return to dispatch while safe ready work
remains; continue independent work when another lane is blocked.

**Done:** every returned assignment is accepted, has actionable correction
findings, or is explicitly blocked; the board reflects all active runs and
actual downstream readiness.

## 5. Integrate and close the whole plan

Have the integration owner assemble accepted work without overwriting unrelated
changes. Route implementation fixes through CLI workers; the parent owns review
and final acceptance. Verify every plan-wide acceptance condition against the
integrated checkout, not just isolated worker results.

**Done:** every todo ID is accepted and integrated gates pass, or every remaining
ID is explicitly blocked with evidence and the required next action. Report the
checkpoint, completed/blocked IDs, integrated checks, worker/model receipts,
remaining live processes, and recovery paths. Do not report complete while a
required task, verification gate, or integration step is unresolved.