Learn-skills.dev spec-kit-tasks

Use when an approved Spec Kit `plan.md` + `spec.md` must be decomposed into dependency-ordered `tasks.md`, or when `tasks.md` is missing/stale after planning or reconciliation changes.

install

source · Clone the upstream repo

git clone https://github.com/NeverSight/learn-skills.dev

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/NeverSight/learn-skills.dev "$T" && mkdir -p ~/.claude/skills && cp -r "$T/data/skills-md/ahgraber/skills/spec-kit-tasks" ~/.claude/skills/neversight-learn-skills-dev-spec-kit-tasks && rm -rf "$T"

manifest: data/skills-md/ahgraber/skills/spec-kit-tasks/SKILL.md

source content

Spec Kit Tasks

Generate an implementation-ready

tasks.md

from Spec Kit design artifacts.

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

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

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
```

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.
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.
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.
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.
Write
```
tasks.md
```
:
- Preserve heading order from the selected template.
- Replace template placeholders and sample content with concrete feature tasks.
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

Checkbox: ALWAYS start with
```
- [ ]
```
(markdown checkbox).
Task ID: Sequential number (
```
T001
```
,
```
T002
```
,
```
T003
```
, ...) in execution order.
[P]
marker: Include ONLY if the task is parallelizable (different files, no dependencies on incomplete tasks).
[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
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