Story Tasks

The user input to you can be provided directly by the agent or as a command argument - you MUST consider it before proceeding with the prompt (if not empty).

User input:

$ARGUMENTS

⚠️ Step 0: Read Template First

Before any other action — read this template now using the Read tool:

.speck/​templates/​story/​tasks-template.md

The template defines required task format, ordering rules, parallel-marker syntax, and TDD structure for tasks.md. Without reading it, generated tasks will have wrong format. The template contains ALL formatting rules — do not reconstruct them from memory.

Checkpoint: After reading, note the required task format and any parallel markers. Then continue to Step 1.

1. Locate the active story directory (STORY_DIR):

   • Preferred: user is already in the story directory (or a subfolder like contracts/)
   • Determine STORY_DIR by walking up from current directory until you find spec.md
   • If no spec.md found: instruct user to cd into the story directory or run /​speck to route
   • Required inputs:
     • {STORY_DIR}/​spec.md
     • {STORY_DIR}/​plan.md (if missing: ERROR "Run /​story-plan first")
     • {STORY_DIR}/​ui-spec.md (REQUIRED if UI-heavy; generated by /​story-ui-spec AFTER /​story-plan and BEFORE /​story-tasks)

2. Load and analyze available design documents WITH DEEP EXTRACTION:

   CRITICAL: Read spec.md for complete requirements:

   • Extract ALL functional requirements (FR-XXX) with full text
   • Extract acceptance criteria from scenarios
   • Extract edge cases and clarification decisions
   • Extract performance targets from NFRs
   • Extract security/​privacy requirements
   • This is REQUIRED - spec.md is the source of truth for WHAT to build

   Always read plan.md for architecture and context:

   • Tech stack and libraries
   • Constitution compliance gates (specific implementation requirements)
   • Phase 1.5 Implementation Guidance section:
     • FR extraction table (use for FR → task mapping)
     • Research findings with code examples (use in task descriptions)
     • Codebase patterns to reuse (specify in tasks)
     • Performance optimization guide (include in relevant tasks)
     • Security implementation checklist (add to security tasks)
     • Design system component registry (specify components in UI tasks)
     • Brand voice copy bank (include copy examples in UI tasks)
     • Constitution gates (reference in affected tasks)

   IF EXISTS: Read data-model.md for entities:

   • Entity names, fields, relationships
   • Validation rules (include in implementation tasks)
   • Business rules and constraints (include in service tasks)

   IF EXISTS: Read contracts/​ for API endpoints:

   • Endpoint paths and methods
   • Request/​response schemas (include in test tasks)
   • Error responses (include in error handling tasks)

   IF EXISTS: Read quickstart.md for test scenarios:

   • Integration test scenarios
   • Validation steps (use as acceptance criteria in tasks)

   UI Spec Gate (if UI-heavy):

   • If this story includes UI components (forms/​pages/​interactive states) and {STORY_DIR}/​ui-spec.md is missing:
     • STOP and instruct the user to run /​story-ui-spec first
     • (UI spec is produced after /​story-plan, and is required before /​story-tasks for UI-heavy stories)

   IF EXISTS: Read ui-spec.md for UI implementation requirements:

   • States, variants, and responsive behavior
   • Accessibility requirements and keyboard interactions
   • Design tokens + component usage rules
   • Microcopy/​content guidelines
   • Visual Assets Manifest (Required Assets table) — Extract all declared assets (logos, SVGs, WebP illustrations)
   • Use these details to generate concrete UI tasks, including:
     • Specific Visual Asset Creation / Optimisation Tasks: If assets are declared in the ui-spec.md table, automatically generate concrete task(s) in the "Setup" or "Core" phase to create, hand-optimize, and verify each declared SVG or WebP file at its target path (e.g., [ ] T1.x: Create hand-optimized SVG asset ASSET-LOGO at public/​assets/​logo.svg).
     • UI component tasks with exact file paths and acceptance checks

   Load recipe visual testing config (if UI story; tight feedback loop):

   • Read specs/​projects/[PROJECT_ID]/​project.md frontmatter for _active_recipe:
   • If present, load .speck/​recipes/[recipe-name]/​recipe.yaml
   • Extract visual_testing: (platform/​strategy/​pattern_file/​breakpoints/​devices/​window_sizes/​agent_commands)
   • Use this to generate explicit tasks so visual testing is part of development (not just validation):
     • Add/​extend the platform’s visual test harness (per .cursor/​skills/​visual-testing-web/​SKILL.md (or platform-specific skill per pattern_file))
     • Add a visual smoke test for the 1–3 most impacted screens/​components
     • Ensure stable selectors/​keys exist (data-testid / RN testID / Flutter keys)
     • Add a baseline capture/​update step (snapshots/​goldens/​screenshots as appropriate)

   IF EXISTS: Read codebase-scan-*.md files for patterns:

   • Specific components to reuse with file:line references
   • Code examples showing how to use existing patterns
   • Anti-patterns to avoid
   • Testing patterns and fixture examples

   Note: Not all projects have all documents, but spec.md and plan.md are REQUIRED.

   Extract story dependencies from epic-breakdown.md:

   • Read {EPIC_DIR}/​epic-breakdown.md if exists
   • Find this story's entry and extract "Depends on:" field
   • Ensure these are present in spec.md YAML frontmatter as depends_on:
   • Also check for stories that depend on THIS story (for blocks: field)
   • Do NOT put depends_on/blocks in tasks.md frontmatter — tasks.md frontmatter is reserved for status: pending|in_progress|completed

3. Generate tasks.md:

   CRITICAL: Load and follow the template exactly:

   .speck/​templates/​story/​tasks-template.md
   

   The template contains ALL format rules, task generation rules, ordering guidelines, and enhanced task description format. Follow it precisely - validation will fail if the exact format is not used.

   Key template sections:

   • YAML front matter (status: pending|in_progress|completed)
   • FR → Task Mapping table
   • Enhanced task descriptions with context cards
   • Task generation rules and ordering
   • Validation checklist

   Apply extracted context (from step 2) when generating tasks:

   • Extracted FRs → FR → Task Mapping table
   • Extracted patterns → Pattern references in task descriptions
   • Extracted performance targets → Performance notes in tasks
   • Extracted security requirements → Security checklists in tasks
   • Extracted design components → Design System references in UI tasks
   • Extracted brand voice → Copy examples in UI tasks

   Write output to {STORY_DIR}/​tasks.md.

   The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it with the context provided in the task description (not requiring separate research).

4. Output summary:

   ✅ Story Tasks Generated!
   
   Feature: [Name]
   Total Tasks: [X]
   
   Task Breakdown:
   - Setup: [Y] tasks
   - Tests: [Z] tasks (marked [P] for parallel)
   - Core Implementation: [A] tasks
   - Integration: [B] tasks
   - Polish: [C] tasks
   
   Parallel Opportunities: [Count] tasks can run simultaneously
   
   FR Coverage: All [X] functional requirements mapped to tasks
   
   Next Steps:
   1. Review task breakdown
   2. ⚠️ REQUIRED: Run /​story-analyze (quality check - DO NOT SKIP)
   3. Then: /​story-implement (execute the tasks)
   4. Finally: /​story-validate (verify completion)
   
   Note: /​story-implement will execute these tasks in order,
   running parallel tasks [P] simultaneously for efficiency.