Files
dotfiles/pi/.pi/agent/prompts/implement.md

2.2 KiB

description
description
Adaptive implementation workflow — routes, plans, waits for approval, then implements

Use the subagent tool to implement the following task. The workflow is ADAPTIVE — first evaluate, then plan, get user approval, then execute.

Step 1: Route

Run the "router" agent with this task: $@

The router will return a classification (SMALL, MEDIUM, LARGE, or HUGE).

Step 2: Execute based on classification

If SMALL:

Run a single "coder" agent. No planning or review needed. After implementation, present what was done. Done.

If MEDIUM:

Run the "scout" agent, then the "planner" agent as a chain.

STOP. Present the plan to the user and ask for approval before continuing.

Once approved (user says ok, go, approved, looks good, etc):

  • Run the "coder" agent to implement the plan
  • Run "reviewer-quick" on the result
  • If NEEDS_FIXES, run the "fixer" agent

If LARGE:

Run a chain: "scout" → "planner" → "plan-reviewer"

STOP. Present the plan AND the Opus review to the user. Ask for approval before continuing.

Once approved:

  • Execute the plan steps using "coder" for sequential steps, or "coder-parallel" with parallel tasks if the plan identified parallelizable steps
  • Run the "reviewer" agent on all changes
  • If NEEDS_FIXES, run the "fixer" agent

If the user requests changes to the plan, revise and present again before implementing.

If HUGE:

Same as LARGE but use "deep-scout" instead of "scout", and prefer parallel execution with "coder-parallel" for independent steps.

STOP after planning. Same approval gate as LARGE.

Important

  • NEVER skip the approval gate for MEDIUM, LARGE, or HUGE tasks. Always present the plan and wait.
  • When presenting the plan, format it clearly. Highlight: what will change, which files, risks, and the Opus review verdict (if applicable).
  • If the user says "with changes" or gives feedback, revise the plan and present again.
  • Always pass scout/planner context forward using {previous} in chain mode.
  • For parallel coder tasks, clearly assign each coder to specific files to avoid conflicts.
  • If any step fails, report what happened and stop.
  • After the final step, summarize: what was done, what files changed, what was reviewed, and any remaining concerns.