spec-kit-tasks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec Kit Tasks

Spec Kit 任务生成

Generate an implementation-ready

tasks.md

from Spec Kit design artifacts.

从Spec Kit设计工件生成可直接用于实现的

tasks.md

。

When to Use

使用场景

```
plan.md
```
and
```
spec.md
```
exist and you need executable tasks for implementation.
```
tasks.md
```
is missing, stale, or not aligned with current plan/spec artifacts (including post-
```
spec-kit-reconcile
```
updates).
You need user-story-scoped task phases with clear dependency and parallelization signals.

```
plan.md
```
和
```
spec.md
```
已存在，且你需要可执行的实现任务。
```
tasks.md
```
缺失、过时，或与当前的规划/规格工件（包括
```
spec-kit-reconcile
```
后的更新）不一致。
你需要按用户故事划分的任务阶段，并带有明确的依赖关系和并行执行标识。

When Not to Use

不适用场景

The feature spec is missing (
```
spec-kit-specify
```
first).
High-impact ambiguity still blocks design decisions (
```
spec-kit-clarify
```
first).
Technical design artifacts are not finalized (
```
spec-kit-plan
```
first).
You are executing tasks rather than generating them (
```
spec-kit-implement
```
).

功能规格缺失（请先执行
```
spec-kit-specify
```
）。
高影响的歧义仍在阻碍设计决策（请先执行
```
spec-kit-clarify
```
）。
技术设计工件尚未最终确定（请先执行
```
spec-kit-plan
```
）。
你正在执行任务而非生成任务（请使用
```
spec-kit-implement
```
）。

Router Fit

在工作流中的位置

Primary route from
```
spec-kit
```
after
```
spec-kit-plan
```
.
Must complete before
```
spec-kit-implement
```
.
Supports
```
spec-kit-analyze
```
and
```
spec-kit-reconcile
```
by producing structured implementation intent.

是
```
spec-kit
```
中
```
spec-kit-plan
```
之后的主要环节。
必须在
```
spec-kit-implement
```
之前完成。
通过生成结构化的实现意图，为
```
spec-kit-analyze
```
和
```
spec-kit-reconcile
```
提供支持。

Preconditions

前置条件

Run from repository root (or a subdirectory inside it).
Active feature context resolves to one
```
specs/<feature>/
```
directory.
```
plan.md
```
exists and reflects the latest approved design.

从仓库根目录（或其子目录）运行。
激活的功能上下文对应到一个
```
specs/<feature>/
```
目录。
```
plan.md
```
已存在且反映最新获批的设计。

Workflow

工作流程

Resolve feature paths and prerequisite gate:

Run
```
scripts/check-prerequisites.sh --json
```
exactly once.
Parse
```
FEATURE_DIR
```
and
```
AVAILABLE_DOCS
```
.

Derive:

```
FEATURE_SPEC = FEATURE_DIR/spec.md
```
```
IMPL_PLAN = FEATURE_DIR/plan.md
```
```
TASKS = FEATURE_DIR/tasks.md
```

If
```
spec.md
```
is missing, stop and route to
```
spec-kit-specify
```
then
```
spec-kit-plan
```
.

Load generation inputs:

Required:
```
plan.md
```
,
```
spec.md
```
.

Optional (when present):

research.md

data-model.md

contracts/

quickstart.md

Template preference:

```
{REPO_ROOT}/templates/tasks-template.md
```

{REPO_ROOT}/.specify/templates/tasks-template.md

fallback:
```
assets/tasks-template.md
```

Extract planning context:
- From
```
plan.md
```
  : stack, architecture, constraints, project structure.
- From
```
spec.md
```
  : prioritized user stories, acceptance criteria, independent test intent.
- From optional docs: shared entities, external interfaces, and setup decisions.
Build task phases:
- Phase 1: Setup.
- Phase 2: Foundational prerequisites blocking all stories.
- Phase 3+: one phase per user story in priority order.
- Final phase: Polish/cross-cutting concerns.
Generate tasks in strict checklist format:
- Required pattern:
```
- [ ] T### [P?] [US#?] Action with file path
```
  .
