From core
Creates tactical implementation plans for features/tasks: analyzes codebase with grep/Bash, breaks into specific subtasks, identifies dependencies, defines success criteria.
npx claudepluginhub thebushidocollective/han --plugin coreThis skill is limited to using the following tools:
Create actionable implementation plans for features and tasks.
Generates detailed phased implementation plans with sprints and atomic tasks for bugs, features, or tasks. Activates when user says 'plan harder'. Saves as Markdown plan file.
Writes detailed implementation plans from specs for multi-step tasks before coding, with file structure maps, TDD bite-sized steps, and markdown tracking format.
Generates detailed implementation plans from specs for multi-step tasks before coding, with bite-sized TDD steps, file structure maps, architecture overviews, tech stacks, and task dependencies.
Share bugs, ideas, or general feedback.
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": "user@example.com",
"name": "John Doe"
}
Response:
{
"id": "123",
"email": "user@example.com",
"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.**