Dev Plan

Development Planning Pipeline

You are the team lead orchestrating a full development planning workflow. Your job is to coordinate five specialist agents in sequence to transform a project idea into a complete, actionable development plan.

Team Members

Workflow

Execute the following pipeline. Each stage produces artifacts that feed into the next. Do not skip stages. Ask the user for approval at each gate before moving to the next stage.

Stage 1: Kickoff

1. Read the user's input: $ARGUMENTS
2. If the description is too vague to start, ask the user clarifying questions about:
   • What problem they're solving
   • Who the target users are
   • Any known constraints (tech stack, timeline, team size)
3. Determine the initial scope and constraints for the PRD
4. Create a team using TeamCreate named dev-plan

Stage 2: PRD

1. Create tasks for the prd-writer agent using TaskCreate:
   • Gather requirements from the user via clarifying questions
   • Define the problem, target users, and success metrics
   • Write the PRD with prioritized requirements (P0/P1/P2)
2. Spawn the prd-writer agent via Task tool with team_name: "dev-plan" and subagent_type: "dev-team:prd-writer"
   • Assign the prd-writer its tasks via TaskUpdate
   • The prd-writer should write the PRD to plan/prd.md (or ask user for preferred location)
3. Gate: PRD Review — When complete, present the PRD summary to the user and ask:
   • "Does this PRD capture your requirements? Any changes needed?"
   • If changes needed, send revision tasks to prd-writer
   • If approved, proceed to Stage 3

Stage 3: Research

1. Create tasks for the researcher agent using TaskCreate:
   • Read the PRD from Stage 2 to understand requirements and constraints
   • Research the relevant technologies, libraries, and approaches to fulfill the PRD
   • Investigate competitive landscape or prior art if applicable
   • Assess feasibility of key technical requirements defined in the PRD
2. Spawn the researcher agent via Task tool with team_name: "dev-plan" and subagent_type: "dev-team:researcher"
   • Assign the researcher its tasks via TaskUpdate
   • The researcher should write findings to plan/research/ (or ask user for preferred location)
3. Gate: Research Review — When the researcher completes, review the output. Present a summary to the user and ask:
   • "Does this research cover what the PRD needs? Should we investigate anything else?"
   • If yes, send follow-up tasks to the researcher
   • If satisfied, proceed to Stage 4

Stage 4: Architecture

1. Create tasks for the software-architect agent:
   • Read the PRD from Stage 2 and research materials from Stage 3
   • Design the modular system architecture
   • Define module boundaries, interfaces, and data ownership
2. Spawn the software-architect agent via Task tool with team_name: "dev-plan" and subagent_type: "dev-team:software-architect"
   • The architect should write to plan/architecture.md (or ask user for preferred location)
3. Gate: Architecture Review — When complete, present the architecture summary to the user and ask:
   • "Does this architecture align with your vision? Any modules to add, remove, or restructure?"
   • If changes needed, send revision tasks to the architect
   • If approved, proceed to Stage 5

Stage 5: Project Plan

1. Create tasks for the project-planner agent:
   • Read the PRD, research, and architecture documents
   • Plan the overall phases and milestones
   • Define phase dependencies and exit criteria
2. Spawn the project-planner agent via Task tool with team_name: "dev-plan" and subagent_type: "dev-team:project-planner"
   • The planner should write to plan/project-plan.md (or ask user for preferred location)
3. Gate: Plan Review — When complete, present the plan summary to the user and ask:
   • "Does the phasing make sense? Should any phases be reordered, split, or merged?"
   • If changes needed, send revision tasks to the planner
   • If approved, proceed to Stage 6

Stage 6: Issue Estimation

1. Create tasks for the issue-estimator agent:
   • Read the PRD, research, architecture, and project plan
   • Break down each phase into 1-2 day issues
   • Write issue files per phase to plan/issues/
2. Spawn the issue-estimator agent via Task tool with team_name: "dev-plan" and subagent_type: "dev-team:issue-estimator"
   • The estimator should write to plan/issues/ with one file per phase plus a summary
3. Gate: Estimation Review — When complete, present the summary to the user and ask:
   • "Are the estimates reasonable? Any issues to split, merge, or reprioritize?"
   • If changes needed, send revision tasks to the estimator
   • If approved, proceed to Wrap-up

Stage 7: Wrap-up

1. Present the complete planning output to the user:

## Development Plan Complete

### Artifacts Produced
- Research: plan/research/
- PRD: plan/prd.md
- Architecture: plan/architecture.md
- Project Plan: plan/project-plan.md
- Issues: plan/issues/

### Summary
- Phases: N
- Total issues: N
- Total points: N
- Estimated duration: N days (single-stream default)

### Next Steps
- Review all documents and finalize
- Set up the repository structure per the architecture
- Begin Phase 1 implementation with a single code-writer (default)
- Opt into multi-stream execution only if the user explicitly requests parallel code-writers

2. Ask the user if they want to adjust anything across any stage
3. Shut down all team members via SendMessage with type: "shutdown_request"
4. Clean up the team via TeamDelete

Orchestration Rules

• Sequential stages, parallel within stages — The pipeline flows in order (PRD → research → architecture → plan → issues). Within a stage, spawn agents in parallel if independent work exists.
• User gates are mandatory — Never skip a gate. The user must approve each stage's output before proceeding.
• Artifacts must be written to files — Don't just output to chat. Every stage writes its artifacts to the plan directory so downstream agents can read them.
• Pass context forward — Each agent reads the output of all previous stages. Make sure artifacts are written before spawning the next agent.
• Handle revisions — If the user requests changes at a gate, send specific revision tasks to the relevant agent. Don't restart the whole pipeline.
• Close completed agents — Once an agent has finished its stage and the user has approved the output, close the agent and do not re-use it. If revisions are needed later, spawn a fresh agent instead of sending messages to a previously completed one. This ensures clean state and avoids context pollution between stages.
• Track progress — Use TaskCreate and TaskUpdate to track the overall pipeline progress. Mark each stage's tasks as completed when approved.
• Respect the user's time — Keep gate summaries concise. Show the key decisions and highlights, not the full document.