spec-kit-execute-tasks

Execute Tasks — Implementation Orchestration Skill

Purpose

Turn an approved tasks.md into real, working code — the only skill in spec-kit that writes product code. It is the last link in the chain (spec-kit-generate-spec → spec-kit-generate-plan → spec-kit-generate-tasks → [spec-kit-analyze-consistency] → spec-kit-execute-tasks), and it earns that position by delegating, not reimplementing: implementation discipline comes from verify-before-implement, commit messages from git-commits, architectural constraints from whatever architecture skills the project already has active, and a final safety-net review from pre-pr-review. This skill's own job is orchestration — sequencing, parallelism where it's genuinely safe, and enforcing that a story is never reported done unless its closure checkpoint actually holds.

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 inputs are: a feature directory or tasks.md path, optionally scoped to a single story ("just execute US1") or a single task ("redo T004").

Core Principle

Delegate discipline, don't reimplement it. A task is done when its own validation ran and passed — not when the code looks right. A story is done when its checkpoint holds, for real.

• Every category of change this skill touches (a contract, a model, a config value, a library call) already has a verification template in verify-before-implement — use it, don't write a weaker inline version.
• [x] is not a formatting convention, it's a claim: "this was verified, for real, right now."
• A story's [CIERRE] task is not skipped, inferred, or rubber-stamped — its Verifica block is walked explicitly before the story is reported complete.

Non-Negotiable Rules

1. Do not invent facts. Never write a field, endpoint, signature, config key, or library call without reading its actual definition first — apply verify-before-implement's matching §6 template for the category of change (contract, model, type, endpoint integration, state/enum, config, library API, CLI) before writing the corresponding code.
2. Preserve task and plan intent. Implement exactly what a task describes. If the real code makes the task's description stop making sense, surface the conflict (§ Handling Unplanned Scope) — do not quietly reinterpret the task to fit what's convenient.
3. A task is marked [x] only after its Validación criterion actually ran and was observed to pass — never by inference, never because the code compiles/type-checks, never because it "should work." Running a test means executing it and reading the output.
4. Never silently re-touch a task already marked [x] from a prior run. Re-invoking this skill skips already-closed tasks unless the user explicitly asks to redo/rework a specific one — this mirrors spec-kit-sync-artifacts'/spec-kit-generate-tasks's "closed work" rule, applied at execution time.
5. Fase 0's staleness check is mandatory before touching any code. If it reports drift with material impact anywhere in the chain, stop and require resolution before implementing — do not implement against a tasks.md that might already be stale.
6. A story's [CIERRE] task is executed for real, not skipped. Its Verifica conditions (no dangling references, no half-wired paths, full R-AC coverage) are walked explicitly before the story's checkpoint is considered held.
7. No new scope. If execution reveals a gap tasks.md doesn't cover, stop and report it — do not silently add a task, an endpoint, or a field to "make it work." (§ Handling Unplanned Scope.)
8. Respect the project's active architecture/convention skills as binding constraints, not suggestions — frontend-architecture, backend-api-standards, or an equivalent project- specific skill, when active, governs how code is written; this skill does not override them.
9. Commit messages follow git-commits exactly. Never invent a commit message format or skip that skill's conventions because "it's just a small change."
10. pre-pr-review runs at the end over the accumulated diff, always — not skipped even when every individual task's validation passed. It is the last safety net, not the first place a gap should be discovered (§ Final Gate).
11. Parallelism is a capability, applied only when genuinely safe — independent stories or [P] tasks with no shared file/state. Default to sequential execution; do not force parallelism where dependencies or shared files make it unsafe.
12. Every task-executor subagent gets scoped context — its task or story, plus the relevant plan.md/spec.md excerpts — never the full parent conversation history.
13. Never claim something was tested, verified, or committed when it wasn't actually done. "Tests pass" means they were run and their output was read.
14. Generate portable agent pairs. If this workflow creates a task-executor (or other support agent), it must generate and validate both a Kiro CLI and a Claude Code definition per the shared portability contract.