- Include
```
[US#]
```
  only for user-story phases.
- Include
```
[P]
```
  only when tasks can run safely in parallel.
- Include exact file paths in every implementation/test task description.
- Add test tasks only when explicitly requested by spec/user.
Validate coverage and ordering before writing:
- Every user story has independently testable tasks.
- Dependencies are explicit and respect phase order.
- Every task matches format requirements (checkbox, ID, labels, file path).
- No orphaned entities/contracts without mapped tasks.
Write
```
tasks.md
```
:
- Preserve heading order from the selected template.
- Replace template placeholders and sample content with concrete feature tasks.
Report completion:
- Absolute
```
tasks.md
```
  path.
- Total task count and per-story counts.
- Parallel opportunities.
- Suggested MVP slice (typically first priority story).
- Readiness handoff for
```
spec-kit-implement
```
  .

解析功能路径和前置检查：

精确运行一次
```
scripts/check-prerequisites.sh --json
```
。
解析
```
FEATURE_DIR
```
和
```
AVAILABLE_DOCS
```
。

推导：

```
FEATURE_SPEC = FEATURE_DIR/spec.md
```
```
IMPL_PLAN = FEATURE_DIR/plan.md
```
```
TASKS = FEATURE_DIR/tasks.md
```

如果
```
spec.md
```
缺失，停止并转向
```
spec-kit-specify
```
，之后再执行
```
spec-kit-plan
```
。

加载生成输入：

必填：
```
plan.md
```
、
```
spec.md
```
。

可选（若存在）：

research.md

、

data-model.md

、

contracts/

、

quickstart.md

。

模板优先级：

```
{REPO_ROOT}/templates/tasks-template.md
```

{REPO_ROOT}/.specify/templates/tasks-template.md

备选：
```
assets/tasks-template.md
```

提取规划上下文：
- 从
```
plan.md
```
  中提取：技术栈、架构、约束、项目结构。
- 从
```
spec.md
```
  中提取：按优先级排序的用户故事、验收标准、独立测试意图。
- 从可选文档中提取：共享实体、外部接口、以及初始化决策。
构建任务阶段：
- 阶段1：初始化设置。
- 阶段2：所有故事的基础前置依赖任务。
- 阶段3及以后：每个阶段对应一个按优先级排序的用户故事。
- 最终阶段：优化/跨领域关注点任务。
生成严格符合清单格式的任务：
- 必填格式：
```
- [ ] T### [P?] [US#?] 操作内容（含文件路径）
```
  。
- 仅在用户故事阶段的任务中包含
```
[US#]
```
  。
- 仅当任务可安全并行执行时包含
```
[P]
```
  。
- 每个实现/测试任务描述中必须包含精确的文件路径。
- 仅当规格/用户明确要求时才添加测试任务。
写入前验证覆盖范围和顺序：
- 每个用户故事都有可独立测试的任务。
- 依赖关系明确且符合阶段顺序。
- 每个任务都符合格式要求（复选框、ID、标签、文件路径）。
- 没有未映射到任务的孤立实体/契约。
写入
```
tasks.md
```
：
- 保留所选模板的标题顺序。
- 用具体的功能任务替换模板中的占位符和示例内容。
报告完成情况：
- ```
tasks.md
```
  的绝对路径。
- 总任务数和每个故事的任务数。
- 可并行执行的机会。
- 建议的MVP切片（通常是优先级最高的故事）。
- 为
```
spec-kit-implement
```
  做好交接准备。

Task Format Guidance

任务格式指南

Format Components

格式组成部分

