speckit-implement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec Kit Implement Skill

Spec Kit 实现 Skill

When to Use

适用场景

The plan and tasks are complete and you are ready to implement.

计划和任务已全部完成，准备开始实施工作。

Inputs

输入项

```
specs/<feature>/tasks.md
```
and
```
plan.md
```

Optional artifacts:

data-model.md

contracts/

research.md

quickstart.md

User constraints (e.g., scope, testing expectations)

If tasks are missing or incomplete, ask the user to run speckit-tasks first.

```
specs/<feature>/tasks.md
```
和
```
plan.md
```

可选工件：

data-model.md

、

contracts/

、

research.md

、

quickstart.md

用户约束条件（如范围、测试预期）

如果任务缺失或不完整，请要求用户先运行speckit-tasks。

Workflow

工作流程

Run
```
.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
```
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").
Check checklists status (if FEATURE_DIR/checklists/ exists):
- Scan all checklist files in the checklists/ directory
- For each checklist, count:
  - Total items: All lines matching
```
- [ ]
```
    or
```
- [X]
```
    or
```
- [x]
```
  - Completed items: Lines matching
```
- [X]
```
    or
```
- [x]
```
  - Incomplete items: Lines matching
```
- [ ]
```
- Create a status table:
  text
```
| Checklist | Total | Completed | Incomplete | Status |
|-----------|-------|-----------|------------|--------|
| ux.md     | 12    | 12        | 0          | ✓ PASS |
| test.md   | 8     | 5         | 3          | ✗ FAIL |
| security.md | 6   | 6         | 0          | ✓ PASS |
```
- Calculate overall status:
  - PASS: All checklists have 0 incomplete items
  - FAIL: One or more checklists have incomplete items
- If any checklist is incomplete:
  - Display the table with incomplete item counts
  - STOP and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
  - Wait for user response before continuing
  - If user says "no" or "wait" or "stop", halt execution
  - If user says "yes" or "proceed" or "continue", proceed to step 3
- If all checklists are complete:
  - Display the table showing all checklists passed
  - Automatically proceed to step 3
Load and analyze the implementation context:
- REQUIRED: Read tasks.md for the complete task list and execution plan
- REQUIRED: Read plan.md for tech stack, architecture, and file structure
- IF EXISTS: Read data-model.md for entities and relationships
- IF EXISTS: Read contracts/ for API specifications and test requirements
- IF EXISTS: Read research.md for technical decisions and constraints
- IF EXISTS: Read quickstart.md for integration scenarios
Project Setup Verification:
- REQUIRED: Create/verify ignore files based on actual project setup:
Detection & Creation Logic:
- Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):
  sh
```
git rev-parse --git-dir 2>/dev/null
```
- Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
- Check if .eslintrc* exists → create/verify .eslintignore
- Check if eslint.config.* exists → ensure the config's
```
ignores
```
  entries cover required patterns
- Check if .prettierrc* exists → create/verify .prettierignore
- Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
- Check if terraform files (*.tf) exist → create/verify .terraformignore
- Check if .helmignore needed (helm charts present) → create/verify .helmignore
If ignore file already exists: Verify it contains essential patterns, append missing critical patterns only If ignore file missing: Create with full pattern set for detected technology

Common Patterns by Technology (from plan.md tech stack):
- Node.js/JavaScript/TypeScript:
```
node_modules/
```
  ,
```
dist/
```
  ,
```
build/
```
  ,
```
*.log
```
  ,
```
.env*
```
- Python:
```
__pycache__/
```
  ,
```
*.pyc
```
  ,
```
.venv/
```
  ,
```
venv/
```
  ,
```
dist/
```
  ,
```
*.egg-info/
```
- Java:
```
target/
```
  ,
```
*.class
```
  ,
```
*.jar
```
  ,
```
.gradle/
```
  ,
```
build/
```
- C#/.NET:
```
bin/
```
  ,
```
obj/
```
  ,
```
*.user
```
  ,
```
*.suo
```
  ,
```
packages/
```
- Go:
```
*.exe
```
  ,
```
*.test
```
  ,
```
vendor/
```
  ,
```
*.out
```
- Ruby:
```
.bundle/
```
  ,
```
log/
```
  ,
```
tmp/
```
  ,
```
*.gem
```
  ,
```
vendor/bundle/
```
- PHP:
```
vendor/
```
  ,
```
*.log
```
  ,
```
*.cache
```
  ,
```
*.env
```
- Rust:
```
target/
```
  ,
```
debug/
```
  ,
```
release/
```
  ,
```
*.rs.bk
```
  ,
```
*.rlib
```
  ,
```
*.prof*
```
  ,
```
.idea/
```
  ,
```
*.log
```
  ,
