---
allowed-tools: Bash(cat:*), Bash(test:*), Write
description: Create implementation task list
---

## Context

- Current spec: !`cat spec/.current 2>/dev/null || echo "No active spec"`
- Project context: @CLAUDE.md

## Your Task

### Phase 1: Validation

1. Verify that `spec/<current-spec>/spec.md` exists
2. If not found, inform the user to run `/spkl:spec` first

### Phase 2: Task Breakdown

Translate the spec into concrete, implementable tasks for human developers (not AI execution instructions):

- **From Requirements section**: Create concrete implementation tasks
- **From Dependencies section**: Understand context, but don't create "read X" tasks
- **From Constraints section**: Use to inform task creation, but don't duplicate them as tasks
- **From Done criteria**: Use to validate task completeness

**Structure:**
- Organize tasks into logical categories (e.g., "Core Models", "API Layer", "UI Components")
- Number categories sequentially (1, 2, 3, etc.)
- Number tasks within each category using decimal notation (1.1, 1.2, 1.3, etc.)
- Use markdown checkbox notation for each task: `- [ ] 1.1 Task description`
- Keep granularity appropriate (not too high-level, not overly detailed)
- Focus on **what** needs to be done, not **how** to do it

**Update behavior:**
- If `spec/<current-spec>/tasks.md` exists, overwrite with fresh task list (developers manually check off completed tasks)

- Save tasks to `spec/<current-spec>/tasks.md`

## Critical Constraints

- Do not include constraints, dependencies, or success criteria in the task list - those remain in the spec to guide implementation
- Test scenarios/validation may be included as tasks if helpful, but consolidate into broad validation areas rather than individual test cases

**Consolidation strategy for validation tasks:**
- Group by **system area** (e.g., "API versioning", "UI validation", "persistence")
- Group by **user flow** (e.g., "refund flows", "authentication flows")
- Typically aim for 3-5 validation tasks total, not 7+
- Example: Instead of separate tasks for "test full refund" and "test partial refund", use "Verify refund flows work correctly (full and partial)"

## Guidelines

- Tasks describe **what to build**, not implementation steps
- Avoid creating meta-tasks like "Read file X" or "Understand Y" (Dependencies section already lists these)
- Each task should be independently understandable and completable
- Tasks should map clearly back to Requirements in the spec

**Example format:**

```markdown
# <spec name>: Implementation Tasks

**1. Core Models**
- [ ] 1.1 Create RefundReason enum in transaction domain
- [ ] 1.2 Add refund_reason field to Refund model

**2. API Layer**
- [ ] 2.1 Update RefundRequest schema to include reason
- [ ] 2.2 Add validation for required reason field

**3. UI Components**
- [ ] 3.1 Add reason dropdown to refund form
- [ ] 3.2 Update refund confirmation to display selected reason

**4. Validation**
- [ ] 4.1 Verify refund flows work correctly (full and partial refunds)
- [ ] 4.2 Verify UI validation and display (dropdown, confirmation, history)
- [ ] 4.3 Verify refund reason persistence in transaction logs
```

## After Completion

- Confirm tasks were written to `spec/<current-spec>/tasks.md`
- Summarize the number of categories and tasks created