Checkbox: ALWAYS start with
```
- [ ]
```
(markdown checkbox).
Task ID: Sequential number (
```
T001
```
,
```
T002
```
,
```
T003
```
, ...) in execution order.
[P]
marker: Include ONLY if the task is parallelizable (different files, no dependencies on incomplete tasks).
[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
Description: Clear action with exact file path.

复选框：必须以
```
- [ ]
```
（Markdown复选框）开头。
任务ID：按执行顺序的序列号（
```
T001
```
、
```
T002
```
、
```
T003
```
...）。
[P]
标记：仅当任务可并行执行时才包含（涉及不同文件，对未完成任务无依赖）。
[Story]
标签：仅在用户故事阶段的任务中必填。
- 格式：
```
[US1]
```
  、
```
[US2]
```
  、
```
[US3]
```
  等（对应
```
spec.md
```
  中的用户故事）。
- 初始化阶段：无故事标签。
- 基础阶段：无故事标签。
- 用户故事阶段：必须包含故事标签。
- 优化阶段：无故事标签。
描述：清晰的操作内容，包含精确的文件路径。

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 Task 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)

正确格式：

- [ ] T001 按实现规划创建项目结构

正确格式：

- [ ] T005 [P] 在src/middleware/auth.py中实现认证中间件

正确格式：

- [ ] T012 [P] [US1] 在src/models/user.py中创建User模型

正确格式：

- [ ] T014 [US1] 在src/services/user_service.py中实现UserService

错误格式：
```
- [ ] 创建User模型
```
（缺少任务ID和故事标签）
错误格式：
```
T001 [US1] 创建模型
```
（缺少复选框）
错误格式：
```
- [ ] [US1] 创建User模型
```
（缺少任务ID）
错误格式：
```
- [ ] T001 [US1] 创建模型
```
（缺少文件路径）

Output

输出内容

```
tasks.md
```
under the active feature directory with dependency-ordered, story-scoped tasks.
Completion summary with task counts, dependency highlights, and MVP recommendation.

激活功能目录下的
```
tasks.md
```
，包含按依赖顺序排列、按故事划分的任务。
完成总结，包含任务数量、依赖关系重点说明和MVP建议。

Key Rules

核心规则

Organize tasks by user story so each story can be implemented and validated independently.
Keep task granularity implementation-ready: no vague one-liners and no giant umbrella tasks.
Preserve execution truth in IDs and dependency order (
```
T001
```
,
```
T002
```
, ...).
Treat foundational work as blocking unless it is explicitly independent and parallel-safe.
Never invent tests by default; include test work only when requested.

按用户故事组织任务，使每个故事都能独立实现和验证。
任务粒度需达到可直接实现的程度：避免模糊的一句话任务，也不要过大的总括性任务。
任务ID和依赖顺序需反映真实的执行顺序（
```
T001
```
、
```
T002
```
...）。
除非明确说明是独立且可安全并行的，否则基础工作视为阻塞任务。
默认不生成测试任务；仅在明确要求时包含测试工作。

Common Mistakes

常见错误

Generating tasks from
```
spec.md
```
alone without using
```
plan.md
```
constraints.
Copying sample tasks from the template instead of replacing them.
Missing file paths or story labels in user-story phases.
Marking conflicting tasks as
```
[P]
```
even though they touch the same files/dependencies.
Producing tasks that cannot satisfy each story's independent test criteria.

仅从
```
spec.md
```
生成任务，未考虑
```
plan.md
```
的约束。
复制模板中的示例任务而不是替换为实际任务。
用户故事阶段的任务中缺少文件路径或故事标签。
即使任务涉及相同文件/依赖，仍将冲突任务标记为
```
[P]
```
。
生成的任务无法满足每个故事的独立测试标准。

References

参考资料

```
references/spec-kit-workflow.dot
```
for where task generation fits in the full Spec Kit sequence.
```
scripts/check-prerequisites.sh
```
```
assets/tasks-template.md
```

https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/tasks.md

```
references/spec-kit-workflow.dot
```
：展示任务生成在完整Spec Kit流程中的位置。
```
scripts/check-prerequisites.sh
```
```
assets/tasks-template.md
```

https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/tasks.md