Stats
Actions
Tags
From core
Creates tactical implementation plans for features/tasks: analyzes codebase with grep/Bash, breaks into specific subtasks, identifies dependencies, defines success criteria.
How this skill is triggered — by the user, by Claude, or both
Slash command
/core:planThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create actionable implementation plans for features and tasks.
Create actionable implementation plans for features and tasks.
han-core:plan - Create tactical implementation plan for a feature or task
/plan [arguments]
A good plan turns a vague goal into concrete, executable steps.
Technical Planning (this skill):
Architecture Design (architecture-design skill):
Use planning for:
Use architecture for:
Clarify what success looks like:
Ask questions:
Understand what exists:
Research:
# Find similar implementations
grep -r "similar_pattern" .
# Find related files
find . -name "*related*"
# Check existing tests
grep -r "test.*similar" test/
Good tasks are:
Task template:
### Task: [Specific deliverable]
**What:** [Concrete description]
**Why:** [Reasoning for this approach]
**Dependencies:** [None, or list of task numbers]
**Complexity:** S | M | L
**Success criteria:**
- [ ] Criterion 1
- [ ] Criterion 2
**Files affected:**
- `path/to/file1.ts`
- `path/to/file2.ts`
**Testing approach:**
[How to verify this works]
Task dependencies:
Example:
Task 1: Create database schema (no dependencies)
Task 2: Create API endpoint (depends on Task 1)
Task 3: Create UI component (depends on Task 2)
Task 4: Add tests (depends on Tasks 1-3)
Parallel vs Sequential:
Can be parallel:
Task A: Frontend component
Task B: Backend API
(If API contract is defined)
Must be sequential:
Task 1: Database migration
Task 2: Update queries to use new schema
(Task 2 depends on Task 1)
Use relative sizing, not time:
If task is > L: Break it down further
Complexity factors:
How will we verify it works?
Example:
## Testing Strategy
**Unit tests:**
- Test validation logic
- Test calculation functions
- Test error handling
**Integration tests:**
- Test API endpoint with real database
- Test with various input scenarios
- Test error responses
**E2E tests:**
- User can complete full workflow
- Error messages display correctly
- Success case works end-to-end
**Manual testing:**
- [ ] Test in Chrome
- [ ] Test in Firefox
- [ ] Test on mobile
# Implementation Plan: [Feature Name]
**Estimated complexity:** S | M | L | XL
**Status:** Draft | Approved | In Progress | Complete
## Goal
[One paragraph: What are we building and why?]
## Current State
[What exists today that's relevant to this plan?]
[What needs to change?]
[What can be reused?]
## Proposed Approach
[High-level strategy: How will we build this?]
[Key technical decisions made]
[Alternatives considered and why not chosen]
## Tasks
### Phase 1: Foundation
#### Task 1.1: [Specific deliverable] (Complexity: S)
**What:** [Concrete description of what needs to be built]
**Why:** [Reasoning for this approach]
**Dependencies:** None
**Success criteria:**
- [ ] Criterion 1 (testable)
- [ ] Criterion 2 (testable)
- [ ] All tests pass
**Files affected:**
- `src/components/Feature.tsx` (create)
- `src/types/feature.ts` (update)
**Testing approach:**
- Unit test for component logic
- Integration test for data flow
---
#### Task 1.2: [Next task] (Complexity: M)
**What:** [Description]
**Why:** [Reasoning]
**Dependencies:** Task 1.1
**Success criteria:**
- [ ] Criterion 1
- [ ] Criterion 2
**Files affected:**
- `api/routes/feature.ts` (create)
**Testing approach:**
- Integration test for API endpoint
---
### Phase 2: Integration
[Additional tasks organized by phase]
## Testing Strategy
**Overall approach:**
[How we'll verify the entire feature works]
**Test coverage goals:**
- Critical paths: 100%
- Happy paths: 100%
- Edge cases: 80%
## Risks & Considerations
| Risk | Impact | Mitigation |
|------|--------|------------|
| Database migration fails | High | Test in staging first, have rollback plan |
| API performance slow | Medium | Add caching, monitor metrics |
## Out of Scope
**Explicitly NOT included in this plan:**
- [Feature A - deferred to v2]
- [Integration B - separate work]
- [Optimization C - premature]
## Open Questions
- [ ] Should we use library X or Y?
- [ ] What's the rate limit for the external API?
## Success Metrics
**How we'll know this is successful:**
- Feature ships to production
- All tests pass
- Performance meets requirements (< 200ms response)
- Zero critical bugs in first week
## References
- [Related documentation]
- [Design mockups]
- [API specifications]
- [Similar implementations]
Frontend tasks:
- Task 1: Create UI component
- Task 2: Add form validation
- Task 3: Connect to API
Backend tasks:
- Task 4: Create API endpoint
- Task 5: Add business logic
- Task 6: Database queries
Infrastructure:
- Task 7: Update deployment config
User Authentication (vertical slice):
- Task 1: Login form (frontend)
- Task 2: Login API (backend)
- Task 3: Session management
- Task 4: E2E test for login flow
Password Reset (vertical slice):
- Task 5: Password reset form
- Task 6: Password reset API
- Task 7: Email notification
- Task 8: E2E test for reset flow
Must Have (P0):
- Task 1: Core functionality
- Task 2: Critical path
Should Have (P1):
- Task 3: Nice to have feature
- Task 4: Enhancement
Could Have (P2):
- Task 5: Polish
- Task 6: Optimization
Good plans are:
Bad plans are:
Don't over-plan:
Good enough:
Bad task:
- Improve performance
Good task:
### Task 3: Optimize database queries (Complexity: M)
**What:** Add indexes to users table for email and created_at columns
**Success criteria:**
- [ ] Query time reduced from 500ms to < 50ms
- [ ] Migration runs successfully
- [ ] No impact on existing queries
Why matters:
## Why this approach?
We chose REST over GraphQL because:
1. Team is more familiar with REST
2. Simple CRUD operations don't need GraphQL flexibility
3. Can add GraphQL later if needed
**Trade-off:** Less flexible, but simpler to implement
Show, don't just tell:
## API Design
### Endpoint: POST /api/users
**Request:**
```json
{
"email": "[email protected]",
"name": "John Doe"
}
Response:
{
"id": "123",
"email": "[email protected]",
"name": "John Doe",
"createdAt": "2024-01-01T00:00:00Z"
}
## Common Planning Mistakes
### Too Vague
BAD:
### Too Detailed
BAD:
### Missing Dependencies
BAD: Task 1: Create UI Task 2: Create API (But UI depends on API contract)
### No Success Criteria
BAD: Task: Add validation (How do we know when it's done?)
GOOD: Task: Add validation
## Adaptive Planning
**Plans are living documents:**
- Update as you learn
- Add newly discovered tasks
- Remove tasks that aren't needed
- Adjust estimates based on reality
**When to update plan:**
- Discovered new requirement
- Found existing code to reuse
- Identified additional complexity
- Changed approach
## Planning Checklist
Before finishing plan, verify:
- [ ] Goal is clear and specific
- [ ] Current state analyzed
- [ ] Approach is feasible
- [ ] Tasks are specific and actionable
- [ ] Dependencies are identified
- [ ] Success criteria defined for each task
- [ ] Testing strategy included
- [ ] Risks documented
- [ ] Out of scope explicitly stated
## Examples
When the user says:
- "How should I implement user authentication?"
- "Plan out the shopping cart feature"
- "What's the approach for migrating to the new API?"
- "Break down this Jira ticket into tasks"
- "Create a plan for adding dark mode"
## Integration with Other Skills
- Use **simplicity-principles** - Keep plan simple (KISS, YAGNI)
- Use **architecture-design** - For high-level structure decisions
- Use **test-driven-development** - Include testing in tasks
- Reference **solid-principles**, **structural-design-principles** for implementation guidance
## Remember
1. **Plans are guides, not contracts** - Adapt as you learn
2. **Start simple, add detail** - Don't over-plan
3. **Make tasks actionable** - Specific and testable
4. **Document decisions** - Explain the "why"
5. **Include testing** - How will we verify it works?
**A good plan makes it easy to start coding.**
npx claudepluginhub thebushidocollective/han --plugin coreGenerates detailed, step-by-step implementation plans from specs or requirements, with bite-sized tasks, file paths, and test-first guidance.
Writes detailed implementation plans from specs for multi-step tasks before coding, with file structure maps, TDD bite-sized steps, and markdown tracking format.
Creates detailed implementation plans with bite-sized tasks and TDD steps. Use when you have a spec or requirements for a multi-step task before writing code.