/work-breakdown

name: work-breakdown
description: Break down features and requirements into actionable, implementable tasks with clear scope and acceptance criteria. Use when planning implementation, organizing complex work, or creating task lists. Trigger phrases: "break down tasks", "create work plan", "organize implementation", "plan development". This skill works best when preceded by `requirements-elicitation` skill use.

Work Breakdown

Key Capabilities

1. **Task Identification** — Identify discrete, implementable work units from high-level requirements 2. **Dependency Analysis** — Determine task order, relationships, and blocking dependencies 3. **Scope Definition** — Create clear, bounded task descriptions with acceptance criteria 4. **Phase Organization** — Group related tasks into logical implementation phases

Approach

1. Read and Understand Requirements

• Review the complete requirements document
• Understand the full scope and all success criteria
• Identify major components and subsystems affected
• Note security requirements and constraints

2. Identify System Components

• What parts of the codebase are affected?
• Which APIs, services, databases, UIs need changes?
• What external systems or dependencies are involved?
• Are multiple platforms affected (web, desktop, mobile, CLI)?

3. Break into Phases

Organize work into logical phases:

**Phase 1: Architecture & Design**

• Design system architecture and data models
• Create sequence diagrams, data flow diagrams
• Define API contracts and interfaces
• Security threat modeling (if applicable)

**Phase 2: Implementation**

• Core functionality development
• Database schema changes
• API endpoint creation
• UI component development
• Integration work

**Phase 3: Testing**

• Unit test development
• Integration test development
• End-to-end test scenarios
• Security testing (if applicable)
• Cross-platform verification

**Phase 4: Documentation & Deployment**

• User documentation
• API documentation
• Deployment procedures
• Migration scripts (if needed)

4. Define Individual Tasks

Each task should be:

• **Right-sized**: Completable in 2-8 hours (not days)
• **Independent**: Can be worked on without blocking on other incomplete tasks (except explicit dependencies)
• **Testable**: Has clear acceptance criteria that can be verified
• **Specific**: Clear description of what needs to be done
• **Assigned**: Identified role or team (e.g., "Backend team", "Security team", "QA")

5. Identify Dependencies

• What tasks must be completed before others can start?
• Are there parallel work streams that can proceed independently?
• What external dependencies exist (library updates, third-party APIs)?
• What approval gates are needed (security review, design review)?

6. Validate Completeness

• Do the tasks cover all functional requirements?
• Are non-functional requirements addressed (performance, security, reliability)?
• Is testing adequately planned?
• Is documentation included?
• Are verification commands/tests defined?

Task Template

Each task should follow this structure:

**Task X.Y**: [Concise task title]

- **Description**: [What needs to be done]
- **Team/Role**: [Backend | Frontend | Security | QA | DevOps]
- **Estimated Duration**: [2-8 hours]
- **Dependencies**: [Task IDs that must complete first, or "None"]
- **Deliverables**: [Specific outputs or changes]
- **Acceptance Criteria**: [How to verify completion]

Example

See `examples/oauth-authentication.md` for a complete worked example.

Best Practices

Do's

• ✅ **Right-size tasks** — 2-8 hours each, not full days or weeks
• ✅ **Clear acceptance criteria** — Must be testable and specific
• ✅ **Assign appropriate teams** — Match task to expertise
• ✅ **Group related tasks** — Organize into phases for clarity
• ✅ **Identify dependencies** — Make blocking relationships explicit
• ✅ **Ensure completeness** — All requirements covered, nothing orphaned
• ✅ **Include verification** — Testing and validation tasks for every feature
• ✅ **Plan documentation** — Technical and user docs are deliverables
• ✅ **Consider security** — Threat modeling and security testing included
• ✅ **Think cross-platform** — Bitwarden runs everywhere; plan for it

Don'ts

• ❌ **Tasks too large** — >1 day tasks should be broken down further
• ❌ **Vague acceptance criteria** — "Make it work" is not testable
• ❌ **Circular dependencies** — Tasks shouldn't block each other in loops
• ❌ **Missing phases** — Don't skip design, testing, or documentation
• ❌ **Unclear deliverables** — Every task should produce something concrete
• ❌ **Ignoring platforms** — Don't forget mobile, CLI, browser extensions
• ❌ **Skipping security** — Security tasks are not optional at Bitwarden

Output Format

Organize work breakdown in structured phases:

# Work Breakdown: [Feature Name]

## Summary

- **Total Estimated Duration**: X-Y hours
- **Number of Tasks**: N tasks across M phases
- **Teams Involved**: [List of teams]
- **Critical Path**: [Key dependencies or bottlenecks]

---

## Phase 1: [Phase Name]

**Goal**: [What this phase accomplishes]

**Task 1.1**: [Task title]

- **Description**: [What needs to be done]
- **Team/Role**: [Who does this]
- **Estimated Duration**: [Hours]
- **Dependencies**: [Prerequisites or "None"]
- **Deliverables**: [Concrete outputs]
- **Acceptance Criteria**: [How to verify]

**Task 1.2**: [Next task]
...

---

## Phase 2: [Phase Name]

...

---

## Verification

After all phases complete, verify:

- [ ] All functional requirements implemented
- [ ] All non-functional requirements met
- [ ] All security requirements addressed
- [ ] All tests passing (unit, integration, E2E)
- [ ] Documentation complete and accurate
- [ ] Deployment procedures tested