```
.env*
```
- Kotlin:
```
build/
```
  ,
```
out/
```
  ,
```
.gradle/
```
  ,
```
.idea/
```
  ,
```
*.class
```
  ,
```
*.jar
```
  ,
```
*.iml
```
  ,
```
*.log
```
  ,
```
.env*
```
- C++:
```
build/
```
  ,
```
bin/
```
  ,
```
obj/
```
  ,
```
out/
```
  ,
```
*.o
```
  ,
```
*.so
```
  ,
```
*.a
```
  ,
```
*.exe
```
  ,
```
*.dll
```
  ,
```
.idea/
```
  ,
```
*.log
```
  ,
```
.env*
```
- C:
```
build/
```
  ,
```
bin/
```
  ,
```
obj/
```
  ,
```
out/
```
  ,
```
*.o
```
  ,
```
*.a
```
  ,
```
*.so
```
  ,
```
*.exe
```
  ,
```
Makefile
```
  ,
```
config.log
```
  ,
```
.idea/
```
  ,
```
*.log
```
  ,
```
.env*
```
- Swift:
```
.build/
```
  ,
```
DerivedData/
```
  ,
```
*.swiftpm/
```
  ,
```
Packages/
```
- R:
```
.Rproj.user/
```
  ,
```
.Rhistory
```
  ,
```
.RData
```
  ,
```
.Ruserdata
```
  ,
```
*.Rproj
```
  ,
```
packrat/
```
  ,
```
renv/
```
- Universal:
```
.DS_Store
```
  ,
```
Thumbs.db
```
  ,
```
*.tmp
```
  ,
```
*.swp
```
  ,
```
.vscode/
```
  ,
```
.idea/
```
Tool-Specific Patterns:
- Docker:
```
node_modules/
```
  ,
```
.git/
```
  ,
```
Dockerfile*
```
  ,
```
.dockerignore
```
  ,
```
*.log*
```
  ,
```
.env*
```
  ,
```
coverage/
```
- ESLint:
```
node_modules/
```
  ,
```
dist/
```
  ,
```
build/
```
  ,
```
coverage/
```
  ,
```
*.min.js
```
- Prettier:
```
node_modules/
```
  ,
```
dist/
```
  ,
```
build/
```
  ,
```
coverage/
```
  ,
```
package-lock.json
```
  ,
```
yarn.lock
```
  ,
```
pnpm-lock.yaml
```
- Terraform:
```
.terraform/
```
  ,
```
*.tfstate*
```
  ,
```
*.tfvars
```
  ,
```
.terraform.lock.hcl
```
- Kubernetes/k8s:
```
*.secret.yaml
```
  ,
```
secrets/
```
  ,
```
.kube/
```
  ,
```
kubeconfig*
```
  ,
```
*.key
```
  ,
```
*.crt
```
Parse tasks.md structure and extract:
- Task phases: Setup, Tests, Core, Integration, Polish
- Task dependencies: Sequential vs parallel execution rules
- Task details: ID, description, file paths, parallel markers [P]
- Execution flow: Order and dependency requirements
Execute implementation following the task plan:
- Phase-by-phase execution: Complete each phase before moving to the next
- Respect dependencies: Run sequential tasks in order, parallel tasks [P] can run together
- Follow TDD approach: Execute test tasks before their corresponding implementation tasks
- File-based coordination: Tasks affecting the same files must run sequentially
- Validation checkpoints: Verify each phase completion before proceeding
Implementation execution rules:
- Setup first: Initialize project structure, dependencies, configuration
- Tests before code: If you need to write tests for contracts, entities, and integration scenarios
- Core development: Implement models, services, CLI commands, endpoints
- Integration work: Database connections, middleware, logging, external services
- Polish and validation: Unit tests, performance optimization, documentation
Progress tracking and error handling:
- Report progress after each completed task
- Halt execution if any non-parallel task fails
- For parallel tasks [P], continue with successful tasks, report failed ones
- Provide clear error messages with context for debugging
- Suggest next steps if implementation cannot proceed
- IMPORTANT For completed tasks, make sure to mark the task off as [X] in the tasks file.
Completion validation:
- Verify all required tasks are completed
- Check that implemented features match the original specification
- Validate that tests pass and coverage meets requirements
- Confirm the implementation follows the technical plan
- Report final status with summary of completed work

Note: This skill assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running speckit-tasks first to regenerate the task list.

从仓库根目录运行
```
.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
```
，并解析FEATURE_DIR和AVAILABLE_DOCS列表。所有路径必须为绝对路径。对于参数中的单引号（如"I'm Groot"），使用转义语法：例如 'I'''m Groot'（或尽可能使用双引号："I'm Groot"）。
检查检查清单状态（若FEATURE_DIR/checklists/存在）：
- 扫描checklists/目录下的所有检查清单文件
- 对每个检查清单，统计：
  - 总项数：所有匹配
