Spec-Kit Tasks

Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.

User Input

text

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Constitution Loading (REQUIRED)

Before ANY action, load and internalize the project constitution:

•

Read constitution:

bash

cat .specify/memory/constitution.md 2>/dev/null || echo "NO_CONSTITUTION"

•
If exists, parse all principles - especially those affecting task ordering (e.g., TDD requirements).

Prerequisites Check

•

Run prerequisites check:

bash

bash .tessl/tiles/tessl-labs/spec-kit/skills/speckit-01-specify/scripts/bash/check-prerequisites.sh --json

•
Parse JSON for FEATURE_DIR and AVAILABLE_DOCS.

•

If error or missing plan.md:

code

ERROR: plan.md not found in feature directory.

Run: /speckit-03-plan

Smart Validation

BEFORE generating tasks, perform validation:

Plan Completeness Gate

•

Tech Stack Validation:

•Verify plan.md has Language/Version defined (not "NEEDS CLARIFICATION")

•If missing:

code

WARNING: Tech stack undefined - tasks may be too generic.

Recommendation: Run /speckit-03-plan to define the tech stack.

•
User Story Mapping:
- •Extract all user stories from spec.md (P1, P2, P3...)
- •Verify each has clear acceptance criteria
- •
  If story lacks testable criteria:
  code
  WARNING: US-X has no testable acceptance criteria. Recommendation: Add acceptance scenarios to spec.md for this user story.
•
Dependency Pre-Analysis:
- •Identify shared entities from data-model.md
- •Flag entities used by multiple stories (potential blockers)
- •Suggest: "Entity X used by US1, US2, US3 - recommend Phase 2 (Foundational)"

Quality Report

code

╭─────────────────────────────────────────────╮
│  PLAN READINESS REPORT                      │
├─────────────────────────────────────────────┤
│  Tech Stack:       [Defined/Missing]   [✓/✗]│
│  User Stories:     X found with criteria    │
│  Shared Entities:  X (→ Foundational phase) │
│  API Contracts:    X endpoints defined      │
│  Research Items:   X decisions documented   │
├─────────────────────────────────────────────┤
│  TASK GENERATION: [READY/NEEDS WORK]        │
╰─────────────────────────────────────────────╯

Execution Flow

1. 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/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
•Optional: tests/test-specs.md (test specifications from /speckit-05-testify)

If tests/test-specs.md exists, tasks can reference specific test IDs:

•Example: "T012 [US1] Implement to pass test TS-001 and TS-002"
•This enables true TDD: tasks explicitly reference the tests they should satisfy

2. Tessl Convention Consultation (if tiles installed)

Purpose: Query installed Tessl tiles for framework conventions to improve file path generation and task ordering.

2.1 Check for Installed Tiles

Platform Detection:

•Unix/Linux/macOS: command -v tessl >/dev/null 2>&1
•Windows PowerShell: Get-Command tessl -ErrorAction SilentlyContinue

If Tessl NOT Available: Skip this section silently (no message needed, plan phase already informed user).

If Tessl Available:

code

mcp__tessl__status()

If no tiles are installed, skip to task generation.

2.2 Query Primary Framework Tile for Project Structure

If a tile is installed for the primary framework (e.g., React, Django, FastAPI, Express):

code

mcp__tessl__query_library_docs(query="project structure conventions for <framework>")

Apply conventions to:

•File path generation in tasks
•Module/package organization
•Naming conventions for files

2.3 Query Testing Framework Tile for Test Organization

If a tile is installed for the testing framework (e.g., pytest, Jest, Vitest):

code

mcp__tessl__query_library_docs(query="test organization patterns for <testing-framework>")

Apply patterns to:

•Test file naming and location
•Test task ordering within phases
•Fixture/helper organization

2.4 Document Applied Conventions

If conventions were queried and applied, note in task generation:

code

Tasks generated with Tessl conventions:
- File structure: <framework> standard layout
- Test organization: <testing-framework> patterns

3. Execute Task Generation

•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 endpoints to user stories
•If research.md exists: Extract decisions for setup tasks
•Generate tasks organized by user story
•Generate dependency graph showing user story completion order
•Create parallel execution examples per user story
•Validate task completeness

4. Task Format (REQUIRED)

Every task MUST strictly follow this format:

text

- [ ] [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)
•
[Story] label: REQUIRED for user story phase tasks only
- •Format: [US1], [US2], [US3], etc.
- •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)

5. 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 independently testable
•Final Phase: Polish & Cross-Cutting Concerns

6. 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
- •Endpoints/UI needed for that story
- •Tests specific to that story (if requested)
•Mark story dependencies

From Contracts:

•Map each contract/endpoint to the user story it serves
•Each contract -> contract test task [P] before implementation

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

From Setup/Infrastructure:

•Shared infrastructure -> Setup phase (Phase 1)
•Foundational/blocking tasks -> Foundational phase (Phase 2)
•Story-specific setup -> within that story's phase

7. Generate tasks.md

Use template structure with:

•Correct feature name from plan.md
•Phase 1: Setup tasks
•Phase 2: Foundational tasks
•Phase 3+: One phase per user story (in priority order)
•Final Phase: Polish & cross-cutting concerns
•Dependencies section
•Parallel execution examples
•Implementation strategy section (MVP first, incremental delivery)

8. Dependency Graph Validation

After generating tasks, validate the dependency graph:

•

Circular Dependency Detection:

Build task dependency graph and detect cycles using DFS:

Algorithm (DFS-based cycle detection):

code

1. Build adjacency list from task dependencies:
   - For each task with "blockedBy: [T00X, T00Y]", add edges T00X → task, T00Y → task
   - For each task with "blocks: [T00X]", add edge task → T00X

