Spec Kit Tasks

Generate an implementation-ready tasks.md from Spec Kit design artifacts.

Invocation Notice

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

When to Use

• plan.md and spec.md exist and you need executable tasks for implementation.
• tasks.md is missing, stale, or not aligned with current plan/spec artifacts (including post-spec-kit-reconcile updates).
• You need user-story-scoped task phases with clear dependency and parallelization signals.

When Not to Use

• The feature spec is missing (spec-kit-specify first).
• High-impact ambiguity still blocks design decisions (spec-kit-clarify first).
• Technical design artifacts are not finalized (spec-kit-plan first).
• You are executing tasks rather than generating them (spec-kit-implement).

Router Fit

• Primary route from spec-kit after spec-kit-plan.
• Must complete before spec-kit-implement.
• Supports spec-kit-analyze and spec-kit-reconcile by producing structured implementation intent.

Preconditions

• Run from repository root (or a subdirectory inside it).
• Active feature context resolves to one specs/<feature>/ directory.
• plan.md exists and reflects the latest approved design.

Workflow

1. Resolve feature paths and prerequisite gate:

• Run scripts/check-prerequisites.sh --json exactly once.
• Parse FEATURE_DIR and AVAILABLE_DOCS.
• Derive:
• FEATURE_SPEC = FEATURE_DIR/spec.md
• IMPL_PLAN = FEATURE_DIR/plan.md
• TASKS = FEATURE_DIR/tasks.md
• If spec.md is missing, stop and route to spec-kit-specify then spec-kit-plan.

1. Load generation inputs:

• Required: plan.md, spec.md.
• Optional (when present): research.md, data-model.md, contracts/, quickstart.md.
• Template preference:
• {REPO_ROOT}/templates/tasks-template.md
• {REPO_ROOT}/.specify/templates/tasks-template.md
• fallback: assets/tasks-template.md

1. Extract planning context:

• From plan.md: stack, architecture, constraints, project structure.
• From spec.md: prioritized user stories, acceptance criteria, independent test intent.
• From optional docs: shared entities, external interfaces, and setup decisions.

1. Build task phases:

• Phase 1: Setup.
• Phase 2: Foundational prerequisites blocking all stories.
• Phase 3+: one phase per user story in priority order.
• Final phase: Polish/cross-cutting concerns.

1. Generate tasks in strict checklist format:

• Required pattern: - [ ] T### [P?] [US#?] Action with file path.
• Include [US#] only for user-story phases.
• Include [P] only when tasks can run safely in parallel.
• Include exact file paths in every implementation/test task description.
• Add test tasks only when explicitly requested by spec/user.

1. Validate coverage and ordering before writing:

• Every user story has independently testable tasks.
• Dependencies are explicit and respect phase order.
• Every task matches format requirements (checkbox, ID, labels, file path).
• No orphaned entities/contracts without mapped tasks.

1. Write tasks.md:

• Preserve heading order from the selected template.
• Replace template placeholders and sample content with concrete feature tasks.

1. Report completion:

• Absolute tasks.md path.
• Total task count and per-story counts.
• Parallel opportunities.
• Suggested MVP slice (typically first priority story).
• Readiness handoff for spec-kit-implement.

Task Format Guidance

Format Components

1. Checkbox: ALWAYS start with - [ ] (markdown checkbox).
2. Task ID: Sequential number (T001, T002, T003, ...) in execution order.
3. `[P]` marker: Include ONLY if the task is parallelizable (different files, no dependencies on incomplete tasks).
4. `[Story]` label: REQUIRED for user story phase tasks only.

• Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)
• Setup phase: no story label
• Foundational phase: no story label
• User story phases: MUST have story label
• Polish phase: no story label

1. Description: Clear action with exact file path.

Examples

• CORRECT: - [ ] T001 Create project structure per implementation plan
• CORRECT: - [ ] T005 [P] Implement authentication middleware in src/middleware/auth.py
• CORRECT: - [ ] T012 [P] [US1] Create User model in src/models/user.py
• CORRECT: - [ ] T014 [US1] Implement UserService in src/services/user_service.py
• WRONG: - [ ] Create User model (missing Task ID and Story label)
• WRONG: T001 [US1] Create model (missing checkbox)
• WRONG: - [ ] [US1] Create User model (missing Task ID)
• WRONG: - [ ] T001 [US1] Create model (missing file path)

Output

• tasks.md under the active feature directory with dependency-ordered, story-scoped tasks.
• Completion summary with task counts, dependency highlights, and MVP recommendation.

Key Rules

• Organize tasks by user story so each story can be implemented and validated independently.
• Keep task granularity implementation-ready: no vague one-liners and no giant umbrella tasks.
• Preserve execution truth in IDs and dependency order (T001, T002, ...).
• Treat foundational work as blocking unless it is explicitly independent and parallel-safe.
• Never invent tests by default; include test work only when requested.

Common Mistakes

• Generating tasks from spec.md alone without using plan.md constraints.
• Copying sample tasks from the template instead of replacing them.
• Missing file paths or story labels in user-story phases.
• Marking conflicting tasks as [P] even though they touch the same files/dependencies.
• Producing tasks that cannot satisfy each story's independent test criteria.

References

• references/spec-kit-workflow.dot for where task generation fits in the full Spec Kit sequence.
• scripts/check-prerequisites.sh
• assets/tasks-template.md
• https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/tasks.md