execplan-implement

You have been provided an ExecPlan. This plan should have tasks and milestones associated with it, describing how to implement the plan.

The goal is the entire plan implemented on a single integration branch, with every task and milestone resolved.

The tasks are not a list of steps. They are a task graph with blocking relationships between them. This means there is always a frontier of tasks which are ready to be grabbed.

Subagent management rules:

• Activate the subagent-model-router skill.
• For every subagent dispatch, use subagent-model-router to obtain its final dispatchable route, and apply its model and effort policy through dispatch controls. Stop on a named blocker.
• Use the router’s model unless the user explicitly names an exact model; do not ask them to choose. Authorization is not model selection. Separately check task authorization, control permissions, and live acceptance of the model and required effort (only under explicit policy). Report specific blockers without confusing permission with capability or bypassing router policy.
• Implementer subagents should be run in the background where possible for maximum concurrency.
• Communication to and from subagents should be sparse. Communicate primarily through context pointers: to the plan, tasks, research notes, and previous commits. Don't duplicate information already available via pointers.
• Delegate integration to one persistent integration coordinator subagent. Reuse it across merge waves, progress updates, and final checks. The coordinator should also handle deterministic commits and status checks directly when safe.

Enforce limits for exploration, implementation, review, and fixes. An agent is idle only with no outstanding assignment; dependency waits remain active.

All commits must follow commit message guidelines.

Runtime enforcement

1. Record each background assignment you dispatch, including reuse. Before dispatch, set a deadline based on expected effort and complexity. Record the routed model and its exact explicit effort or host-default omission. Track task and agent IDs, start time, extension count (initially zero), and enforcement handle as available.
2. Arm enforcement before waiting. Use a host timeout or parent-owned scheduler bounded by the nearest assignment or checkpoint deadline. Independently time out blocking operations. Recheck deadlines whenever control returns, including after user interruptions.
3. At expiry, request status, completed work, blockers, and updated ETA by a bounded checkpoint deadline. Keep overdue work under a deadline. On timely status, confirm completion, stop the worker, or grant its only ETA-based extension. If extended, record the new deadline, increment the count, and re-arm enforcement. Preserve the count across follow-ups. Stop the worker on a missed checkpoint or expired extension.
4. Before transferring ownership, confirm the worker and its write-producing operations have stopped, then route and dispatch a fresh replacement. If shutdown is unconfirmed, report the blocker and continue independent work. Cancel enforcement on completion.

Steps

1. Activate the exec-plans skill, then read the plan, milestones, and tasks to understand the task graph.

2. (optional) Use an exploration subagent to conduct any exploration required by the tasks - relevant codebase files or external documentation. Brief it with the needed context, acceptance criteria, and known negative cases, using context pointers where those facts are already available. Ensure the exploration subagent can save files - it should save its markdown notes in a directory next to the plan, accessible by all future subagents. This lets implementer subagents focus on implementation rather than exploration.

3. If current branch is main or master, create a new integration branch. Start the integration coordinator subagent, instructing it to activate the exec-plans skill and reconcile its required plan sections before reporting a checkpoint complete.

4. Use implementer subagents to implement each task, each in its own worktree on its own branch. Follow the router’s final dispatchable route and runtime enforcement as specified above. Each implementer subagent:

   • confirms its worktree is based on the integration branch before starting, and resets onto it if not;
   • calls the Skill tool with tdd to build the task;
   • merges the integration branch tip into its own branch before reporting done

5. Once an implementer subagent completes, have the same integration coordinator subagent merge its work to the integration branch.

6. If this changes the frontier of available tasks, kick off more implementer subagents to work on the new tasks. This allows for maximum concurrency.

7. Once all tickets are complete, follow the code review fix cycle.

8. Ensure all tasks and milestones are resolved and report the integration branch.

9. Clean up all implementer subagent worktrees and their related branches.

Code review fix cycle

Call the Skill tool with code-review-biaxis on the integration branch. Track all issues raised by the code review as new tasks in the ExecPlan frontier, then fix them in a single implementer subagent. Repeat code review → fix cycle until no issues remain for a maximum of three iterations. Report all unresolved issues.

For each repeat of the cycle, prefer reusing the code review and implementer subagents from the previous iteration when they match the final dispatchable route: the same model with no original effort override for host_default, or the exact model/effort pair for explicit. Otherwise, dispatch a fresh agent.

Gotchas

• Do not create worktrees anywhere within the main project directory because agents will automatically discover files like AGENTS.md causing context window bloat. Recommend creating them in ../<project name>.worktrees.