```
- [ ]
```
    、
```
- [X]
```
    或
```
- [x]
```
    的行
  - 已完成项数：匹配
```
- [X]
```
    或
```
- [x]
```
    的行
  - 未完成项数：匹配
```
- [ ]
```
    的行
- 创建状态表格：
  text
```
| 检查清单 | 总项数 | 已完成 | 未完成 | 状态 |
|-----------|-------|-----------|------------|--------|
| ux.md     | 12    | 12        | 0          | ✓ 通过 |
| test.md   | 8     | 5         | 3          | ✗ 失败 |
| security.md | 6   | 6         | 0          | ✓ 通过 |
```
- 计算整体状态：
  - 通过：所有检查清单的未完成项数为0
  - 失败：至少一个检查清单存在未完成项
- 若存在未完成的检查清单：
  - 显示包含未完成项数的表格
  - 停止执行并询问："部分检查清单未完成。是否仍要继续实施？(是/否)"
  - 等待用户回复后再继续
  - 若用户回复"否"、"等待"或"停止"，则终止执行
  - 若用户回复"是"、"继续"或"推进"，则进入步骤3
- 若所有检查清单已完成：
  - 显示所有检查清单均通过的表格
  - 自动进入步骤3
加载并分析实施上下文：
- 必填：读取tasks.md获取完整任务列表和执行计划
- 必填：读取plan.md获取技术栈、架构和文件结构
- 若存在：读取data-model.md获取实体及关系
- 若存在：读取contracts/获取API规范和测试要求
- 若存在：读取research.md获取技术决策和约束条件
- 若存在：读取quickstart.md获取集成场景
项目配置验证：
- 必填：根据实际项目配置创建/验证忽略文件：
检测与创建逻辑：
- 执行以下命令判断仓库是否为git仓库（若是则创建/验证.gitignore）：
  sh
```
git rev-parse --git-dir 2>/dev/null
```
- 检查是否存在Dockerfile* 或 plan.md中提及Docker → 创建/验证.dockerignore
- 检查是否存在.eslintrc* → 创建/验证.eslintignore
- 检查是否存在eslint.config.* → 确保配置中的
```
ignores
```
  条目覆盖所需规则
- 检查是否存在.prettierrc* → 创建/验证.prettierignore
- 检查是否存在.npmrc或package.json → 若要发布则创建/验证.npmignore
- 检查是否存在terraform文件（*.tf）→ 创建/验证.terraformignore
- 检查是否需要.helmignore（存在helm图表）→ 创建/验证.helmignore
若忽略文件已存在：验证其包含必要规则，仅添加缺失的关键规则 若忽略文件缺失：根据检测到的技术栈创建包含完整规则集的文件

按技术栈划分的通用规则（来自plan.md的技术栈）：
- Node.js/JavaScript/TypeScript：
```
node_modules/
```
  ,
```
dist/
```
  ,
```
build/
```
  ,
```
*.log
```
  ,
```
.env*
```
- Python：
```
__pycache__/
```
  ,
```
*.pyc
```
  ,
```
.venv/
```
  ,
```
venv/
```
  ,
```
dist/
```
  ,
```
*.egg-info/
```
- Java：
```
target/
```
  ,
```
*.class
```
  ,
```
*.jar
```
  ,
```
.gradle/
```
  ,
```
build/
```
- C#/.NET：
```
bin/
```
  ,
```
obj/
```
  ,
```
*.user
```
  ,
```
*.suo
```
  ,
```
packages/
```
- Go：
```
*.exe
```
  ,
```
*.test
```
  ,
```
vendor/
```
  ,
```
*.out
```
- Ruby：
```
.bundle/
```
  ,
```
log/
```
  ,
```
tmp/
```
  ,
```
*.gem
```
  ,
```
vendor/bundle/
```
- PHP：
```
vendor/
```
  ,
```
*.log
```
  ,
```
*.cache
```
  ,
```
*.env
```
- Rust：
```
target/
```
  ,
```
debug/
```
  ,
```
release/
```
  ,
```
*.rs.bk
```
  ,
```
*.rlib
```
  ,
```
*.prof*
```
  ,
```
.idea/
```
  ,
```
*.log
```
  ,
```
.env*
```
- Kotlin：
```
build/
```
  ,
```
out/
```
  ,
```
.gradle/
```
  ,
```
.idea/
```
  ,
```
*.class
```
  ,
```
*.jar
```
  ,
```
*.iml
```
  ,
```
*.log
```
  ,
```
.env*
```
- C++：
```
build/
```
  ,
```
bin/
```
  ,
