Speckit.Tasks

---
description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
handoffs:
  - label: Estimate Effort
    agent: speckit.estimate
    prompt: Estimate fibonacci complexity for each task
    send: true
  - label: Generate E2E Pipeline
    agent: speckit.e2e
    prompt: Generate E2E testing pipeline artifacts for this feature
    send: true
---

## User Input

```text
$ARGUMENTS

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

Outline

1. Setup: Run .specify/scripts/python/check_prerequisites.py --json from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. Use shell quoting per CLAUDE.md "Shell Script Compatibility".

   • Feature purpose: carry the one-line feature purpose from spec.md through this step.

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

3. Execute task generation workflow:

   • Load plan.md and extract tech stack, libraries, project structure
   • Load ## External Ingress + Runtime Readiness Gate from plan.md:
     • ERROR if this section is missing
     • Detect whether ingress/webhook/callback handling applies
     • If applicable, include T000 in Phase 1 and order all webhook registration/public URL/dependency provisioning tasks after T000
   • 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
   • Detect async/event-loop/background-worker integrations from plan.md and research.md
   • Detect human tasks: For each user story, identify any work requiring a human to act in an external system (configure a webhook URL, create an API key, set up a third-party workflow, provision infrastructure, etc.). Emit these as [H] tasks within the story phase, sequenced before the first implementation task. Each [H] task description must name the external system and the action. The runbook and verification command are generated in the HUD by speckit.estimate.
   • 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)
   • For each async integration path, include explicit guard tasks:
     • lifecycle implementation task (start/ready/timeout-cancel/shutdown/fail-safe cleanup),
     • regression test task exercising the path while an event loop is already running,
     • validation task asserting no orphan processes/tasks after execution.
   • For each live-vs-local state integration path, include explicit state-safety guard tasks:
     • source-of-truth and reconciliation invariant task (startup/reconnect/before-decision ordering),
     • regression test task for stale/orphan local state reconciliation,
     • validation task asserting no unresolved drift leaves local records active.
   • For each local DB mutation path that controls lifecycle/risk/financial state, include explicit transaction guard tasks:
     • transaction-boundary implementation task (atomic multi-step writes, commit/rollback semantics),
     • regression test task proving rollback/no-partial-write behavior on failure,
     • validation task asserting impossible/partial local lifecycle states cannot persist.

3b. Symbol annotation (MANDATORY before writing tasks.md):

• For each task identified in step 3, run mcp__codegraph__find_code for the primary symbol or file it will touch.
• Record the result as file:symbol pairs — stable identifiers that survive line number drift as earlier tasks are completed.
• If codegraph returns no match (new file/symbol not yet created), record the intended file path only — no symbol annotation needed.
• These annotations attach to the task description and become the input to speckit.implement's CodeGraph Recon step.

4. Generate tasks.md by pre-scaffolding from template:

   1. Run: uv run python .specify/scripts/pipeline-scaffold.py speckit.tasks --feature-dir $FEATURE_DIR FEATURE_NAME="[Feature Name]"
   • Pre-structures the file with Phase sections, Dependencies section, Parallel Opportunities section, etc.
   2. Fill in the scaffolded structure:
      • 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)

5. Run estimation (MANDATORY):

   • Immediately invoke /speckit.estimate after writing tasks.md.
   • Require FEATURE_DIR/estimates.md to exist before reporting completion.
   • If estimation identifies 8/13-point tasks, follow the estimate command's mandatory breakdown loop until those warnings are cleared.
   • If estimation cannot complete, stop and report the blocker (do not proceed to implementation-ready status).

6. Report: Output path to gener