Spec Kit Implement

Execute approved feature tasks in dependency order and keep tasks.md status accurate.

Invocation Notice

• Inform the user when this skill is being invoked by name: spec-kit-implement.

When to Use

• tasks.md exists and you need to execute it phase-by-phase to deliver the feature.
• Implementation work has started, but task sequencing, checklist gates, or progress tracking is inconsistent.
• You need deterministic execution behavior before handoff or release readiness checks.

When Not to Use

• tasks.md does not exist yet (spec-kit-tasks first).
• You are still writing or revising requirements/design artifacts (spec-kit-specify, spec-kit-clarify, spec-kit-plan).
• You need read-only consistency analysis rather than execution (spec-kit-analyze).
• You need coordinated artifact remediation after gaps are discovered (spec-kit-reconcile).

Router Fit

• Primary route from spec-kit after spec-kit-tasks.
• Requires planning + task artifacts for the active feature branch.
• Routes execution-discovered artifact drift to spec-kit-reconcile.

Preconditions

• Run from repository root (or a subdirectory inside it).
• Active feature context resolves to a single specs/<feature>/ directory.
• tasks.md reflects the current approved plan.md.

Workflow

1. Resolve feature artifacts and enforce implementation gate:

• Run scripts/check-prerequisites.sh --json --require-tasks --include-tasks exactly once.
• Parse FEATURE_DIR and AVAILABLE_DOCS.
• Derive:
• TASKS = FEATURE_DIR/tasks.md
• IMPL_PLAN = FEATURE_DIR/plan.md
• If prerequisites fail:
• missing tasks.md: stop and route to spec-kit-tasks
• missing plan.md: stop and route to spec-kit-plan

1. Enforce checklist gate when checklists exist:

• If FEATURE_DIR/checklists/ exists, scan all checklist files.
• If any unchecked items remain, stop and ask whether to proceed anyway.
• Continue only after explicit user approval.

1. Load execution context:

• Required: tasks.md, plan.md.
• Optional (when present): data-model.md, contracts/, research.md, quickstart.md.
• Use these artifacts as source of truth; do not invent scope beyond them.

1. Verify ignore-file coverage for active tooling:

• Check relevant ignore files (.gitignore, .dockerignore, .eslintignore, .prettierignore, etc.).
• Add only missing critical patterns; preserve existing user/project conventions.

1. Parse tasks.md into an execution plan before running tasks:

• Extract phase boundaries and phase intent (setup/foundational, user-story phases, polish).
• Extract per-task fields: task ID, description, file path, [P] marker, and optional [US#] label.
• Build dependency order from task IDs, phase ordering, and explicit sequencing notes.
• Treat this parsed structure as execution truth for progress and failure handling.

1. Execute tasks in phase order:

• Respect ordering and dependency constraints from tasks.md.
• Run [P] tasks in parallel only when there is no file overlap or dependency coupling.
• Follow tests-before-implementation ordering where test tasks exist.
• Complete each phase before moving to the next:
• setup/foundational work first,
• then user-story phases in priority order,
• polish and cross-cutting validation last.

1. Track progress and failures continuously:

• After each completed task, mark it [X] in tasks.md immediately.
• Halt on critical sequential task failures and report the blocking context.
• For parallel batches, keep successful items moving and report failed tasks with next actions.

1. Run completion checks:

• All required tasks are complete.
• Implementation aligns with spec.md/plan.md intent.
• Required tests/validation pass per project constraints.
• If gaps remain (for example missing wiring, acceptance mismatch, integration drift), route to spec-kit-reconcile with a concrete gap report.

1. Report implementation result:

• Absolute path to tasks.md.
• Completed vs remaining task counts.
• Checklist gate outcome (if used).
• Final status and recommended next step.

Output

• Updated tasks.md completion state for the active feature.
• Implementation progress summary with blockers/failures (if any).
• Final readiness signal for post-implementation verification/review.

Key Rules

• Treat tasks.md ordering as execution truth.
• Never mark a task [X] before its work and validations are complete.
• Do not run [P] tasks concurrently when they touch the same files or dependent resources.
• Stop and reroute when prerequisite artifacts are missing or invalid.
• Do not patch spec/plan/tasks ad hoc during execution; use spec-kit-reconcile for structured remediation.

Common Mistakes

• Starting implementation with stale or missing tasks.md.
• Skipping checklist acknowledgment when unresolved checklist items exist.
• Forgetting immediate [X] updates in tasks.md, causing drift between reality and artifact state.
• Running [P] tasks together despite file/dependency conflicts.
• Continuing past critical sequential failures instead of stopping and reporting.
• Editing spec.md/plan.md/tasks.md informally during implementation instead of routing remediation through spec-kit-reconcile.

References

• references/spec-kit-implement-flow.dot for implementation execution logic workflow
• references/spec-kit-workflow.dot for overall context of how the implementation fits into the Spec Kit process.
• scripts/check-prerequisites.sh
• https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/implement.md