spec-kit-generate-tasks

Generate Tasks — Task Decomposition Skill

Purpose

Turn an approved technical plan (plan.md) into tasks.md: an ordered, dependency-aware, user-story-organized task list that spec-kit-execute-tasks can run — without writing product code here. This skill is the third link in the spec-kit chain (spec-kit-generate-spec → spec-kit-generate-plan → spec-kit-generate-tasks): it does not redesign the plan, it decomposes an already-approved plan into atomic, independently verifiable work.

The output is tasks.md plus checklists/tasks-quality.md. It does not implement product code, and it does not validate cross-artifact consistency in depth — that deeper check is spec-kit-analyze-consistency's job, when that skill is invoked.

User Input

$ARGUMENTS

Always consider the complete user message and any files or attachments available in the current conversation, even when $ARGUMENTS appears literally or is empty. The most common input is a reference to an existing feature directory or plan.md, with optional constraints ("only generate tasks for the MVP story", "skip test tasks").

Core Principle

Organize by user story, not by technical layer. A story is only complete when its checkpoint holds — closure is structural, not an afterthought.

• tasks.md is grouped by user story (R-US##, in Priority order P1 → P2 → P3), so each story is independently implementable, testable, and deliverable as an MVP increment.
• Every story's closing checkpoint is the mechanism that enforces "cierre de ciclos": a story only counts as done when it is functional and verifiable on its own — which excludes, by construction, leaving the system broken.
• Every task traces back to an operation in plan.md and a requirement/acceptance criterion in spec.md.

Non-Negotiable Rules

1. Do not invent facts. Never fabricate a file path, an existing helper, or a test framework convention not already verified in plan.md's Technical Context or Project Structure. Use verify-before-implement when a task needs a fact plan.md didn't already establish.
2. Preserve plan intent. Do not reinterpret, split, or merge an O-0# operation in a way that changes what plan.md decided. Decomposing into smaller tasks is expected; changing the approach is not.
3. Separate facts from assumptions. A task whose exact file path isn't yet verifiable is marked nuevo: <proposed path>, never presented as if the path is confirmed.
4. Surface conflicts. If decomposing an operation reveals it doesn't actually match spec.md/plan.md cleanly, report the mismatch — do not silently resolve it by picking whichever task shape is easiest to write.
5. Organize by user story — never a flat generic task list. Structure is always Setup → Foundational → one phase per R-US## in Priority order → Polish. An operation that doesn't belong cleanly to one story is assigned to the story that needs it first, with a forward dependency noted — never placed in an ad hoc "misc" phase.
6. No code before approval. tasks.md describes work; it does not contain product code.
7. No hollow tasks.md. Every task states a concrete action, a file (verified or explicitly proposed), a dependency (or "ninguna"), and an observable validation criterion. "Improve X" or "handle edge cases" without specifics is not a valid task.
8. Use verified project context. Reuse plan.md's Technical Context and Project Structure directly — do not re-derive the project's layout independently and risk disagreeing with it.
9. Keep scope controlled. No task introduces work absent from plan.md/spec.md. A gap found during decomposition is reported, not quietly filled with a "nice to have" task.
10. The Closure Rule is mandatory, not optional polish. Every user-story phase — and Setup/Foundational when it gates the whole feature — ends with an explicit [CIERRE] task (§ Closure Rule below). It is never omitted, never merged into a regular task, and never marked done by inference.
11. Safe Deferral consistency is enforced during decomposition. If plan.md's Safe Deferral table marks an operation Dormant for a later story, no task in an earlier story may invoke that deferred code path — doing so silently invalidates the Dormant classification. If this happens, report it as a conflict with plan.md, do not silently write the task anyway.
12. Every task is traceable. Each task cites the R-FR##/R-AC##/O-0# it satisfies.
13. Never claim readiness without validation. tasks.md is READY only after checklists/tasks-quality.md passes.
14. Generate portable agent pairs. If this workflow creates a task-decomposer (or other support agent), it must generate and validate both a Kiro CLI and a Claude Code definition per the shared portability contract.