SuperAPI AI Directory

speckit-tasks-zh

Design & creation

View repository

Updated 10-15 21:46

About this skill

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

  1. 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").
  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)
    • Note: Not all projects have all documents. Generate tasks based on what is available.
  2. 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)
  3. Generate tasks.md: Use .specify/templates/tasks-template.md as 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)
  4. 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:

  1. Checkbox: Always start with - [ ] (markdown checkbox)
  2. Task ID: Sequential number in execution order (T001, T002, T003...)
  3. [P] marker: Include only when the task can be parallelized (different files, does not depend on incomplete tasks)
  4. [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
  5. 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

  1. 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)
  2. 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
  3. 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
  4. 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