85 lines
3.2 KiB
Markdown
85 lines
3.2 KiB
Markdown
---
|
|
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
|