Plan Builder
Write implementation plans using the appropriate template based on complexity.
Template Selection
| Complexity | When to Use | Template |
|------------|-------------|----------|
| Minimal | Simple bugs, small improvements, clear single-file changes | references/minimal.md |
| Standard | Most features, complex bugs, team collaboration | references/standard.md |
| Comprehensive | Major features, architectural changes, multi-phase work | references/comprehensive.md |
Selection Criteria
Use Minimal When
- Fix is obvious and localized
- Single file or 2-3 related files
- No architectural decisions needed
- Clear acceptance criteria from description
Use Standard When (Default)
- Multiple components affected
- Requires research or external docs
- Team needs context for review
- Has dependencies or risks
Use Comprehensive When
- New system or major feature
- Multiple phases of work
- Architectural decisions required
- Cross-cutting concerns (security, performance)
- Involves multiple teams or stakeholders
Plan Output
Write plans to: docs/plans/[YYYYMMDDHHMMSS]_<title>.md
Include in every plan:
- Research findings with file paths (e.g.,
src/models/user.rb:42) - External documentation URLs
- Related issues/PRs if known
- Acceptance Criteria from user input (populated from blueprint Step 2)
Conditional Sections
UI Features
Include "Design System Reference" section when feature involves:
- Pages, components, forms, buttons, modals
- Visual design elements
DevOps Features
Include "Infrastructure Context" section when feature involves:
- Terraform/OpenTofu, Ansible, cloud resources
- Docker, CI/CD, infrastructure
Anti-Patterns
| Don't | Do | |-------|-----| | Use comprehensive for simple bugs | Match template to actual complexity | | Skip Acceptance Criteria | Always include testable criteria | | Leave placeholder text | Fill all sections or remove them | | Over-plan obvious changes | Minimal template exists for a reason |