Implement plan

Implement Plan

Execute an implementation plan file.

Task Tracking

At the start, use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:

1. Resolve and read the plan file
2. Read context files
3. Run $implement skill
4. Update plan status

Step 1: Resolve and Read the Plan File

Determine which plan file to implement using these rules in order:

1. Explicit path — If an absolute or relative path was passed, use it
2. Explicit slug — If a slug was passed (e.g., add-image-cache), resolve to .turbo/plans/<slug>.md if that file exists; otherwise fall through to rule 5 before erroring
3. Single file — Glob .turbo/plans/*.md. If exactly one plan exists, use it
4. Most recent — If multiple plans exist, use the most recently modified
5. Unexpanded shell — If a slug or path was passed but resolved to no plan, derive <slug> from the basename (stripping .md) and check .turbo/shells/<slug>.md. If it exists, halt with: "<slug> is a shell that needs expansion first. Run $pick-next-shell to expand and implement it."
6. Legacy fallback — If .turbo/plans/ does not exist but .turbo/plan.md exists, use it
7. Nothing found — If no plan matched any rule above, tell the user to run $turboplan (for a new task) or $pick-next-shell (for existing shells) and stop

If multiple plans exist and the most-recent choice is non-obvious (e.g., several plans were modified within the same minute), use request_user_input to let the user pick from the candidates.

State the resolved plan path before continuing, then read the file.

Workflow state lives at .turbo/workflows/<slug>.md — slug from the resolved plan's basename. It pairs one-to-one with the thread's goal. When this run's create_goal attempt succeeds, write the file fresh: Status: active plus this invocation's update_plan list as a checkbox list. When an unfinished goal already exists, mirror into the workflow file its objective names; when it names none, continue without workflow state. Mirror every update_plan call into the file; it holds the pipeline's remaining steps and their statuses. When this run created the goal, run the terminal step in order: mark the final entry completed and mirror it, set Status: closed, mark the goal complete with update_goal, then emit any halt message.

Attempt create_goal with the objective: "Execute the implementation plan at <plan path> through $implement, then set the plan's frontmatter status to done when it has frontmatter. Workflow state: .turbo/workflows/<slug>.md; mirror every update_plan call into it. Loop state lives under .turbo/loops/. After any context compaction, re-read the plan file, the workflow file, and any active ledger, and continue from the first unfinished entry. Mark this goal complete only after that status update, or after $implement completes for a plan without frontmatter." If an unfinished goal already exists, an outer workflow owns it; continue without creating one.

Step 2: Read Context Files

Read in full:

• Every file listed in the plan's Context Files section
• Files the user referenced in their original request (if any)
• Every file path the plan references in the Context, Pattern Survey, and Implementation Steps sections

Step 3: Run $implement Skill

Run the $implement skill. The plan file, its file references, and its Verification section are already in conversation context from Step 1.

Step 4: Update Plan Status

After $implement completes, set the plan's frontmatter status: to done. If the plan is the legacy .turbo/plan.md without frontmatter, skip the status update.

If this run created a goal in Step 1, mark it complete with update_goal.

Then call update_plan to mark this step completed and continue with the next step of the active workflow.

Rules

• The plan file is read-only during execution. If revisions are needed, run $refine-plan or $draft-plan separately.
• Never skip Step 2.
• Never enumerate or execute the plan's Implementation Steps inline. The work runs through $implement. Restating steps as a turn-level narration counts as inline execution and bypasses the delegation.
• If the plan's Implementation Steps or Verification include git commit, git push, or PR creation, halt before Step 3 and ask the user to remove them via $refine-plan.