13 KiB
name, description, version
| name | description | version |
|---|---|---|
| Task Breakdown | This skill should be used when the user asks to "create tasks", "break down story into tasks", "define tasks", "what tasks are needed", "write acceptance criteria", or when they have user stories and need to decompose them into specific, executable tasks with clear acceptance criteria that can be created as GitHub issues in a GitHub Project. | 0.2.0 |
Task Breakdown
Overview
Task breakdown transforms user stories into concrete, executable work items that can be assigned, tracked, and completed. Tasks represent the actual implementation steps needed to deliver a user story, each with clear acceptance criteria. This skill guides the process of decomposing stories into well-defined tasks suitable for GitHub issue tracking.
Purpose
Tasks are the execution layer in the requirements hierarchy:
- Above: User Stories (user-facing functionality)
- Tasks: Specific implementation steps
- Below: (Nothing—tasks are the lowest level)
Well-defined tasks:
- Represent discrete units of work (hours to 1-2 days max)
- Have clear, testable acceptance criteria
- Can be assigned to individuals
- Track progress toward story completion
- Enable accurate status reporting
When to Use This Skill
Use task breakdown when:
- A user story exists and needs to be implemented
- User asks for specific work items or tasks
- Planning a sprint and need granular work breakdown
- Creating GitHub issues in a GitHub Project for tracking work
- Defining clear acceptance criteria for work items
Prerequisite: User story must exist before creating tasks. If no story exists, use user-story-creation skill first.
Task Characteristics
What Makes a Good Task
Specific and Concrete:
- Clear, unambiguous description
- Obvious what needs to be done
- No interpretation needed
Right-sized:
- 2-8 hours of work (up to 1-2 days maximum)
- Small enough to complete in a single sitting when possible
- Large enough to deliver meaningful progress
Testable:
- Has clear acceptance criteria
- Can verify when complete
- Observable outcome
Assignable:
- One person can own and complete it
- Doesn't require coordinating multiple people
Valuable:
- Contributes toward completing the story
- Represents real progress
Task Breakdown Process
Step 1: Review the User Story
Understand the story being implemented:
Key Actions:
- Read story issue in GitHub Projects
- Understand the user goal and value
- Review acceptance criteria
- Note any constraints or assumptions
Step 2: Identify Implementation Layers
Break down work by typical software layers:
Frontend/UI Tasks:
- Component creation
- UI layout and styling
- User interactions and events
- Client-side validation
- State management
Backend/API Tasks:
- API endpoint implementation
- Business logic
- Data validation
- Error handling
- Integration with services
Data/Database Tasks:
- Schema changes
- Migrations
- Data access layer
- Queries and optimization
Testing Tasks:
- Unit tests
- Integration tests
- E2E tests
- Manual test scenarios
Documentation Tasks:
- API documentation
- User-facing documentation
- Code comments
- README updates
DevOps/Infrastructure Tasks:
- Configuration changes
- Deployment scripts
- Environment setup
- Monitoring/logging
Step 3: Apply Common Task Patterns
Use these patterns as starting points:
CRUD Operations:
- Implement Create functionality
- Implement Read/List functionality
- Implement Update functionality
- Implement Delete functionality
- Add validation for each operation
Feature Implementation:
- Design and create UI components
- Implement backend API
- Connect frontend to backend
- Add error handling
- Write tests
- Update documentation
Integration:
- Research third-party API/service
- Implement authentication/connection
- Implement data mapping/transformation
- Handle errors and edge cases
- Test integration end-to-end
Step 4: Define Acceptance Criteria
For each task, specify clear success conditions:
Format:
Use specific, testable statements:
- "Component renders correctly with props X, Y, Z"
- "API endpoint returns 200 status with correct data structure"
- "Database migration runs without errors and creates table T"
- "Unit tests achieve >80% code coverage for module M"
Key Elements:
- What should exist/work when task is complete
- How to verify it works
- Any performance or quality standards
Step 5: Sequence and Dependencies
Order tasks logically:
Dependency Analysis:
- Which tasks must come first?
- What's the critical path?
- Can any tasks be done in parallel?
Typical Sequence:
- Data/schema changes (if needed)
- Backend implementation
- Frontend implementation
- Integration and testing
- Documentation
Mark Dependencies:
- Note which tasks block others
- Identify tasks that can start immediately
- Plan for parallel work when possible
Step 6: Create Task Issues in GitHub Projects
For each task, create a GitHub issue in the relevant GitHub Project:
Issue Title: "[Clear, action-oriented task description]"
Issue Description: Task details and acceptance criteria using template
Custom Fields:
- Type: Task
- Priority: (inherited from story)
- Status: Not Started
Labels:
type:task- Technical labels (frontend, backend, database, testing, docs)
Parent: Link to Story issue as parent
Estimate: (optional) Hour or story point estimate
Task Templates and Examples
Frontend Task Example
Title: "Create campaign filter UI component"
Description: Implement React component for filtering campaigns by date range.
Acceptance Criteria:
- Component accepts startDate and endDate props
- Renders two date picker inputs with labels
- Emits onChange event when dates are selected
- Validates that end date is not before start date
- Shows error message for invalid date ranges
- Component is responsive on mobile and desktop
- Unit tests cover all functionality
Technical Notes:
- Use existing DatePicker component from design system
- Follow component structure in /src/components/filters/
Backend Task Example
Title: "Implement GET /api/campaigns endpoint with date filtering"
Description: Create API endpoint that returns campaigns filtered by date range.
Acceptance Criteria:
- Endpoint accepts startDate and endDate query params
- Returns campaigns with activity between specified dates
- Returns 400 error if dates are invalid
- Returns 200 with empty array if no campaigns match
- Response follows standard campaign object schema
- Query is optimized with proper indexes
- Endpoint documented in API docs
Technical Notes:
- Use existing campaign repository pattern
- Add integration tests
Database Task Example
Title: "Add indexes for campaign date filtering performance"
Description: Create database indexes to optimize campaign date range queries.
Acceptance Criteria:
- Migration script creates index on campaigns.created_at
- Migration script creates composite index on (status, created_at)
- Migration runs successfully in dev environment
- Migration rollback script works correctly
- Query execution time reduced from >500ms to <100ms
- Migration documented in migrations/README.md
Testing Task Example
Title: "Write integration tests for campaign filtering"
Description: Create comprehensive integration tests for campaign date filtering feature.
Acceptance Criteria:
- Test successful filtering with valid date range
- Test error handling for invalid date range
- Test edge case: start date equals end date
- Test edge case: no campaigns in date range
- Test edge case: very large result set (1000+ campaigns)
- All tests pass in CI environment
- Test coverage for this feature is >90%
Documentation Task Example
Title: "Document campaign filtering in user guide"
Description: Add user-facing documentation for the new campaign filtering feature.
Acceptance Criteria:
- Section added to /docs/user-guide/campaigns.md
- Includes screenshots showing date filter UI
- Explains how to filter by date range
- Documents error messages and how to resolve them
- Includes example use cases
- Reviewed for clarity and accuracy
Best Practices
Keep Tasks Focused
One clear objective per task:
❌ "Implement campaign filtering and sorting and export" ✅ "Implement campaign date filtering" ✅ "Implement campaign sorting by name" ✅ "Implement campaign CSV export"
Use Action-Oriented Titles
Start with verbs:
Good:
- "Create campaign filter component"
- "Implement date validation logic"
- "Add database index for performance"
- "Write unit tests for filter module"
Poor:
- "Campaign filtering" (vague)
- "Database" (what about it?)
- "Tests" (what kind? for what?)
Include Technical Context
Help the implementer:
- Reference existing code patterns to follow
- Note relevant files or modules
- Mention design system components to use
- Link to related tasks or documentation
Balance Granularity
Not too big, not too small:
Too big: "Implement entire campaign management system" (this is a story or epic)
Too small: "Import React" (this is a substep, not a task)
Just right: "Create CampaignList component with sorting and filtering props"
Always Include Acceptance Criteria
Never create a task without clear success conditions:
- Minimum 3-5 criteria per task
- Make them specific and testable
- Include both functional and quality criteria
Task Types
Implementation Tasks
Primary work to build functionality:
- Create UI components
- Implement API endpoints
- Write business logic
- Build data access layer
Testing Tasks
Verify quality and correctness:
- Write unit tests
- Create integration tests
- Perform manual testing
- User acceptance testing
Documentation Tasks
Communicate how it works:
- API documentation
- User guides
- Code comments
- README updates
Infrastructure Tasks
Enable functionality:
- Database migrations
- Configuration changes
- Deployment scripts
- Environment setup
Research/Spike Tasks
Investigate unknowns:
- Evaluate libraries/tools
- Prototype approaches
- Performance testing
- Feasibility studies
Common Pitfalls to Avoid
Tasks Without Acceptance Criteria
Every task needs testable success conditions:
❌ "Work on campaign filtering" ✅ "Implement date filter UI" + 5 specific acceptance criteria
Tasks Too Large
Watch for multi-day or multi-person tasks:
- Split tasks larger than 2 days
- Each task should be completable by one person
- If coordination needed, it's probably too big
Mixing Concerns
One task, one focus area:
❌ "Implement filter UI and backend API and database schema" ✅ Three separate tasks for UI, API, and database
Vague Descriptions
Be specific about what needs to be done:
❌ "Fix bugs" ✅ "Fix date validation bug where end date before start date is allowed"
Missing Dependencies
Note what must be done first:
- Database schema before backend code
- Backend API before frontend integration
- Core functionality before tests (usually)
Integration with GitHub Issues (GitHub Projects)
Task Issue Format
Title: Clear, action-oriented description
Labels:
type:task- Technical area (frontend, backend, database, etc.)
- Priority (inherited from story)
Assignment: Person responsible
Estimate: Optional hours or points
Parent Link: User story issue
Acceptance Criteria: In issue description
Tracking Progress
Tasks enable granular progress tracking:
- Story progress = % of tasks complete
- Epic progress = % of stories complete (via tasks)
- Vision progress = % of epics complete (via stories → tasks)
Full traceability: Vision → Epic → Story → Task
Quick Reference: Task Breakdown Flow
- Review Story → Understand user goal, value, acceptance criteria
- Identify Layers → Frontend, backend, database, testing, docs, infrastructure
- Apply Patterns → Use common task patterns as starting points
- Define Acceptance Criteria → Specify testable success conditions for each task
- Sequence → Order tasks, note dependencies
- Create Issues → Add to GitHub Projects as children of story
- Assign → (Optional) Assign tasks to team members
- Execute → Begin work, update task status as progress is made
Additional Resources
Reference Files
For detailed task templates:
${CLAUDE_PLUGIN_ROOT}/skills/task-breakdown/references/task-template.md- Complete task template with acceptance criteria formats
Next Steps
After creating tasks:
- Create task issues in GitHub Projects (as children of story issue)
- Assign tasks to team members (if applicable)
- Begin execution—implement, test, document
- Update task status as work progresses
- When all tasks complete, story is complete
Tasks are where vision becomes reality—invest time to make them clear, testable, and actionable.