with one click
workflow-plan-phases
// Creates a structured implementation plan document with properly sized phases for efficient sub-agent execution.
// Creates a structured implementation plan document with properly sized phases for efficient sub-agent execution.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | workflow-plan-phases |
| description | Creates a structured implementation plan document with properly sized phases for efficient sub-agent execution. |
| disable-model-invocation | true |
Creates a phased implementation plan from a feature description, optimized for context-efficient sub-agent execution.
/workflow-plan-phases <description>
/workflow-plan-phases "Build a user authentication system with OAuth, MFA, and session management"
/workflow-plan-phases --output=docs/plans/auth-system.md "Build authentication system..."
description (required): What the user wants to build--output: Custom output path (default: docs/plans/{slugified-name}.md)docs/plans/ (create directory if needed) using a slugified filenameThis command only creates the plan. Do NOT proceed to implement any phases.
After the plan is written:
/workflow-implement-phases when ready to executeNever start writing code or implementing phases after creating the plan.
This skill provides methodology for creating implementation plans that are optimized for sub-agent execution, with properly sized phases that respect context window constraints.
A good phase plan:
Never skip this step. Even if the description seems complete, clarifying questions:
Scope & Boundaries
Technical Context
Integration Points
User Experience
Constraints
Present 3-5 targeted questions based on the description:
Before I create the implementation plan, I have a few questions:
1. **Existing Code**: Is this a new feature in an existing codebase, or greenfield?
If existing, what patterns should I follow?
2. **Auth Context**: You mentioned user roles - is there an existing auth system
to integrate with, or is that part of this work?
3. **Data Layer**: What database are you using? Are there existing models
this relates to?
4. **Scope Boundary**: Should this include the admin UI for managing X,
or just the core functionality?
5. **Testing**: What level of test coverage do you need? Unit only,
or integration/E2E as well?
Wait for answers before proceeding.
Target each phase to consume 30-50k tokens of sub-agent context:
RIGHT-SIZED Phase (~30-50k tokens):
TOO LARGE Phase (>60k tokens - split it):
TOO SMALL Phase (<15k tokens - combine it):
When a phase is too large, split by:
Example - Too Large:
Phase 1: Build user management with registration, login, profile
editing, password reset, email verification, and admin user listing
Split Into:
Phase 1: User model and registration endpoint
Phase 2: Login and session management
Phase 3: Password reset flow
Phase 4: Email verification
Phase 5: Profile editing
Phase 6: Admin user listing
Hard Dependencies (must complete first):
Soft Dependencies (preferred order, but parallelizable):
No Dependencies (fully parallel):
Strategies to reduce coupling between phases:
Define interfaces early: First phase exports types/interfaces, later phases implement against them
Stub dependencies: Phase can stub what it needs, later phase replaces stub with real implementation
Feature flags: Phases can merge independently, enable via flag
Vertical slices: Each phase is a thin vertical slice through all layers rather than horizontal layers
docs/plans/{feature-name}.md
Slugify the feature name:
user-authentication-system.mdapi-rate-limiting.md# {Feature Name} Implementation Plan
## Overview
{2-3 sentence summary of what this plan delivers}
## Goals
- {Primary goal}
- {Secondary goal}
- {Tertiary goal}
## Non-Goals (Out of Scope)
- {Explicit exclusion 1}
- {Explicit exclusion 2}
## Technical Context
- **Stack**: {language, framework, database}
- **Existing Code**: {relevant existing modules/patterns}
- **Integration Points**: {external services, APIs}
---
## Phase 1: {Phase Name}
### Objective
{One sentence describing what this phase accomplishes}
### Specification
{Detailed description of the work. Include:}
- What to create/modify
- Specific requirements
- Edge cases to handle
- Error handling expectations
### Files to Create/Modify
- `path/to/file.ts` - {purpose}
- `path/to/other.ts` - {purpose}
### Acceptance Criteria
- [ ] {Verifiable criterion 1}
- [ ] {Verifiable criterion 2}
- [ ] {Verifiable criterion 3}
### Dependencies
- **Requires**: {None | Phase X}
- **Blocks**: {Phase Y, Phase Z}
### Estimated Scope
- Files: {2-5}
- Complexity: {Low | Medium | High}
---
## Phase 2: {Phase Name}
{Same structure as Phase 1}
---
## Execution Strategy
### Dependency Graph
Phase 1 --+-- Phase 3 | Phase 2 --+ | Phase 4 <-+-- Phase 5
### Recommended Execution
- **Parallel Group 1**: Phase 1, Phase 2
- **Sequential**: Phase 3 (after Phase 1)
- **Parallel Group 2**: Phase 4, Phase 5 (after Phase 3)
---
## Verification Checklist
After all phases complete:
- [ ] {Integration verification 1}
- [ ] {Integration verification 2}
- [ ] {End-to-end test}
## Open Questions
- {Any unresolved decisions to revisit}
Use action-oriented names:
Good:
- "Create User Model and Repository"
- "Implement JWT Authentication"
- "Add Rate Limiting Middleware"
- "Build Password Reset Flow"
Bad:
- "User Stuff"
- "Part 1"
- "Backend Work"
- "Misc Improvements"
Be specific enough that a sub-agent can implement without guessing:
Vague:
"Add user authentication"
Specific:
"Create POST /api/auth/login endpoint that:
- Accepts { email, password } body
- Validates against User model
- Returns JWT token with 24h expiry on success
- Returns 401 with { error: 'Invalid credentials' } on failure
- Rate limits to 5 attempts per 15 minutes per IP
- Logs failed attempts with IP and email (not password)"
Write testable criteria:
Not Testable:
- "Works correctly"
- "Handles errors"
- "Is secure"
Testable:
- "POST /api/users returns 201 with user object (excluding password)"
- "Invalid email format returns 400 with validation error"
- "Passwords are hashed with bcrypt cost factor 12"
- "JWT tokens expire after 24 hours"
Wrong:
Phase 1: Setup
Phase 1.1: Database schema
Phase 1.2: Model classes
Phase 1.3: Repository layer
Right:
Phase 1: Database Schema and Migrations
Phase 2: User Model and Repository
Phase 3: Authentication Service
Wrong:
Phase 3: Implement all remaining features including search,
filtering, pagination, sorting, export, and batch operations
Right:
Phase 3: List Endpoint with Pagination
Phase 4: Search and Filtering
Phase 5: Sorting Options
Phase 6: Export Functionality
Phase 7: Batch Operations
Wrong:
Phase 2: Handle edge cases and fix bugs
Right:
Phase 2: Input Validation and Error Handling
- Validate email format, password strength
- Handle duplicate email registration
- Return structured error responses
Wrong:
Phase 1 depends on Phase 3
Phase 3 depends on Phase 2
Phase 2 depends on Phase 4
Phase 4 depends on Phase 1 (circular!)
Right:
Phase 1: Foundation (no dependencies)
Phase 2: Core Logic (depends on 1)
Phase 3: Extended Features (depends on 2)
Phase 4: Polish and Edge Cases (depends on 3)
Before delivering plan:
This skill is for planning only. After creating the plan, STOP.
Do NOT:
After the plan is complete:
/workflow-implement-phases or the implement-phases skill when ready to executeThe user decides when to proceed with implementation.