SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场speckit-tasks

speckit-tasks

编程与开发

查看项目

更新于 10-16 07:51

技能介绍

用途

speckit-tasks 用于在实现计划已经准备好之后，生成一份按依赖顺序排列的任务列表。当 plan.md 已就绪、需要把设计文档拆解为可执行的实现任务时使用它。若缺少计划文件，应提示用户先运行 speckit-plan。

输入

  • 必需：specs/<feature>/plan.md 与 specs/<feature>/spec.md
  • 可选制品：data-model.md、contracts/、research.md、quickstart.md
  • 用户请求中的约束或优先级

并非所有项目都包含全部文档，工具会基于现有内容生成任务。

工作流程

  1. Setup：在仓库根目录运行 .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 则提取决策用于 setup 任务；按用户故事组织任务；生成展示用户故事完成顺序的依赖图；为每个用户故事创建并行执行示例；校验任务完整性（每个用户故事都具备所需任务且可独立测试）。
  4. 生成 tasks.md：以 .specify/templates/tasks-template.md 为结构模板，填入正确的功能名称、Phase 1 Setup、Phase 2 Foundational、Phase 3+ 每个用户故事一个阶段（按 spec.md 优先级排列）、最终 Polish 阶段。每个阶段包含故事目标、独立测试标准、测试（如要求）、实现任务。所有任务必须遵循严格清单格式，每个任务有明确文件路径，并包含依赖关系章节、每个故事的并行执行示例、实现策略章节（MVP 先行、增量交付）。
  5. 报告：输出生成的 tasks.md 路径及摘要，包括任务总数、每个用户故事的任务数、识别出的并行机会、每个故事的独立测试标准、建议的 MVP 范围（通常是 User Story 1），并做格式校验，确认所有任务符合清单格式（复选框、ID、标签、文件路径）。

任务生成规则

  • 任务必须按用户故事组织，以支持独立实现与测试。
  • 测试是可选的：仅在功能规格中明确要求或用户要求 TDD 时生成测试任务。
  • 每个任务必须严格遵循格式：- [ ] [TaskID] [P?] [Story?] 描述+文件路径。
  • 复选框始终以 - [ ] 开头；Task ID 为按执行顺序的连续编号（T001、T002、T003…）；[P] 标记仅在任务可并行时添加（不同文件、不依赖未完成任务）；[Story] 标签仅用于用户故事阶段任务，格式为 [US1]、[US2]、[US3] 等，对应 spec.md 中的用户故事；Setup 阶段与 Foundational 阶段不加故事标签；Polish 阶段也不加故事标签；描述需明确动作并带准确文件路径。
  • 正确示例：- [ ] 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。
  • 错误示例：缺少 ID 与 Story 标签、缺少复选框、缺少 Task ID、缺少文件路径等写法均不符合要求。

任务组织

  • 用户故事（spec.md）为主要组织结构：每个用户故事（P1、P2、P3…）拥有独立阶段，把该故事所需的模型、服务、端点/UI 映射进去；若要求测试，则加入该故事专属测试；标注故事间依赖（多数故事应相互独立）。
  • 契约：把每个契约/端点映射到其服务的用户故事；若要求测试，则在该故事阶段中于实现之前加入契约测试任务 [P]。
  • 数据模型：把每个实体映射到需要它的用户故事；若实体服务多个故事，放在最早的故事或 Setup 阶段；关系映射为相应故事阶段的服务层任务。
  • Setup/基础设施：共享基础设施放入 Setup 阶段（Phase 1）；阻塞性/基础任务放入 Foundational 阶段（Phase 2）；故事专属的准备工作放在该故事阶段内。

阶段结构

  • Phase 1：Setup（项目初始化）
  • Phase 2：Foundational（阻塞性前置，必须在用户故事前完成）
  • Phase 3+：按优先级顺序（P1、P2、P3…）排列的用户故事；每个故事内部顺序为测试（如要求）→ 模型 → 服务 → 端点 → 集成
  • 每个阶段都应是完整、可独立测试的增量
  • 最终阶段：Polish 与横切关注点

输出与后续

输出为 specs/<feature>/tasks.md。任务生成后，可用 speckit-analyze 分析跨制品一致性，再用 speckit-implement 实现计划。

适用场景与限制

适用于已具备实现计划、需要把计划拆解为按用户故事组织、带依赖顺序与并行标记的任务清单的规格驱动开发流程。生成的 tasks.md 应可立即执行，每个任务需具体到 LLM 无需额外上下文即可完成。限制方面，本条目未提供收费、价格、平台或效果相关事实，暂未提供。