```
obj/
```
  ,
```
out/
```
  ,
```
*.o
```
  ,
```
*.so
```
  ,
```
*.a
```
  ,
```
*.exe
```
  ,
```
*.dll
```
  ,
```
.idea/
```
  ,
```
*.log
```
  ,
```
.env*
```
- C：
```
build/
```
  ,
```
bin/
```
  ,
```
obj/
```
  ,
```
out/
```
  ,
```
*.o
```
  ,
```
*.a
```
  ,
```
*.so
```
  ,
```
*.exe
```
  ,
```
Makefile
```
  ,
```
config.log
```
  ,
```
.idea/
```
  ,
```
*.log
```
  ,
```
.env*
```
- Swift：
```
.build/
```
  ,
```
DerivedData/
```
  ,
```
*.swiftpm/
```
  ,
```
Packages/
```
- R：
```
.Rproj.user/
```
  ,
```
.Rhistory
```
  ,
```
.RData
```
  ,
```
.Ruserdata
```
  ,
```
*.Rproj
```
  ,
```
packrat/
```
  ,
```
renv/
```
- 通用规则：
```
.DS_Store
```
  ,
```
Thumbs.db
```
  ,
```
*.tmp
```
  ,
```
*.swp
```
  ,
```
.vscode/
```
  ,
```
.idea/
```
工具特定规则：
- Docker：
```
node_modules/
```
  ,
```
.git/
```
  ,
```
Dockerfile*
```
  ,
```
.dockerignore
```
  ,
```
*.log*
```
  ,
```
.env*
```
  ,
```
coverage/
```
- ESLint：
```
node_modules/
```
  ,
```
dist/
```
  ,
```
build/
```
  ,
```
coverage/
```
  ,
```
*.min.js
```
- Prettier：
```
node_modules/
```
  ,
```
dist/
```
  ,
```
build/
```
  ,
```
coverage/
```
  ,
```
package-lock.json
```
  ,
```
yarn.lock
```
  ,
```
pnpm-lock.yaml
```
- Terraform：
```
.terraform/
```
  ,
```
*.tfstate*
```
  ,
```
*.tfvars
```
  ,
```
.terraform.lock.hcl
```
- Kubernetes/k8s：
```
*.secret.yaml
```
  ,
```
secrets/
```
  ,
```
.kube/
```
  ,
```
kubeconfig*
```
  ,
```
*.key
```
  ,
```
*.crt
```
解析tasks.md结构并提取：
- 任务阶段：设置、测试、核心开发、集成、优化
- 任务依赖：顺序执行 vs 并行执行规则
- 任务详情：ID、描述、文件路径、并行标记[P]
- 执行流程：顺序和依赖要求
按照任务计划执行实施工作：
- 分阶段执行：完成一个阶段后再进入下一个阶段
- 遵循依赖关系：顺序任务按顺序执行，标记[P]的并行任务可同时执行
- 遵循TDD方法：在对应的实现任务之前先执行测试任务
- 基于文件的协调：影响同一文件的任务必须顺序执行
- 验证检查点：进入下一阶段前验证当前阶段已完成
实施执行规则：
- 先完成设置：初始化项目结构、依赖项、配置
- 先测试后编码：若需要为契约、实体和集成场景编写测试
- 核心开发：实现模型、服务、CLI命令、端点
- 集成工作：数据库连接、中间件、日志、外部服务
- 优化与验证：单元测试、性能优化、文档完善
进度跟踪与错误处理：
- 完成每个任务后报告进度
- 若任何非并行任务失败，终止执行
- 对于标记[P]的并行任务，继续执行成功的任务，报告失败的任务
- 提供带上下文的清晰错误信息以方便调试
- 若实施无法继续，建议下一步操作
- 重要提示：已完成的任务，务必在tasks文件中标记为[X]。
完成验证：
- 验证所有必填任务均已完成
- 检查已实现的功能是否符合原始规格
- 验证测试通过且覆盖率满足要求
- 确认实施符合技术计划
- 报告最终状态及已完成工作的总结

注意：本Skill假设tasks.md中存在完整的任务分解。若任务缺失或不完整，建议用户先运行speckit-tasks重新生成任务列表。

Outputs

输出项

Implementation changes in the codebase
Updated
```
specs/<feature>/tasks.md
```
with completed tasks checked off

Any generated/updated ignore files (e.g.,

.gitignore

.dockerignore

.eslintignore

.prettierignore

)

代码库中的实施变更
已更新的
```
specs/<feature>/tasks.md
```
，其中已完成任务已标记为已勾选
任何生成/更新的忽略文件（如
```
.gitignore
```
、
```
.dockerignore
```
、
```
.eslintignore
```
、
```
.prettierignore
```
）