plan-builder

# 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 | `resources/minimal.md` |
| **Standard** | Most features, complex bugs, team collaboration | `resources/standard.md` |
| **Comprehensive** | Major features, architectural changes, multi-phase work | `resources/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