Back to Details

speckit-tasks

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spec Kit Tasks Skill

Spec Kit Tasks Skill

When to Use

使用场景

  • The implementation plan is ready and you need a dependency-ordered task list.
  • 当实施方案已确定，且你需要一份按依赖顺序排列的任务清单时。

Inputs

输入项

  • specs/<feature>/plan.md
    and 
    specs/<feature>/spec.md
  • Optional artifacts: 
    data-model.md
    , 
    contracts/
    , 
    research.md
    , 
    quickstart.md
  • Any user constraints or priorities from the request
If the plan is missing, ask the user to run speckit-plan first.
  • specs/<feature>/plan.md
    和 
    specs/<feature>/spec.md
  • 可选工件：
    data-model.md
    、
    contracts/
    、
    research.md
    、
    quickstart.md
  • 请求中包含的任何用户约束或优先级
如果缺少plan.md，请要求用户先运行speckit-plan。

Workflow

工作流程

  1. Setup: Run 
    .specify/scripts/bash/check-prerequisites.sh --json
    from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot").
  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/ (API endpoints), 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 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 (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)
  4. Generate tasks.md: Use 
    .specify/templates/tasks-template.md
    as structure, fill with:
    • 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. Report: Output path to generated tasks.md and 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: Confirm ALL tasks follow the checklist format (checkbox, ID, labels, file paths)
Context for task generation: the user's request and any stated priorities
The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
  1. 环境准备：从仓库根目录运行
    .specify/scripts/bash/check-prerequisites.sh --json
    ，并解析FEATURE_DIR和AVAILABLE_DOCS列表。所有路径必须为绝对路径。对于参数中的单引号（如"I'm Groot"），使用转义语法：例如'I'''m Groot'（或尽可能使用双引号："I'm Groot"）。
  2. 加载设计文档：从FEATURE_DIR中读取：
    • 必填项：plan.md（技术栈、库、项目结构）、spec.md（带优先级的用户故事）
    • 可选项：data-model.md（实体）、contracts/（API端点）、research.md（决策记录）、quickstart.md（测试场景）
    • 注意：并非所有项目都包含所有文档。根据可用内容生成任务。
  3. 执行任务生成工作流：
    • 加载plan.md并提取技术栈、库、项目结构
    • 加载spec.md并提取带优先级（P1、P2、P3等）的用户故事
    • 如果存在data-model.md：提取实体并映射到用户故事
    • 如果存在contracts/：将端点映射到用户故事
    • 如果存在research.md：提取用于准备任务的决策记录
    • 按用户故事组织生成任务（参见下方任务生成规则）
    • 生成显示用户故事完成顺序的依赖关系图
    • 为每个用户故事创建并行执行示例
    • 验证任务完整性（每个用户故事包含所有必要任务，且可独立测试）
  4. 生成tasks.md：以
    .specify/templates/tasks-template.md
    为结构，填充以下内容：
    • 从plan.md中获取正确的功能名称
    • 阶段1：准备任务（项目初始化）
    • 阶段2：基础任务（所有用户故事的阻塞前置条件）
    • 阶段3及以后：每个用户故事对应一个阶段（按spec.md中的优先级排序）
    • 每个阶段包含：故事目标、独立测试标准、测试（如果有要求）、实现任务
    • 最终阶段：优化与横切关注点
    • 所有任务必须遵循严格的清单格式（参见下方任务生成规则）
    • 每个任务的清晰文件路径
    • 显示故事完成顺序的依赖关系部分
    • 每个故事的并行执行示例
    • 实施策略部分（先做MVP，增量交付）
  5. 报告：输出生成的tasks.md路径和摘要：
    • 总任务数
    • 每个用户故事的任务数
    • 识别到的并行执行机会
    • 每个故事的独立测试标准
    • 建议的MVP范围（通常仅用户故事1）
    • 格式验证：确认所有任务都遵循清单格式（复选框、TaskID、标签、文件路径）
任务生成的上下文：用户的请求和任何已说明的优先级
生成的tasks.md应可立即执行——每个任务必须足够具体，无需额外上下文即可由LLM完成。

Task Generation Rules

任务生成规则

CRITICAL: Tasks MUST be organized by user story to enable independent implementation and testing.
Tests are OPTIONAL: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.
关键要求：任务必须按用户故事组织，以支持独立实现和测试。
测试为可选项：仅当功能规格中明确要求或用户请求TDD方法时，才生成测试任务。

Checklist Format (REQUIRED)

清单格式（必填）

