speckit-tasks
npx machina-cli add skill h3y6e/speckit-skills/speckit-tasks --openclawSpeckit Tasks Skill
Outline
-
Setup: Run
scripts/check-prerequisites.sh --jsonfrom repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot"). -
Load design documents: Read from FEATURE_DIR:
- Required: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
- Optional: data-model.md (entities), contracts/ (interface contracts), research.md (decisions), quickstart.md (test scenarios)
- Note: Not all projects have all documents. Generate tasks based on what's available.
-
Execute task generation workflow:
- Load plan.md and extract tech stack, libraries, project structure
- Load spec.md and extract user stories with their priorities (P1, P2, P3, etc.)
- If data-model.md exists: Extract entities and map to user stories
- If contracts/ exists: Map interface contracts to user stories
- If research.md exists: Extract decisions for setup tasks
- Generate tasks organized by user story (see Task Generation Rules below)
- Generate dependency graph showing user story completion order
- Create parallel execution examples per user story
- Validate task completeness (each user story has all needed tasks, independently testable)
-
Generate tasks.md: Use
references/tasks-template.mdas structure, fill with:- Correct feature name from plan.md
- Phase 1: Setup tasks (project initialization)
- Phase 2: Foundational tasks (blocking prerequisites for all user stories)
- Phase 3+: One phase per user story (in priority order from spec.md)
- Each phase includes: story goal, independent test criteria, tests (if requested), implementation tasks
- Final Phase: Polish & cross-cutting concerns
- All tasks must follow the strict checklist format (see Task Generation Rules below)
- Clear file paths for each task
- Dependencies section showing story completion order
- Parallel execution examples per story
- Implementation strategy section (MVP first, incremental delivery)
-
Report: Output path to generated tasks.md and summary:
- Total task count
- Task count per user story
- Parallel opportunities identified
- Independent test criteria for each story
- Suggested MVP scope (typically just User Story 1)
- Format validation: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)
The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
Task Generation Rules
CRITICAL: Tasks MUST be organized by user story to enable independent implementation and testing.
Tests are OPTIONAL: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
Checklist Format (REQUIRED)
Every task MUST strictly follow this format:
- [ ] [TaskID] [P?] [Story?] Description with file path
Format Components:
- Checkbox: ALWAYS start with
- [ ](markdown checkbox) - Task ID: Sequential number (T001, T002, T003...) in execution order
- [P] marker: Include ONLY if 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 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)
Task Organization
-
From User Stories (spec.md) - PRIMARY ORGANIZATION:
- Each user story (P1, P2, P3...) gets its own phase
- Map all related components to their story:
- Models needed for that story
- Services needed for that story
- Interfaces/UI needed for that story
- If tests requested: Tests specific to that story
- Mark story dependencies (most stories should be independent)
-
From Contracts:
- Map each interface contract → to the user story it serves
- If tests requested: Each interface contract → contract test task [P] before implementation in that story's phase
-
From Data Model:
- Map each entity to the user story(ies) that need it
- If entity serves multiple stories: Put in earliest story or Setup phase
- Relationships → service layer tasks in appropriate story phase
-
From Setup/Infrastructure:
- Shared infrastructure → Setup phase (Phase 1)
- Foundational/blocking tasks → Foundational phase (Phase 2)
- Story-specific setup → within that story's phase
Phase Structure
- Phase 1: Setup (project initialization)
- Phase 2: Foundational (blocking prerequisites - MUST complete before user stories)
- Phase 3+: User Stories in priority order (P1, P2, P3...)
- Within each story: Tests (if requested) → Models → Services → Endpoints → Integration
- Each phase should be a complete, independently testable increment
- Final Phase: Polish & Cross-Cutting Concerns
Source
git clone https://github.com/h3y6e/speckit-skills/blob/main/skills/speckit-tasks/SKILL.mdView on GitHub Overview
Speckit Tasks automates turning design and planning documents into an executable tasks.md. It reads plan.md, spec.md, and optional docs (data-model.md, contracts/, research.md, quickstart.md) to generate a structured, dependency-aware task breakdown organized by user stories. The result is a ready-to-run, checkbox-based plan that supports MVP-first delivery and parallel workstreams.
How This Skill Works
The skill loads design docs from the FEATURE_DIR, extracts the tech stack and user stories from plan.md and spec.md, and maps entities and interface contracts when data-model.md or contracts/ exist. It then renders tasks.md using the references/tasks-template.md structure, organizing tasks into Phase 1 (Setup), Phase 2 (Foundational), and Phase 3+ (one phase per user story in priority order), plus a Final Polish phase. It also generates a dependency graph and parallel execution examples, ensuring every task adheres to the required checklist format.
When to Use It
- When starting a new feature with a well-defined plan and prioritized user stories.
- When you need a dependency-aware task breakdown that supports parallel work by multiple teams.
- When you want to generate a tasks.md directly from plan.md, spec.md, and optional design docs.
- When aiming for MVP-first delivery with incremental phases aligned to user story priorities.
- When you want built-in validation that every user story has complete, independently testable tasks.
Quick Start
- Step 1: Run prerequisites check from repo root and locate FEATURE_DIR and AVAILABLE_DOCS (absolute paths).
- Step 2: Load plan.md, spec.md, and any optional docs (data-model.md, contracts/, research.md, quickstart.md) to map stories and entities.
- Step 3: Generate tasks.md using references/tasks-template.md, review dependency graph, then validate all tasks follow the checklist format.
Best Practices
- Keep plan.md and spec.md up to date so generated tasks reflect current priorities and tech stack.
- Use absolute paths in all referenced documents as described in the Setup phase.
- Write tasks to be independent and testable within their user story phase.
- Include a clear dependency graph and parallel execution examples for each story.
- Verify that all tasks follow the strict checklist format (- [ ] [TaskID] [P?] [Story?] Description with file path).
Example Use Cases
- Generate a tasks.md for a new user-authentication feature, with Phase 3 tasks grouped under US1 based on the plan.md and spec.md.
- Create a tasks.md for a data-sync feature where data-model.md maps entities to user stories and contracts/define interfaces.
- Produce a task breakdown for a dashboard feature that references quickstart.md and research.md for tests and decisions.
- Build a TDD-aligned tasks.md where test tasks are included only if explicitly requested in the spec.
- Polish and cross-cutting concerns phase that addresses accessibility, logging, and observability across all user stories.