| name | plan-implementation |
| description | Break down feature specifications into manageable implementation phases with TDD vertical slices. Creates actionable task lists for immediate development. Use when you have a feature spec and need a concrete implementation roadmap. |
Implementation Planning
Overview
This skill takes a feature specification document and breaks it down into concrete, manageable implementation phases. Each phase is sized appropriately for implementation (typically completable in a focused work session) and follows a Test-Driven Development approach with vertical slices.
When to Use
- After completing feature discovery (feature spec exists in
/docs/features/) - Before starting implementation of a complex feature
- When a feature needs to be broken into phases for incremental delivery
- When you want to create an actionable task list from a specification
- When planning sprints or work iterations
Core Principles
1. TDD Vertical Slices
Each phase should:
- Start with tests (Red-Green-Refactor)
- Deliver end-to-end functionality (data → logic → UI)
- Be independently testable (can validate it works)
- Build incrementally (each phase adds value to previous)
2. Appropriate Sizing
Tasks should be:
- Small enough: Completable in 30-90 minutes of focused work
- Large enough: Deliver meaningful, testable functionality
- Concrete: Clear acceptance criteria and deliverables
- Independent: Minimal dependencies on other in-progress work
3. Risk-Aware Sequencing
Phases should be ordered to:
- Validate assumptions early: High-risk items in early phases
- Build foundation first: Core domain models before complex logic
- Enable testing: Test infrastructure before feature code
- Deliver value incrementally: Each phase produces working software
Instructions
Phase 1: Analyze Feature Specification
- Read the feature spec from
/docs/features/[feature-name].md - Extract requirements: Identify all functional requirements and acceptance criteria
- Identify complexity areas: Note which parts are complex, risky, or have unknowns
- Map dependencies: Understand what exists, what's new, what needs changing
- Review codebase: Read relevant existing code to understand integration points
Phase 2: Design Phase Breakdown
- Identify vertical slices: What end-to-end capabilities can be delivered incrementally?
- Sequence for value: What order delivers testable functionality earliest?
- Group related work: Cluster tasks that naturally belong together
- Size appropriately: Break large slices into multiple phases if needed
- Define deliverables: What does "done" look like for each phase?
Phase 3: Create Implementation Tasks
For each phase, define:
- Phase Goal: One sentence describing what this phase accomplishes
- Test-First Tasks: What tests to write first (RED phase)
- Implementation Tasks: What code to write to make tests pass (GREEN phase)
- Refactoring Tasks: What cleanup/improvements to make (REFACTOR phase)
- Acceptance Criteria: How to verify this phase is complete
Phase 4: Generate Task List
- Create TodoWrite list: Populate with first phase tasks
- Document remaining phases: Write markdown doc with all phases
- Add phase markers: Clear separators between phases
- Include estimates: Flag complex/risky tasks
- Link to spec: Reference feature spec for context
Phase Template
Each phase should follow this structure:
### Phase N: [Descriptive Name]
**Goal**: [One sentence describing what this phase delivers]
**Vertical Slice**: [What end-to-end capability does this deliver?]
**TDD Cycle**:
#### RED - Write Failing Tests
- [ ] Test: [Specific test case 1]
- [ ] Test: [Specific test case 2]
- [ ] Test: [Specific test case 3]
**Why these tests**: [Brief explanation of what behavior we're defining]
#### GREEN - Make Tests Pass
- [ ] Create/modify: [File or class name]
- [ ] Implement: [Specific method or functionality]
- [ ] Wire up: [Integration points]
**Implementation notes**: [Key decisions, patterns to follow, gotchas]
#### REFACTOR - Clean Up
- [ ] Extract: [What to pull out into separate methods/classes]
- [ ] Rename: [What to make clearer]
- [ ] Remove: [What duplication to eliminate]
**Acceptance Criteria**:
- [ ] All tests in this phase pass
- [ ] Code coverage for new code > 80%
- [ ] [Specific observable behavior works]
- [ ] No regressions in existing tests
**Deliverable**: [What working functionality can be demonstrated]
**Estimated Complexity**: [Simple / Medium / Complex]
**Risks**: [Any concerns or unknowns]
Task Sizing Guidelines
Too Small (Avoid)
- Single line changes
- Trivial refactorings
- Adding one test case ❌ Why: Overhead of tracking exceeds value
Just Right (Target)
- Implement one domain concept with tests
- Add one feature capability end-to-end
- Refactor one subsystem with test coverage ✅ Why: Meaningful progress, clear validation, manageable scope
Too Large (Break Down)
- "Implement entire feature"
- "Refactor whole service layer"
- "Add all API endpoints" ❌ Why: Too vague, hard to test, risky, unclear when done
Vertical Slice Examples
Good Vertical Slice
Phase: Add horse training for Speed stat
- Tests: Training increases Speed, respects caps, validates input
- Implementation: Training entity, TrainingService.AddTraining(), Horse.CalculateEffectiveStats()
- Refactor: Extract validation, use value objects
- Demo: Can train a horse's Speed and see it improve in the database
Poor Vertical Slice (Too Horizontal)
Phase: Create all training entities
- Tests: Training entity exists, Stamina entity exists, Agility entity exists
- Implementation: Training class, Stamina class, Agility class
- Refactor: Share base class
- ❌ Problem: Doesn't deliver working feature, can't validate in real scenario
Output Format
This skill produces two outputs:
1. Implementation Plan Document
Create /docs/implementation/[feature-name]-implementation-plan.md with:
- Overview of approach
- All phases with tasks
- Testing strategy
- Risk mitigation notes
- Dependencies and prerequisites
2. TodoWrite Task List
Populate TodoWrite with tasks from Phase 1 only:
- Keeps immediate focus clear
- Avoids overwhelming task list
- Each phase gets added as it becomes active
Integration with Feature Discovery
This skill works hand-in-hand with feature-discovery:
- feature-discovery: Understand requirements → Create feature spec
- plan-implementation: Analyze spec → Create implementation plan → Populate tasks
- Implementation: Execute tasks → Mark todos complete → Move to next phase
Best Practices
Before Planning
- Feature spec exists and is approved
- Open questions are resolved
- Technical approach is validated
- Codebase has been explored
During Planning
- Each phase delivers testable value
- Tests are written before implementation
- Phases build on each other logically
- Risks are identified and sequenced appropriately
- Task list is concrete and actionable
After Planning
- First phase tasks are in TodoWrite
- Implementation plan is documented
- Team/stakeholders agree on approach
- Ready to start implementing immediately
Example Usage
User Workflow
User: "I'm ready to implement the race modifiers refactor"
Claude (using plan-implementation skill):
1. Reads docs/features/race-modifiers-refactor.md
2. Analyzes requirements and existing code
3. Designs 7 phases with vertical slices
4. Creates detailed task breakdown for each phase
5. Writes docs/implementation/race-modifiers-refactor-implementation-plan.md
6. Populates TodoWrite with Phase 1 tasks
7. Reports: "Ready to implement! Phase 1 tasks added to your todo list."
Phase Progression
Phase 1 Complete → Mark todos done → Add Phase 2 todos
Phase 2 Complete → Mark todos done → Add Phase 3 todos
...
All Phases Complete → Feature implemented with full test coverage
Common Phase Patterns
Pattern 1: Foundation Phase
Goal: Set up infrastructure and test harness
- Create test project structure
- Add domain entities/value objects
- Write characterization tests for existing behavior
- Deliverable: Tests run, infrastructure ready
Pattern 2: Core Logic Phase
Goal: Implement main business logic
- Write tests for core calculations/rules
- Implement service methods
- Validate edge cases
- Deliverable: Core feature works in unit tests
Pattern 3: Integration Phase
Goal: Connect to existing systems
- Write integration tests
- Wire up to database/repositories
- Connect to existing services
- Deliverable: Feature works end-to-end
Pattern 4: UI Phase (if applicable)
Goal: Add user-facing interface
- Write UI tests (if framework supports)
- Create controllers/view models
- Wire up to backend services
- Deliverable: Feature accessible to users
Pattern 5: Cleanup Phase
Goal: Remove old code and polish
- Delete deprecated methods
- Consolidate duplicated logic
- Add documentation
- Deliverable: Clean, maintainable codebase
Notes
- This skill uses Read, Grep, Glob to analyze feature specs and codebase
- Uses TodoWrite to create initial task list
- May use AskUserQuestion to clarify ambiguous implementation choices
- Focuses on actionable, concrete tasks rather than abstract planning
- Emphasizes tests-first approach for confidence and correctness
- Delivers working software incrementally rather than big-bang integration
CRITICAL GIT WORKFLOW RULES
NEVER commit or push code without EXPLICIT user approval.
When implementing planned features:
- Plan Phase: Create implementation plan - NO git commands
- Implementation: Write code, run tests - NO git commits
- WAIT for user approval: User must explicitly say "commit this" or "push this"
- ONLY THEN: Create commits and push to remote
Examples of what NOT to do:
- ❌ "Let me commit Phase 1" (without asking first)
- ❌ Automatically committing after completing a phase
- ❌ Assuming user wants code committed
Correct workflow:
- ✅ Complete phase implementation
- ✅ Run tests to verify
- ✅ Report results to user: "Phase 1 is complete. All tests passing."
- ✅ ASK: "Would you like me to commit these changes?"
- ✅ WAIT for explicit approval
- ✅ ONLY THEN run git commands
COMMIT AND PR MESSAGE RULES
NEVER include Claude Code attribution or self-reference in commits or PRs.
When creating commits or pull requests:
- ❌ NEVER add "🤖 Generated with [Claude Code]" footer
- ❌ NEVER add "Co-Authored-By: Claude Sonnet" tag
- ❌ NEVER mention Claude, AI, or automated generation
- ✅ Write commit messages as if written by the developer
- ✅ Focus on what changed and why
- ✅ Use professional, technical language only
Examples:
BAD - DO NOT DO THIS:
Feature implementation complete
This adds the new commentary system.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
GOOD - DO THIS:
Feature implementation complete
This adds the new commentary system with event detection
and natural language variation.