2. Initialize:
   - visited = {} (empty set)
   - recursion_stack = {} (empty set)
   - cycles = [] (empty list)

3. For each task_id in graph:
   if task_id not in visited:
      dfs_detect_cycle(task_id, visited, recursion_stack, path=[], cycles)

4. dfs_detect_cycle(node, visited, rec_stack, path, cycles):
   visited.add(node)
   rec_stack.add(node)
   path.append(node)

   for neighbor in graph[node]:
      if neighbor not in visited:
         dfs_detect_cycle(neighbor, visited, rec_stack, path, cycles)
      elif neighbor in rec_stack:
         # Cycle found! Extract cycle path
         cycle_start = path.index(neighbor)
         cycle = path[cycle_start:] + [neighbor]
         cycles.append(cycle)

   rec_stack.remove(node)
   path.pop()

5. Return cycles list

If cycles found:

code

ERROR: Circular dependency detected.

CIRCULAR DEPENDENCY: T005 → T012 → T008 → T005

Tasks involved:
- T005: [description]
- T012: [description]
- T008: [description]

Resolution options:
1. Remove one dependency to break the cycle
2. Merge tasks if they represent the same work
3. Reorder phases to resolve implicit dependencies

Cannot generate tasks.md until resolved.

•

Orphan Task Detection:

•Find tasks with no dependencies AND not blocking anything

•If orphans found:

code

WARNING: Orphan tasks detected: T015, T023

These tasks have no dependencies and don't block anything.
Verify they belong to the correct phase or add explicit dependencies.

•
Critical Path Analysis:
- •Identify longest dependency chain
- •Report: "Critical path: T001 → T003 → T012 → T018 (4 tasks)"
- •Suggest parallelization opportunities

•

Phase Boundary Validation:

•Ensure no cross-phase dependencies go backwards

•If backward dependency found:

code

ERROR: Invalid phase dependency.

T012 (Phase 3) depends on T018 (Phase 4).
Earlier phases cannot depend on later phases.

Resolution: Move T018 to Phase 3 or earlier, or remove the dependency.

•

Story Independence Check:

•Verify each user story phase CAN be implemented independently

•If higher-priority story depends on lower-priority:

code

WARNING: Priority inversion detected.

US2 (higher priority) depends on US3 tasks (lower priority).
This may indicate incorrect story prioritization.

Recommendation: Review story priorities or adjust dependencies.

Dependency Report

code

╭─────────────────────────────────────────────╮
│  DEPENDENCY GRAPH ANALYSIS                  │
├─────────────────────────────────────────────┤
│  Total Tasks:      X                        │
│  Circular Deps:    [None/X found]      [✓/✗]│
│  Orphan Tasks:     [None/X found]      [✓/!]│
│  Critical Path:    X tasks deep             │
│  Phase Boundaries: [Valid/X violations][✓/✗]│
│  Story Independence: [Yes/No]          [✓/✗]│
├─────────────────────────────────────────────┤
│  Parallel Opportunities: X task groups      │
│  Estimated Parallelism: X% speedup          │
╰─────────────────────────────────────────────╯

Report

Output:

•Path to generated tasks.md
•
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 confirmation

Semantic Diff on Re-run

If tasks.md already exists, perform semantic diff before overwriting:

1. Detect Existing Tasks

If tasks.md exists with task items:

•
Extract semantic elements:
- •Task IDs and descriptions
- •Phase structure
- •Completion status (checked/unchecked)
- •User story assignments
•
Preserve completion status:
- •Tasks marked [x] should remain completed
- •Map old task IDs to new task IDs by description similarity

•

Compare with new generation:

code

╭─────────────────────────────────────────────────────╮
│  SEMANTIC DIFF: tasks.md                            │
├─────────────────────────────────────────────────────┤
│  Tasks:                                             │
│    + Added: T025-T030 (new user story US4)          │
│    ~ Renamed: T012 description updated              │
│    - Removed: T008 (was for deleted FR-008)         │
│    ✓ Preserved: 15 completed tasks kept             │
│                                                     │
│  Phases:                                            │
│    + Added: Phase 5 (User Story 4)                  │
│    ~ Reordered: None                                │
├─────────────────────────────────────────────────────┤
│  COMPLETION STATUS:                                 │
│    Previously completed: 15 tasks                   │
│    Mapped to new tasks: 14 tasks                    │
│    Lost (task removed): 1 task                      │
╰─────────────────────────────────────────────────────╯

2. Smart Merge Strategy

•Completed tasks: Preserve completion status where possible
•New tasks: Add as uncompleted
•Removed tasks: Warn if they were completed (work may be lost)
•Reordered tasks: Maintain new order, preserve completion

3. Warn About In-Progress Work

If significant changes affect completed tasks:

code

⚠ WARNING: 3 completed tasks would be affected by regeneration.
Completed work that may need review:
- T008 [x] Create User model (task removed)
- T012 [x] Implement auth (description changed)

Proceed anyway? (yes/no)

Next Steps

After generating tasks:

•
Recommended: Run /speckit-07-analyze to validate cross-artifact consistency
- •Checks all user stories have corresponding tasks
- •Verifies all tasks trace back to requirements
- •Detects orphaned artifacts and constitution violations
- •Catches issues before implementation begins
•
Required: Run /speckit-08-implement to execute the implementation
- •Note: Requires all checklists to be 100% complete

Suggest to user:

code

Tasks generated! Next steps:
- /speckit-07-analyze - (Recommended) Validate consistency between spec, plan, and tasks
- /speckit-08-implement - Execute implementation (requires 100% checklist completion)