starwave:tasks

What this skill does

### 3. Create Task List

Create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.
The tasks document should be based on the requirement and design documents, so ensure these exists first.

**Constraints:**

**Feature Discovery:**
- The user provides the {feature_name} as part of the prompt, or by way of the current branch which will contain the name of the feature, either in whole or prefixed by specs/
- Verify that the specs/{feature_name} folder exists and has a requirements.md and design.md file
- If the folder does NOT exist, the model SHOULD check the current git branch and see if that matches an existing feature
- The model MUST request the user to provide the {feature_name} using the question "I can't find this feature, can you provide it again? Based on the git branch, I think it might be {found_name}"
- If the requirements.md or design.md file does not exist in the folder, the model MUST inform the user that they need to use the requirements and design skills to create these first
- If a decision_log.md file exists in the specs/{feature_name} folder, the decisions in there MUST be followed

**Task Planning Approach:**
- The model MUST create a 'specs/{feature_name}/tasks.md' file if it doesn't already exist
- Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner
- Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage
- Each prompt builds on the previous prompts, and ends with wiring things together
- There should be no hanging or orphaned code that isn't integrated into a previous step
- Focus ONLY on tasks that involve writing, modifying, or testing code

**Task Format Requirements:**
- The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:
  - Top-level items (like epics) should be used only when needed
  - Sub-tasks should be numbered with decimal notation (e.g., 1.1, 1.2, 2.1)
  - Each item must be a checkbox
  - Simple structure is preferred
- The model MAY optionally group tasks into phases for additional clarity:
  - Phases are optional organizational aids, not required
  - Common phase examples include: pre-work, implement changes, code cleanup, documentation
  - Phases should improve readability without adding unnecessary complexity
  - Tasks within phases still follow the same numbering and format requirements
- Each task item MUST include:
  - A clear objective as the task description that involves writing, modifying, or testing code
  - Additional information as sub-bullets under the task
  - Specific references to requirements from the requirements document (referencing granular sub-requirements, not just user stories)

**Task Content Requirements:**
- Each task MUST be actionable by a coding agent:
  - Involve writing, modifying, or testing specific code components
  - Specify what files or components need to be created or modified
  - Be concrete enough that a coding agent can execute them without additional clarification
  - Be scoped to specific coding activities (e.g., "Implement X function" rather than "Support X feature")
- Tasks MUST build incrementally on previous steps

**Task Granularity — No Inflation:**

A task represents a meaningful unit of work that moves the feature forward. Task lists bloat when agents fragment coherent changes into trivial substeps; this wastes execution time and obscures the real shape of the work.

- The model MUST NOT split a single coherent change into separate tasks for setup, implementation, and wiring when the work is small enough to be done together (e.g., do NOT create "create file", "add import", "add function stub", "implement body" as four tasks when they form one cohesive edit). The TDD pairing rule is the only mandated split — beyond it, combine.
- A task SHOULD be substantial enough that completing it represents recognisable progress. If a task takes only a line or two of code and has no independent test, it probably belongs merged into an adjacent task.
- Phases MUST NOT be added for decorative structure. Use phases only when they group genuinely distinct stages of work (e.g., schema migration before API changes). A single-phase list is preferable to invented phases.
- Streams MUST NOT be added when tasks cannot actually run in parallel. A single stream is the default; only split into multiple streams when independent work exists AND parallel execution is realistic.
- Task `details` sub-bullets MUST add decision-relevant information (file paths, behavioral constraints, edge cases to cover). They MUST NOT restate the task title, explain what a test is for, or describe obvious implementation steps.

- The model MUST use red/green TDD ordering for all implementation tasks:
  - **Red**: Write a failing test first that defines the expected behaviour (e.g., task 1.1 writes unit tests for the interface/function)
  - **Green**: Implement the minimum code to make the test pass (e.g., task 1.2 implements the function)
  - Every implementation task MUST be preceded by a test task that will initially fail against the unimplemented code
  - The test task and its corresponding implementation task MUST be adjacent and clearly paired (e.g., "1.1 Write tests for X" followed by "1.2 Implement X to pass tests")
  - Tasks that only modify configuration, types/interfaces, or wiring are exempt from requiring a preceding test task
- If the design specifies property-based testing for certain components, the model MUST include explicit tasks for writing property tests before or alongside unit tests for those components
- The plan MUST cover all aspects of the design that can be implemented through code
- All requirements MUST be covered by the implementation tasks
- If gaps are identified during implementation planning, the model MUST mention them and propose relevant changes to the requirements or design

**Task Dependencies:**
- The model MUST identify dependencies between tasks using `blocked_by` relationships
- A task that requires another task to be completed first MUST declare that dependency
- Common dependency patterns include:
  - Tests blocked by the interfaces/types they test
  - Integration code blocked by the components being integrated
  - Higher-level features blocked by lower-level building blocks
- Dependencies MUST be expressed as task IDs (e.g., `"blocked_by": ["1", "2"]`)
- Circular dependencies are not allowed and indicate a design problem

**Work Streams for Parallel Execution:**
- The model MUST analyze tasks to identify independent work streams that can be executed in parallel
- A work stream is a set of tasks that can be worked on independently from other streams
- Common stream patterns include:
  - Frontend vs Backend work
  - Different modules or components with no shared code
  - Independent features that don't interact
  - Test writing vs implementation (when tests can be written from interfaces)
- Tasks in the same stream should be numbered sequentially and share the same stream ID
- The default stream is 1; additional streams use 2, 3, etc.
- Tasks SHOULD be assigned to streams based on:
  - Code locality (same files/modules = same stream)
  - Logical grouping (related functionality = same stream)
  - Dependency chains (dependent tasks should generally be in the same stream)
- Cross-stream dependencies are allowed and enable coordination between parallel agents

**Task Exclusions:**
The model MUST NOT include the following types of non-coding tasks in the main tasks.md:
- User acceptance testing or user feedback gathering
- Deployment to production or staging environments
- Performance metrics gathering or analysis
- Running the application to test end to end flows (automated tests to test end-to-end flows from a user perspective are allowed)
- User training or documentation creation
- Business process changes or o