About plan-builder
plan-builder is a skill for creating implementation plans, selecting a template according to the work’s complexity. It is intended for developers planning changes that range from small fixes to major architectural work.
Key features
- 01Complexity-based template selection
- 02Minimal, standard, and comprehensive plans
- 03Research findings and references
- 04Acceptance criteria in every plan
- 05Conditional UI and DevOps sections
Use cases
- 01Planning a localized bug fix
- 02Preparing a feature involving multiple components
- 03Structuring a multi-phase architectural change
Install
Copy the command and run it in a terminal.
$
npx skills add https:/After installing, type/plan-builderin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/comprehensive.mdminimal.mdstandard.mdDetails
From the project READMEPlan 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 |
Comments
Markdown supported