User input
$ARGUMENTS
Youmustconsider the user input (if non-empty) before proceeding.
Outline
scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json
- Setup: Run from the repository root
{SCRIPT}and parse the FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in arguments, such as "I'm Groot", use the escape syntax: e.g. 'I'''m Groot' (or use double quotes 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/ (API endpoints), research.md (decisions), quickstart.md (test scenarios)
- Note: Not all projects have all documents. Generate tasks based on what is available.
-
Execute the task generation workflow:
- Load plan.md and extract the tech stack, libraries, project structure
- Load spec.md and extract user stories with priorities (P1, P2, P3, etc.)
- If data-model.md exists: extract entities and map them 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 (see the task generation rules below)
- Generate a dependency graph showing the user story completion order
- Create parallel execution examples for each user story
- Validate task completeness (each user story has the required tasks and can be tested independently)
-
Generate tasks.md: Use
.specify/templates/tasks-template.mdas the structure, and fill in:- Get the 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, ordered by priority in spec.md
- Each phase includes: story goal, independent test criteria, tests (if required), implementation tasks
- Final phase: Polish and cross-cutting concerns
- All tasks must follow a strict checklist format (see the task generation rules below)
- Explicit file paths for each task
- A dependencies section showing the story completion order
- Parallel execution examples for each story
- An implementation strategy section (MVP first, incremental delivery)
-
Report: Output the generated tasks.md path and summary:
- Total task count
- Task count per user story
- Identified parallel opportunities
- Independent test criteria for each story
- Suggested MVP scope (usually just user story 1)
- Format validation: Confirm that all tasks follow the checklist format (checkbox, ID, labels, file paths)
Provide context for task generation: {ARGS}
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 when explicitly required in the feature specification or when the user requests a TDD approach.
Checklist Format (Required)
Every task must strictly follow this format:
- [ ] [任务ID] [P?] [故事?] 带文件路径的描述
Format Components:
- Checkbox: Always start with
- [ ](markdown checkbox) - Task ID: Sequential number in execution order (T001, T002, T003...)
- [P] marker: Include only when the task can be parallelized (different files, does not depend on incomplete tasks)
- [Story] label: Required only for user story phase tasks
- Format: [US1], [US2], [US3], etc. (mapped to user stories in spec.md)
- Setup phase: no story label
- Foundational phase: no story label
- User story phase: must have story label
- Polish phase: no story label
- Description: Clear action with exact file path
Examples:
- ✅ Correct:
- [ ] T001 根据实现计划创建项目结构 - ✅ Correct:
- [ ] T005 [P] 在 src/middleware/auth.py 中实现认证中间件 - ✅ Correct:
- [ ] T012 [P] [US1] 在 src/models/user.py 中创建用户模型 - ✅ Correct:
- [ ] T014 [US1] 在 src/services/user_service.py 中实现 UserService - ❌ Incorrect:
- [ ] 创建用户模型(missing ID and story label) - ❌ Incorrect:
T001 [US1] 创建模型(missing checkbox) - ❌ Incorrect:
- [ ] [US1] 创建用户模型(missing task ID) - ❌ Incorrect:
- [ ] T001 [US1] 创建模型(missing file path)
Task Organization
-
From user stories (spec.md) - Primary organization:
- Each user story (P1, P2, P3...) has its own phase
- Map all relevant components to their stories:
- Models needed by that story
- Services needed by that story
- Endpoints/UI needed by that story
- If tests are required: specific tests for that story
- Mark story dependencies (most stories should be independent)
-
From contracts:
- Map each contract/endpoint → to the user story it serves
- If tests are required: each contract → contract test task [P] before implementation in that story phase
-
From data model:
- Map each entity to the user story that needs it
- If an entity serves multiple stories: place it in the earliest story or the setup phase
- Relationships → service layer tasks in the 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: Foundation (blocking prerequisites - must be completed before user stories)
- Phase 3+: User stories in priority order (P1, P2, P3...)
- Within each story: tests (if required) → models → services → endpoints → integration
- Each phase should be a complete, independently testable increment
- Final Phase: Polish and cross-cutting concerns