Every task MUST strictly follow this format:
text
- [ ] [TaskID] [P?] [Story?] Description with file path
Format Components:
  1. Checkbox: ALWAYS start with 
    - [ ]
    (markdown checkbox)
  2. Task ID: Sequential number (T001, T002, T003...) in execution order
  3. [P] marker: Include ONLY if task is parallelizable (different files, no dependencies on incomplete tasks)
  4. [Story] label: REQUIRED for user story phase tasks only
    • Format: [US1], [US2], [US3], etc. (maps to user stories from spec.md)
    • Setup phase: NO story label
    • Foundational phase: NO story label
    • User Story phases: MUST have story label
    • Polish phase: NO story label
  5. 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)
  • ❌ WRONG: 
    - [ ] T001 [US1] Create model
    (missing file path)
每个任务必须严格遵循以下格式：
text
- [ ] [TaskID] [P?] [Story?] 带文件路径的描述
格式组成部分：
  1. 复选框：必须以
    - [ ]
    开头（Markdown复选框）
  2. TaskID：按执行顺序排列的序号（T001、T002、T003...）
  3. [P]标记：仅当任务可并行执行时包含（涉及不同文件，不依赖未完成的任务）
  4. [Story]标签：仅用户故事阶段的任务需要
    • 格式：[US1]、[US2]、[US3]等（与spec.md中的用户故事对应）
    • 准备阶段：无故事标签
    • 基础阶段：无故事标签
    • 用户故事阶段：必须有故事标签
    • 优化阶段：无故事标签
  5. 描述：清晰的操作说明及确切文件路径
示例：
  • ✅ 正确：
    - [ ] T001 根据实施方案创建项目结构
  • ✅ 正确：
    - [ ] T005 [P] 在src/middleware/auth.py中实现认证中间件
  • ✅ 正确：
    - [ ] T012 [P] [US1] 在src/models/user.py中创建User模型
  • ✅ 正确：
    - [ ] T014 [US1] 在src/services/user_service.py中实现UserService
  • ❌ 错误：
    - [ ] 创建User模型
    （缺少TaskID和故事标签）
  • ❌ 错误：
    T001 [US1] 创建模型
    （缺少复选框）
  • ❌ 错误：
    - [ ] [US1] 创建User模型
    （缺少TaskID）
  • ❌ 错误：
    - [ ] T001 [US1] 创建模型
    （缺少文件路径）

Task Organization

任务组织

  1. 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
      • If tests requested: Tests specific to 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 requested: Each contract → contract test task [P] before implementation in that story's phase
  3. 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 in 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
  1. 按用户故事（spec.md） - 主要组织方式：
    • 每个用户故事（P1、P2、P3...）对应一个独立阶段
    • 将所有相关组件映射到对应的故事：
      • 该故事所需的模型
      • 该故事所需的服务
      • 该故事所需的端点/UI
      • 如果要求测试：该故事专属的测试
    • 标记故事依赖关系（大多数故事应可独立执行）
  2. 按契约：
    • 将每个契约/端点映射到其服务的用户故事
    • 如果要求测试：在该故事阶段的实现任务之前，添加每个契约对应的可并行执行的契约测试任务[P]
  3. 按数据模型：
    • 将每个实体映射到需要它的用户故事（一个或多个）
    • 如果实体服务于多个故事：将其放在最早的故事或准备阶段
    • 关系映射到对应故事阶段的服务层任务
  4. 按准备/基础设施：
    • 共享基础设施 → 准备阶段（阶段1）
    • 基础/阻塞任务 → 基础阶段（阶段2）
    • 故事专属的准备工作 → 对应故事的阶段内

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 a complete, independently testable increment
  • Final Phase: Polish & Cross-Cutting Concerns
  • 阶段1：准备（项目初始化）
  • 阶段2：基础（阻塞性前置条件 - 必须在用户故事开始前完成）
  • 阶段3及以后：按优先级排序的用户故事（P1、P2、P3...）
    • 每个故事内部：测试（如果有要求）→ 模型 → 服务 → 端点 → 集成
    • 每个阶段应是一个完整的、可独立测试的增量版本
  • 最终阶段：优化与横切关注点

Outputs

输出项

  • specs/<feature>/tasks.md
  • specs/<feature>/tasks.md

Next Steps

后续步骤

After tasks are generated:
  • Analyze cross-artifact consistency with speckit-analyze.
  • Implement the plan with speckit-implement.
生成任务后：
  • 使用speckit-analyze分析跨工件的一致性。
  • 使用speckit-implement执行方案。