Back to Details

speckit-tasks

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Speckit Tasks Skill

Speckit Tasks Skill

Outline

概述

  1. Setup: Run 
    scripts/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/ (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 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
    • 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 
    references/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)
The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
  1. 环境准备：从仓库根目录运行
    scripts/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/（接口契约）、research.md（决策记录）、quickstart.md（测试场景）
    • 注意：并非所有项目都包含所有文档。根据可用文档生成任务。
  3. 执行任务生成流程：
    • 加载plan.md并提取技术栈、库、项目结构
    • 加载spec.md并提取带优先级的用户故事（P1、P2、P3等）
    • 如果存在data-model.md：提取实体并映射到用户故事
    • 如果存在contracts/：将接口契约映射到用户故事
    • 如果存在research.md：提取环境准备任务的决策记录
    • 根据用户故事组织生成任务（见下方任务生成规则）
    • 生成显示用户故事完成顺序的依赖关系图
    • 为每个用户故事生成并行执行示例
    • 验证任务完整性（每个用户故事包含所有必要任务，可独立测试）
  4. 生成tasks.md：以
    references/tasks-template.md
    为结构模板，填充以下内容：
    • 从plan.md中获取正确的功能名称
    • 阶段1：环境准备任务（项目初始化）
    • 阶段2：基础任务（所有用户故事的阻塞性前置条件）
    • 阶段3及以后：每个用户故事对应一个阶段（按spec.md中的优先级排序）
    • 每个阶段包含：故事目标、独立测试标准、测试（如有要求）、实施任务
    • 最终阶段：优化与横切关注点
    • 所有任务必须遵循严格的 checklist 格式（见下方任务生成规则）
    • 每个任务需包含清晰的文件路径
    • 依赖关系部分：显示故事完成顺序
    • 每个故事的并行执行示例
    • 实施策略部分（先做MVP，增量交付）
  5. 报告：输出生成的tasks.md路径及摘要：
    • 总任务数
    • 每个用户故事的任务数
    • 识别到的并行执行机会
    • 每个故事的独立测试标准
    • 建议的MVP范围（通常仅包含用户故事1）
    • 格式验证：确认所有任务均遵循checklist格式（复选框、ID、标签、文件路径）
生成的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?] Description with file path
格式组成：
  1. 复选框：必须以
    - [ ]
    开头（Markdown复选框）
  2. 任务ID：按执行顺序的连续编号（T001、T002、T003...）
  3. [P]标记：仅当任务可并行执行时包含（不同文件，不依赖未完成的任务）
  4. [Story]标签：仅用户故事阶段的任务需要
    • 格式：[US1]、[US2]、[US3]等（对应spec.md中的用户故事）
    • 环境准备阶段：无故事标签
    • 基础阶段：无故事标签
    • 用户故事阶段：必须有故事标签
    • 优化阶段：无故事标签
  5. 描述：清晰的操作，附带精确的文件路径
示例：
  • ✅ 正确：
    - [ ] T001 Create project structure per implementation plan
  • ✅ 正确：
    - [ ] T005 [P] Implement authentication middleware in src/middleware/auth.py
  • ✅ 正确：
    - [ ] T012 [P] [US1] Create User model in src/models/user.py
  • ✅ 正确：
    - [ ] T014 [US1] Implement UserService in src/services/user_service.py
  • ❌ 错误：
    - [ ] Create User model
    （缺少ID和故事标签）
  • ❌ 错误：
    T001 [US1] Create model
    （缺少复选框）
  • ❌ 错误：
    - [ ] [US1] Create User model
    （缺少任务ID）
  • ❌ 错误：
    - [ ] T001 [US1] Create model
    （缺少文件路径）

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
      • Interfaces/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 interface contract → to the user story it serves
    • If tests requested: Each interface 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...）
    • 每个故事阶段内：测试（如有要求）→模型→服务→端点→集成
    • 每个阶段应是一个完整的、可独立测试的增量
  • 最终阶段：优化与横切关注点