Loading...
Loading...
Use when creating implementation plans for features or tasks. Focuses on tactical execution planning with clear tasks, dependencies, and success criteria.
npx skill4agent add thebushidocollective/han technical-planning# Find similar implementations
grep -r "similar_pattern" .
# Find related files
find . -name "*related*"
# Check existing tests
grep -r "test.*similar" test/### 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 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)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)## 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]
**Created:** YYYY-MM-DD
**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?
- [ ] Do we need to support IE11?
## 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 configUser 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 flowMust 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- Improve performance### 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 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## API Design
### Endpoint: POST /api/users
**Request:**
```json
{
"email": "user@example.com",
"name": "John Doe"
}{
"id": "123",
"email": "user@example.com",
"name": "John Doe",
"createdAt": "2024-01-01T00:00:00Z"
}
## Common Planning Mistakes
### ❌ Too Vague
### ❌ Too Detailed
### ❌ Missing Dependencies
### ❌ No Success Criteria
## 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
## 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
**Document changes:**
```markdown
## Plan Updates
**2024-01-15:** Added Task 3.1 - need to handle legacy data format
**2024-01-20:** Removed Task 2.3 - existing helper function covers this
**2024-01-22:** Increased Task 4 from S to M - more complex than expected