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.

1. 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.

1. **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.

1. 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.

1. 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.

1. 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.

1. 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.)

1. 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.

1. 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."

1. 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).

1. 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.

1. 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.

1. 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.

1. 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.

Cross-Platform Agent Compatibility

The complete portability contract lives in spec-kit-shared/agent-portability.md. Before generating, validating, or reporting on the task-executor role — or any other agent this skill materializes — read that file completely and follow it exactly. If the active host cannot resolve the reference, follow its fallback section.

task-executor is the standard role for this skill: executing one independent task or user story in parallel with others. Do not invent a different name or redefine it for another purpose.

Artifact Conventions

The .speckit/ layout (including .speckit/specs//) and state.json schema live in spec-kit-shared/artifact-conventions.md. Read it before Fase 0 below.

Skill Delegation Map

This skill does not reimplement any of the following — it invokes them (or, on a host without nested skill invocation, follows their documented procedure directly, citing them, per the same pattern spec-kit-generate-spec uses for its Extension Hooks):

| Concern | Delegate to | When | | --- | --- | --- | | Implementation verification discipline | verify-before-implement | Before writing any task's code | | Project architecture/conventions | frontend-architecture / backend-api-standards / project-specific equivalent | Whenever the project has one active | | Commit messages | git-commits | After closing a cohesive group of tasks | | Documentation for new code | code-documentation | When a task or the project's own convention requires it | | Final safety-net review | pre-pr-review | Once, at the end, over the accumulated diff (§ Final Gate) |

Input Contract

Resolving the Target Tasks

1. If the user gave an explicit feature directory, tasks.md path, story, or task ID, use it.
2. Otherwise, read .speckit/feature.json for the active feature directory.
3. If neither resolves, stop and ask:

> Provide the feature directory, or a specific story/task, to execute. If you haven't generated > tasks yet, run spec-kit-generate-tasks first.

1. Read tasks.md, plan.md, spec.md, and checklists/tasks-quality.md completely.

Readiness Gate

• If tasks-quality.md's STATUS is READY, proceed.
• If it is DRAFT — NEEDS CLARIFICATION, stop and ask the user to either resolve the blocking

items upstream first, or explicitly confirm executing against a draft. Writing real code against an unresolved gap (as opposed to planning or task-listing against one) is the highest-risk point in this chain — if the user confirms anyway, record EXECUTED_FROM_DRAFT_TASKS: true and repeat the warning prominently in the Completion Report, and skip any task whose Validación or Archivo(s) depends directly on the unresolved item, reporting exactly which tasks were skipped and why, rather than implementing on top of a known-unresolved assumption.

Fase 0 — Staleness Check (every invocation)

Read spec-kit-sync-artifacts/SKILL.md and follow its full Phase 1/2 procedure across the whole chain: source documents → spec.md → plan.md → tasks.md. If it reports any drift:

1. If the drift is upstream of tasks.md (a source, spec.md, or plan.md changed since

tasks.md was generated), stop — do not execute against a tasks.md that might not reflect current intent. Recommend the nearest upstream skill per spec-kit-sync-artifacts's one-hop recommendation.

1. If spec-kit-sync-artifacts flagged any task as "closed work potentially affected," treat that exactly

as Rule 4 requires — it does not get silently re-executed just because this run touches nearby work.

1. Only proceed once the chain is confirmed consistent (or the user explicitly accepts executing

against a known, described gap — same discipline as the Readiness Gate above).

Workflow

Phase 1 — Determine Execution Order

Read tasks.md's phase structure: Setup → Foundational → one phase per user story (priority order) → Polish. Respect explicit Depende de citations within that order. If the user scoped this invocation to one story or task, still verify its dependencies (Setup/Foundational, and any earlier story it explicitly depends on) are already complete — do not execute a scoped task whose prerequisites were never done.

Phase 2 — Per-Task Execution

For each task, in order:

1. Read its Traza a / Archivo(s) / Depende de / Validación line completely.
2. Verify before implementing: identify which verify-before-implement §6 category this task

falls into (contract, model/schema, type/interface, endpoint integration, state/enum, config, library API, CLI) and complete that category's verification checklist against the actual codebase — not from memory, not from the task description alone.

1. If the project has an active architecture/convention skill relevant to this file, follow it as

a binding constraint (Rule 8).

1. Implement the change.
2. Run the task's Validación criterion for real — execute the test/command/manual check it

names, and read the actual output. Do not infer a pass from the code looking correct.

1. Mark the task [x] only after step 5 actually passed. If it didn't, do not mark it done — fix

the implementation and re-run, or stop and report the specific failure if it can't be resolved within this task's own scope.

Phase 3 — Parallel Execution (two levels)

Applied only where Rule 11's safety condition genuinely holds:

1. Between stories (primary parallelism unit): once Foundational's checkpoint holds,

independent story phases — no integration declared between them in tasks.md, no shared files — may be delegated to separate task-executor subagents in parallel, each scoped (Rule 12) to its own story plus the relevant plan.md/spec.md excerpts.

1. Within a story (secondary, finer-grained): [P]-tagged tasks with no cross-dependency and

no shared file may be parallelized the same way, delegated or not.

1. Tasks that share a file, or have a real dependency between them, always execute sequentially in

the same thread — parallelism is never forced onto a boundary that isn't actually independent.

1. After parallel branches complete, verify there is no cross-branch conflict (e.g. two branches

editing overlapping code unexpectedly) before treating the batch as done.

Phase 4 — Story Closure

When all of a story's implementation tasks are [x], execute its [CIERRE] task for real (Rule 6): walk each condition in its Verifica block against the actual current state of the code — not the task list — and only then mark [CIERRE] [x] and treat the story's checkpoint as held.

Phase 5 — Commit

When a cohesive group of tasks closes (typically: one story, or a clearly self-contained subset), use git-commits for the commit message — this skill never invents its own commit message format or convention.

Final Gate (before reporting done — always, in this order)

1. Closure re-verification: for every story completed in this run, re-confirm its [CIERRE]

task's conditions still hold against the final code state (Rule 6).

1. pre-pr-review over the accumulated diff — the last safety net, run unconditionally (Rule

10). If it returns pedir cambios or no aprobar hasta verificar X because a feature is incomplete or a deferral is unsafe or materially unverified, that is not just an immediate finding to resolve — it is a signal that spec-kit-generate-plan's Safe Deferral classification for the relevant operation was applied incorrectly (an operation that looked Dormant/Flagged/Additive turned out not to be, in practice). Resolve the finding or required verification before reporting done, and report the misclassification explicitly as feedback toward spec-kit-generate-plan.

Handling Unplanned Scope Discovered Mid-Execution

If implementing a task reveals a real requirement tasks.md doesn't cover (Rule 7):

1. Stop implementing that specific thread — do not improvise a fix for scope that was never

planned.

1. Report exactly what was found and why it wasn't anticipated.
2. Recommend the correct upstream response: spec-kit-generate-tasks (if plan.md already covers it and

only the task decomposition missed it) or spec-kit-analyze-consistency (if it's unclear whether plan.md/spec.md cover it at all).

1. Continue with other, unaffected tasks in the meantime if they don't depend on resolving this.

Re-invocation and Idempotency

Re-running this skill on a tasks.md with some tasks already [x]:

• Skips every [x] task by default (Rule 4).
• If the user explicitly names a closed task to redo, treat it as a fresh execution of that one

task (Phase 2 in full), and note in the Completion Report that previously-closed work was intentionally revisited, and why.

• Re-runs Fase 0 regardless — a re-invocation is exactly when drift is most likely to have

accumulated since the last run.

Pre-Execution Extension Hooks

Before execution, check .speckit/extensions.yml per spec-kit-shared/artifact-conventions.md's schema, reading hooks.before_execute. Follow the same enablement/condition/mandatory-vs-optional rules the other spec-kit skills use.

Mandatory Post-Execution Hooks

After execution, process hooks.after_execute the same way, using the same emit-then-execute format the other spec-kit skills use.

Completion Report

Report:

• SPECIFY_FEATURE_DIRECTORY: resolved feature directory.
• EXECUTED_FROM_DRAFT_TASKS: true if tasks.md was not READY when execution started.
• TASKS_COMPLETED / TASKS_SKIPPED (already closed) / TASKS_FAILED: counts, with IDs for the

latter two.

• STORIES_CLOSED: which story checkpoints were confirmed held this run.
• PARALLELISM_USED: none / between-stories / within-story, with which stories/tasks.
• COMMITS: list of commits made, each with its git-commits-formatted message.
• PRE_PR_REVIEW: summary of pre-pr-review's findings, and whether any indicated a Safe

Deferral misclassification to report upstream.

• UNPLANNED_SCOPE_FOUND: any gaps reported per § Handling Unplanned Scope, or "none".
• AGENTS: none, or every generated Kiro/Claude path with validation and parity status.
• NEXT: remaining stories/tasks if any, or "feature complete — ready for PR" if all closed and

pre-pr-review raised no blockers.

Done When

• [ ] tasks.md was resolved, read, and confirmed READY (or draft execution was explicitly

confirmed, with affected tasks skipped and reported).

• [ ] Fase 0's staleness check ran across the full chain before any code was written.
• [ ] E

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ErikaAX08
• Source: ErikaAX08/erikas-skills
• License: MIT
• Homepage: https://github.com/ErikaAX08/erikas-skills#readme

Install and usage instructions live in the source repository linked above.