/kiro-spec-tasks

name: kiro-spec-tasks
description: Generate implementation tasks for a specification
metadata:
  shared-rules: "tasks-generation.md, tasks-parallel-analysis.md"

Implementation Tasks Generator

<background_information>

• **Success Criteria**:
• All requirements mapped to specific tasks
• Tasks properly sized (1-3 hours each)
• Clear task progression with proper hierarchy
• Natural language descriptions focused on capabilities
• A lightweight task-plan sanity review confirms the task graph is executable before `tasks.md` is written

</background_information>

<instructions>

Execution Steps

Step 1: Load Context

**Read all necessary context**:

• `{{KIRO_DIR}}/specs/$1/spec.json`, `requirements.md`, `design.md`
• `{{KIRO_DIR}}/specs/$1/tasks.md` (if exists, for merge mode)
• Core steering context: `product.md`, `tech.md`, `structure.md`
• Additional steering files only when directly relevant to requirements coverage, design boundaries, runtime prerequisites, or team conventions that affect task executability

**Validate approvals**:

• If `-y` flag provided: Auto-approve requirements and design in spec.json. Tasks approval is also handled automatically in Step 4.
• Otherwise: Verify both approved (stop if not, see Safety & Fallback)
• Determine sequential mode based on presence of `--sequential`

Step 2: Generate Implementation Tasks

**Load generation rules and template**:

• Read `rules/tasks-generation.md` from this skill's directory for principles
• If `sequential` is false: Read `rules/tasks-parallel-analysis.md` from this skill's directory for parallel judgement criteria
• Read `{{KIRO_DIR}}/settings/templates/specs/tasks.md` for format (supports `(P)` markers)

Parallel Research

The following research areas are independent and can be executed in parallel: 1. **Context loading**: Spec documents (requirements.md, design.md), steering files 2. **Rules loading**: tasks-generation.md, tasks-parallel-analysis.md, tasks template

If multi-agent is enabled, spawn sub-agents for each area above. Otherwise execute sequentially.

After all parallel research completes, synthesize findings before generating tasks.

**Generate task list following all rules**:

• Use language specified in spec.json
• Map all requirements to tasks
• When documenting requirement coverage, list numeric requirement IDs only (comma-separated) without descriptive suffixes, parentheses, translations, or free-form labels
• Ensure all design components included
• Verify task progression is logical and incremental
• Ensure each executable sub-task includes at least one detail bullet that states what "done" looks like in observable terms
• Keep normal implementation tasks within a single responsibility boundary; if work crosses boundaries, make it an explicit integration task
• Collapse single-subtask structures by promoting them to major tasks and avoid duplicating details on container-only major tasks (use template patterns accordingly)
• Apply `(P)` markers to tasks that satisfy parallel criteria (omit markers when sequential mode requested)
• Mark optional test coverage subtasks with `- [ ]*` only when they strictly cover acceptance criteria already satisfied by core implementation and can be deferred post-MVP
• If existing tasks.md found, merge with new content

Step 3: Review Task Plan

• Keep the draft task plan in working memory; do NOT write `tasks.md` yet
• Run the `Task Plan Review Gate` from `rules/tasks-generation.md`
• Review coverage:
• Every requirement ID appears in at least one task
• Every design component, contract, integration point, runtime prerequisite, and validation concern is represented
• Review executability:
• Each sub-task is an executable 1-3 hour work unit
• Each sub-task has a verifiable deliverable
• Each executable sub-task includes an observable completion bullet
• No implicit prerequisites remain hidden
• `_Depends:_`, `_Boundary:_`, and `(P)` markers still match the dependency graph and architecture boundaries
• If issues are task-plan-local, repair the draft and re-run the review gate before writing
• Keep the review bounded to at most 2 repair passes
• If review exposes a real requirements/design gap or contradiction, stop and send the user back to requirements/design instead of inventing filler tasks

Step 3.5: Run Task-Graph Sanity Review

Before writing `tasks.md`, run one lightweight independent sanity review of the task graph.

• If fresh subagent dispatch is available, spawn one fresh review subagent for this step. Otherwise perform the same review in the current context.
• Provide only file paths, the draft task plan, and merge context if an existing `tasks.md` is being updated. The reviewer should read `requirements.md`, `design.md`, and the task-generation rules directly instead of relying on a parent-synthesized coverage summary.
• Check only:
• hidden prerequisites or missing setup tasks
• dependency or ordering mistakes
• boundary overlap or ambiguous ownership between tasks
• tasks that are too large, too vague, cross boundaries without being explicit integration tasks, or are missing a verifiable deliverable
• contradictions introduced between requirements, design, and the task graph
• Return one verdict:
• `PASS`
• `NEEDS_FIXES`
• `RETURN_TO_DESIGN`
• If `NEEDS_FIXES`, repair the draft once and re-run the sanity review one time.
• If `RETURN_TO_DESIGN`, stop without writing `tasks.md` and point back to the exact gap in requirements/design.
• Keep this bounded. Do not turn it into a second full planning cycle.

Step 4: Finalize

**Write tasks.md**:

• Create/update `{{KIRO_DIR}}/specs/$1/tasks.md`
• Update spec.json metadata:
• Set `phase: "tasks-generated"`
• Set `approvals.tasks.generated: true, approved: false`
• Set `approvals.requirements.approved: true`
• Set `approvals.design.approved: true`
• Update `updated_at` timestamp

**Approval**:

• If auto-approve flag (`-y`) is provided: