tasks-planning

Original source / Raw SKILL.md

---
name: tasks-planning
description: Use during Phase 4 of spec creation to break specification into organized task groups with dependencies - analyzes requirements to determine natural groupings, presents structure for validation, and creates detailed actionable tasks
---

# Tasks Planning

## What It Does

1. Analyzes spec and requirements
2. Determines natural task groupings by layer/skill
3. Presents structure for validation
4. Creates detailed tasks.md with dependencies
5. Notes reusability and visual references

**Tasks are specific, verifiable, and ordered by dependencies.**

## The Process

### Step 1: Load Specification

```bash
SPEC="[provided by workflow]"

cat "$SPEC/spec.md"
cat "$SPEC/planning/requirements.md"
ls -la "$SPEC/planning/visuals/"
```

**Analyze:**
- Requirements and dependencies
- Technical layers (database, API, frontend)
- Existing code to leverage
- Visual designs to implement

### Step 2: Determine Task Groups

Identify natural groupings:

**Common patterns:**
- Database Layer (models, migrations)
- API Layer (controllers, routes, auth)
- Frontend Components (UI, forms, pages)
- Integration & Testing (end-to-end verification)

**Consider dependencies:**
- Database before API (API needs models)
- API before Frontend (Frontend needs endpoints)
- Implementation before Testing

**Present structure:**
```
Based on spec, I'm organizing tasks into:

1. **Database Layer**
   - Models, migrations, associations
   - Dependencies: None (foundation)

2. **API Layer**
   - Controllers, endpoints, auth
   - Dependencies: Database Layer

3. **Frontend Components**
   - UI, forms, pages
   - Dependencies: API Layer

4. **Integration & Testing**
   - End-to-end verification
   - Dependencies: All implementation

This follows dependency order: foundation → API → interface → verification

Does this grouping make sense, or organize differently?
```

**WAIT for confirmation.**

### Step 3: Present Task Breakdown

After grouping approved:

```
Detailed task breakdown:

## Task Group 1: Database Layer
**Dependencies:** None

- [ ] 1.0 Complete database layer
  - [ ] 1.1 Create [Model] with validations
    - Fields: [list]
    - Validations: [list]
    - Reuse pattern from: [existing if applicable]
  - [ ] 1.2 Create migration for [table]
    - Add indexes for: [fields]
    - Foreign keys: [relationships]
  - [ ] 1.3 Set up associations
    - [Model] has_many [related]
    - [Model] belongs_to [parent]

**Acceptance Criteria:**
- Models pass validation tests
- Migrations run successfully
- Associations work correctly

---

## Task Group 2: API Layer
**Dependencies:** Task Group 1

[Similar structure]

---

[Continue for all groups]

Does this breakdown capture all requirements?
```

**WAIT for confirmation.**

### Step 4: Create tasks.md

After breakdown approved:

```bash
cat > "$SPEC/tasks.md" <<'EOF'
# Task Breakdown: [Feature Name]

## Overview
Total Task Groups: [count]
Total Tasks: [count including sub-tasks]

## Task List

### Task Group 1: [Name]

#### Dependencies: [None or previous groups]

- [ ] 1.0 Complete [layer]
  - [ ] 1.1 [Implementation task]
    - [Specific details]
    - [Reuse pattern from: [existing code] if applicable]
  - [ ] 1.2 [Implementation task]
    - [Specific details]
  - [ ] 1.3 [Implementation task]
  - [ ] 1.4 [Implementation task]

**Acceptance Criteria:**
- [Functional criteria]
- [Technical criteria]
- [Quality criteria]

---

### Task Group 2: [Name]

#### Dependencies: Task Group 1

[Similar structure for each group]

---

## Execution Order

Recommended sequence:
1. Task Group 1: [Name] (Foundation)
2. Task Group 2: [Name] (Builds on 1)
3. Task Group 3: [Name] (Builds on 2)
4. Task Group 4: [Name] (Verification)

## Notes

- Tasks reference specific files/components from spec.md
- Reusability opportunities noted where applicable
- Visual assets referenced in frontend tasks
- Follow TDD: write tests for each component/behavior
EOF
```

### Step 5: Report Completion

```
✅ Task breakdown complete!

Created: tasks.md

Summary:
- [X] task groups by dependencies
- [Y] total tasks
- Execution order defined
- Acceptance criteria for each group

Structure:
- Specific and verifiable tasks
- Dependencies clearly marked
- Reusability notes included
- Visual references added (if applicable)

Ready for Phase 5: Verification
```

**Return to workflow.**

## Task Breakdown Principles

### Grouping Logic

**Group by layer AND skill:**
- Database tasks together (backend skills)
- API tasks together (backend + API design)
- Frontend tasks together (UI/UX + frontend)
- Testing together (integration + QA)

**Respect dependencies:**
- Foundation layers first
- Build progressively
- Verification last

### Task Granularity

**Good task size:** Completable in 1-4 hours

**Too granular:**
- ❌ "Add import statement"
- ❌ "Define variable"

**Too broad:**
- ❌ "Build authentication system"
- ❌ "Create all components"

**Just right:**
- ✅ "Create User model with validations"
- ✅ "Implement login API endpoint"
- ✅ "Build registration form component"

### Testing Approach

**Follow TDD naturally:**
- Write test for behavior
- Implement to pass test
- Refactor while green
- Repeat for next behavior

**Don't specify test counts** - write tests for each:
- Model method
- API endpoint
- UI component behavior
- Integration flow

Subagents following TDD will write appropriate tests.

## Adapting Structure

**API-heavy feature:**
```
1. Database Layer
2. API Endpoints
3. Authentication/Authorization
4. Frontend Integration
5. Integration Testing
```

**UI-heavy feature:**
```
1. Data Layer (if needed)
2. Component Library
3. Page Layouts
4. Interaction Flows
5. Integration Testing
```

**Background job:**
```
1. Data Models
2. Job Logic
3. Queue Configuration
4. Monitoring/Logging
5. Integration Testing
```

**Adapt to feature, but always:**
- Respect dependencies
- Include verification group
- Note reusability

## Red Flags

**Never:**
- Create vague tasks without specifics
- Omit dependencies
- Skip reusability notes when identified
- Forget visual references (if visuals exist)

**Always:**
- Make tasks specific and verifiable
- Note dependencies between groups
- Include reusability references
- Reference visual files in frontend tasks
- Define acceptance criteria per group

## Integration

**Called by:**
- `spec-creation-workflow` (Phase 4)

**Returns to:**
- `spec-creation-workflow`

**Creates:**
- `[spec]/tasks.md`

**Uses:**
- `spec.md` - Requirements and structure
- `planning/requirements.md` - Original requirements
- `planning/visuals/*` - Design assets

**Next phase uses:**
- `tasks.md` for verification