spec-driven-implementation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec-Driven Implementation Skill

Purpose

目标

Guide feature implementation through two structured phases: Task Breakdown (TDD) → Execution. This systematic approach ensures test-driven development, quality gates, and tracked progress from design to working code.

通过两个结构化阶段指导功能实现：任务拆分（TDD）→ 执行。这种系统化方法确保了测试驱动开发、质量管控，以及从设计到可运行代码的全程进度跟踪。

Activation Triggers

触发条件

Activate this skill when:

User says "implement this feature" or "let's code this"
User mentions "tasks", "TDD", or "execution"
User uses
```
/dev-workflow:spec
```
command with implementation options (tasks, execute)
User is ready to start implementation after design approval
User says "break this down into tasks"
Design phase is complete and approved

在以下场景下激活本技能：

用户说“implement this feature”或“let's code this”
用户提及“tasks”“TDD”或“execution”
用户使用带有实现选项（tasks、execute）的/dev-workflow:spec命令
用户在设计获批后准备开始实现
用户说“break this down into tasks”
设计阶段已完成并获批准

Prerequisites

前置条件

This skill requires completed planning from

spec-driven-planning

skill:

Feature directory exists:
```
docx/features/[NN-feature-name]/
```
```
requirements.md
```
is complete with EARS requirements
```
design.md
```
is complete and approved

If prerequisites are missing:

"Implementation requires completed planning. Run
/dev-workflow:spec
and complete options 1-3 first (Feature Creation, Requirements, Design)."

本技能需要

spec-driven-planning

技能完成的规划成果：

功能目录已存在：
```
docx/features/[NN-feature-name]/
```
```
requirements.md
```
已完成，包含EARS需求
```
design.md
```
已完成并获批准

若前置条件缺失：

"实现需要已完成的规划。请先运行/dev-workflow:spec并完成选项1-3（功能创建、需求定义、设计）。"

Two-Phase Implementation Workflow

两阶段实现工作流

Phase 4: Task Breakdown (TDD Focus)

阶段4：任务拆分（聚焦TDD）

Goal: Break design into small, testable tasks following Red-Green-Refactor

Task Structure:

Each task follows TDD cycle:

[ ] Task N: [Description]
    [ ] RED: Write failing test for [functionality]
    [ ] GREEN: Implement minimal code to pass test
    [ ] REFACTOR: Clean up and optimize

    Acceptance Criteria:
    [ ] [Specific criterion 1]
    [ ] [Specific criterion 2]
    Linked Requirements: REQ-###, REQ-###

Traceability Rules:

Every task must list the requirement IDs it satisfies (use IDs from requirements.md).
Maintain coverage by ensuring all requirements appear in at least one task.
If a requirement spans multiple tasks, repeat the ID across those tasks for clarity.

Task Sizing Guidelines:

Each task should take 30-60 minutes
If longer, break into subtasks
Each task must be independently testable
Each task produces working, tested code

UltraThink Before Task Breakdown: Before breaking design into tasks, activate deep thinking if:

Design involves complex algorithms or data structures
Integration points between components are unclear
Multiple implementation strategies are possible
Edge cases and error handling are non-trivial

🗣 Say: "Let me ultrathink the implementation strategy before breaking this into tasks."

Questions to ultrathink:

What's the simplest implementation that satisfies requirements?
Which parts are most likely to change?
Where are the hidden complexities?
What assumptions might break during implementation?
How will we test each component in isolation?
What could we build incrementally vs. all at once?

After UltraThink: Create focused, testable tasks that validate assumptions early.

Task Categories:

Component Tasks
- Implement individual components
- One component per task or split if large
Integration Tasks
- Connect components
- Test component interactions
- Verify data flow
Error Handling Tasks
- Implement error scenarios
- Test edge cases
- Verify error messages
Documentation Tasks
- Write docstrings
- Update README
- Create API docs
Final Verification Tasks
- Code review
- Performance testing
- Security review
- Manual testing

Output: Update

docx/features/[NN-feature-name]/tasks.md

with:

Implementation approach summary
Organized task list with checkboxes
Acceptance criteria for each task
Notes section for implementation considerations

User Confirmation:

"Tasks defined with TDD cycle. Ready to begin implementation?"

目标： 将设计拆分为遵循红-绿-重构流程的小型可测试任务

任务结构：

每个任务遵循TDD循环：

[ ] Task N: [Description]
    [ ] RED: Write failing test for [functionality]
    [ ] GREEN: Implement minimal code to pass test
    [ ] REFACTOR: Clean up and optimize

    Acceptance Criteria:
    [ ] [Specific criterion 1]
    [ ] [Specific criterion 2]
    Linked Requirements: REQ-###, REQ-###

可追溯性规则：

每个任务必须列出其满足的需求ID（使用requirements.md中的ID）。
确保所有需求至少出现在一个任务中，以保证覆盖范围。
若某需求跨多个任务，需在这些任务中重复列出该ID以便清晰追溯。

任务规模指南：

每个任务耗时应在30-60分钟
若耗时更长，拆分为子任务
每个任务必须可独立测试
每个任务需产出可运行的已测试代码

任务拆分前深度思考（UltraThink）： 在将设计拆分为任务前，若出现以下情况需激活深度思考：

设计涉及复杂算法或数据结构
组件间的集成点不明确
存在多种实现策略
边缘情况和错误处理非 trivial

🗣 提示："在拆分任务前，让我先深度思考实现策略。"

深度思考需解决的问题：

满足需求的最简实现方式是什么？
哪些部分最可能发生变更？
隐藏的复杂性在哪里？
哪些假设可能在实现过程中不成立？
如何独立测试每个组件？
哪些部分可以增量构建，哪些需要一次性完成？

深度思考后： 创建聚焦的、可测试的任务，尽早验证假设。

任务分类：

组件任务
- 实现单个组件
- 一个任务对应一个组件，若组件过大可拆分
集成任务
- 连接各个组件
- 测试组件间的交互
- 验证数据流
错误处理任务
- 实现错误场景
- 测试边缘情况
- 验证错误提示
文档任务
- 编写文档字符串
- 更新README
- 创建API文档
最终验证任务
- 代码评审
- 性能测试
- 安全评审
- 手动测试

输出： 更新

docx/features/[NN-feature-name]/tasks.md

，包含：

实现方法概述
带复选框的有序任务列表
每个任务的验收标准
实现注意事项的备注部分

用户确认：

"已按TDD循环定义任务。是否准备开始实现？"

Phase 5: Execution

阶段5：执行

Goal: Execute tasks systematically with quality gates

Execution Workflow:

For each task:

Mark Task as In Progress

Use Edit tool on

docx/features/[NN-feature-name]/tasks.md

Find the task header:
```
[ ] Task N: [description]
```
Replace with:
```
[→] Task N: [description]
```
Also mark the RED phase checkbox as
```
[→]
```

Example Edit call:

Edit tool:
  file: docx/features/01-user-auth/tasks.md
  old_string: "[ ] Task 3: Implement JWT validation"
  new_string: "[→] Task 3: Implement JWT validation"

RED Phase
- Write failing test for the specific functionality
- Run test suite to verify failure (test MUST fail)
- Use Edit tool to check off RED phase:
```
[ ] RED: ...
```
  →
```
[x] RED: ...
```
- Commit:
```
test: Add test for [functionality]
```
GREEN Phase
- Write minimal implementation to make test pass
- Run tests until passing (all tests MUST pass)
- Don't optimize yet (just make it work)
- Use Edit tool to check off GREEN phase:
```
[ ] GREEN: ...
```
  →
```
[x] GREEN: ...
```
- Commit:
```
feat: Implement [functionality]
```
REFACTOR Phase
- Clean up code (remove duplication, improve naming)
- Run tests to ensure still passing
- Use Edit tool to check off REFACTOR phase:
```
[ ] REFACTOR: ...
```
  →
```
[x] REFACTOR: ...
```
- Commit:
```
refactor: Optimize [component]
```
Mark Task Complete
Use Edit tool on
```
docx/features/[NN-feature-name]/tasks.md
```
:
- Change task header:
```
[→] Task N: ...
```
  →
```
[x] Task N: ...
```
- Verify all acceptance criteria are checked:
```
[x]
```
- Update Progress Summary section (see instructions below)

目标： 系统地执行任务，确保质量管控

执行工作流：

针对每个任务：

标记任务为进行中

在

docx/features/[NN-feature-name]/tasks.md

上使用编辑工具：

找到任务标题：
```
[ ] Task N: [description]
```
替换为：
```
[→] Task N: [description]
```
同时将RED阶段的复选框标记为
```
[→]
```

编辑示例：

Edit tool:
  file: docx/features/01-user-auth/tasks.md
  old_string: "[ ] Task 3: Implement JWT validation"
  new_string: "[→] Task 3: Implement JWT validation"

RED阶段
- 为特定功能编写失败的测试
- 运行测试套件以验证失败（测试必须失败）
- 使用编辑工具勾选RED阶段：
```
[ ] RED: ...
```
  →
```
[x] RED: ...
```
- 提交：
```
test: Add test for [functionality]
```
GREEN阶段
- 编写最简实现使测试通过
- 运行测试直至通过（所有测试必须通过）
- 暂不优化（先让代码能运行）
- 使用编辑工具勾选GREEN阶段：
```
[ ] GREEN: ...
```
  →
```
[x] GREEN: ...
```
- 提交：
```
feat: Implement [functionality]
```
REFACTOR阶段
- 清理代码（移除重复、优化命名）
- 运行测试确保仍能通过
- 使用编辑工具勾选REFACTOR阶段：
```
[ ] REFACTOR: ...
```
  →
```
[x] REFACTOR: ...
```
- 提交：
```
refactor: Optimize [component]
```
标记任务完成
在
```
docx/features/[NN-feature-name]/tasks.md
```
上使用编辑工具：
- 修改任务标题：
```
[→] Task N: ...
```
  →
```
[x] Task N: ...
```
- 验证所有验收标准已勾选：
```
[x]
```
- 更新进度汇总部分（参见下方说明）

Task Tracking Protocol

任务跟踪协议

CRITICAL: Use Edit tool to update tasks.md - don't just announce progress.

关键要求：使用编辑工具更新tasks.md - 不要仅口头宣布进度。

Workflow Summary

工作流汇总

Start Phase 5
    ↓
Edit: Status "Not Started" → "In Progress"
    ↓
For each task:
    ↓
    Edit: [ ] Task N → [→] Task N
    Edit: [ ] RED → [→] RED
    ↓
    Write failing test
    ↓
    Edit: [→] RED → [x] RED
    Edit: [ ] GREEN → [→] GREEN
    ↓
    Implement code
    ↓
    Edit: [→] GREEN → [x] GREEN
    Edit: [ ] REFACTOR → [→] REFACTOR
    ↓
    Refactor code
    ↓
    Edit: [→] REFACTOR → [x] REFACTOR
    Edit: [→] Task N → [x] Task N
    Edit: Update Progress Summary
    ↓
Next task or finish
    ↓
Edit: Status "In Progress" → "Complete"

启动阶段5
    ↓
编辑：状态“Not Started” → “In Progress”
    ↓
针对每个任务：
    ↓
    编辑：[ ] Task N → [→] Task N
    编辑：[ ] RED → [→] RED
    ↓
    编写失败的测试
    ↓
    编辑：[→] RED → [x] RED
    编辑：[ ] GREEN → [→] GREEN
    ↓
    实现代码
    ↓
    编辑：[→] GREEN → [x] GREEN
    编辑：[ ] REFACTOR → [→] REFACTOR
    ↓
    重构代码
    ↓
    编辑：[→] REFACTOR → [x] REFACTOR
    编辑：[→] Task N → [x] Task N
    编辑：更新进度汇总
    ↓
下一个任务或完成
    ↓
编辑：状态“In Progress” → “Complete”

Edit Tool Usage Pattern

编辑工具使用模式

Always follow this pattern for every task:

Before starting any task:

Use Edit tool to change [ ] → [→] in tasks.md

After completing each phase (RED/GREEN/REFACTOR):

Use Edit tool to change [→] → [x] for that phase
Use Edit tool to change [ ] → [→] for next phase

After completing full task:

Use Edit tool to change [→] → [x] for task header
Use Edit tool to update Progress Summary counts

Don't skip these Edit calls - they're not optional suggestions, they're required operations.

每个任务必须遵循以下模式：

开始任何任务前：

使用编辑工具将tasks.md中的[ ] → [→]

完成每个阶段（RED/GREEN/REFACTOR）后：

使用编辑工具将该阶段的[→] → [x]
使用编辑工具将下一阶段的[ ] → [→]

完成整个任务后：

使用编辑工具将任务标题的[→] → [x]
使用编辑工具更新进度汇总的计数

不要跳过这些编辑操作 - 它们不是可选建议，而是必须执行的操作。

Announcing vs. Modifying

口头宣布 vs 实际修改

Wrong (Just Announcing):

✅ Task 1 complete
Moving to Task 2...

Right (Actually Modifying + Announcing):

[Using Edit tool to mark Task 1 complete: [→] → [x]]
[Using Edit tool to update Progress Summary: Completed 1/10]
✅ Task 1 complete

[Using Edit tool to mark Task 2 in progress: [ ] → [→]]
Starting Task 2: JWT token generation...

错误做法（仅口头宣布）：

✅ Task 1 complete
Moving to Task 2...

正确做法（实际修改 + 口头宣布）：

[使用编辑工具标记Task 1完成：[→] → [x]]
[使用编辑工具更新进度汇总：已完成1/10]
✅ Task 1 complete

[使用编辑工具标记Task 2为进行中：[ ] → [→]]
Starting Task 2: JWT token generation...

Progress Summary Maintenance

进度汇总维护

The Progress Summary section must stay synchronized:

Before any tasks start:

markdown

- Total Tasks: 10
- Completed: 0/10
- In Progress: None

After Task 1 starts:

markdown

- Total Tasks: 10
- Completed: 0/10
- In Progress: Task 1 - User model with password hashing

After Task 1 completes:

markdown

- Total Tasks: 10
- Completed: 1/10
- In Progress: Task 2 - JWT token generation

Use Edit tool to update these fields after every task completion.

Status Checkpoints:

Every 2-3 completed tasks, provide status update:

🔄 Checkpoint Update:
- ✅ Tests: [N/N] passing
- ✅ Type check: No errors
- ✅ Lint: Clean
- 📝 Completed tasks: [X/Y]
- 🎯 Next: [Next task description]

[Confidence: X.X]

进度汇总部分必须保持同步：

任务未开始前：

markdown

- Total Tasks: 10
- Completed: 0/10
- In Progress: None

Task 1开始后：

markdown

- Total Tasks: 10
- Completed: 0/10
- In Progress: Task 1 - User model with password hashing

Task 1完成后：

markdown

- Total Tasks: 10
- Completed: 1/10
- In Progress: Task 2 - JWT token generation

每次任务完成后使用编辑工具更新这些字段。

状态检查点：

每完成2-3个任务，提供状态更新：

🔄 检查点更新：
- ✅ 测试：[N/N] 通过
- ✅ 类型检查：无错误
- ✅ 代码规范检查：无问题
- 📝 已完成任务：[X/Y]
- 🎯 下一步：[下一个任务描述]

[Confidence: X.X]

Quick Reference

快速参考

Edit patterns already detailed above. Key reminders:

Update Status header when starting/completing implementation
Use Grep to count tasks if needed:
```
grep -c "^\- \[x\] Task" tasks.md
```
Update test coverage optionally: Run
```
npm run test:coverage
```
and Edit tasks.md

Auto-Trigger Code Quality Review:

Before each commit:

Use Skill tool to invoke:
```
dev-workflow:code-quality
```
Review changes for issues
Address critical findings before commit

How to activate:

Use Skill tool: Skill(skill: "dev-workflow:code-quality")

Integration Points:

Use Skill tool to invoke:
```
dev-workflow:test-driven-development
```
for strict TDD guidance
Use Skill tool to invoke:
```
dev-workflow:git-workflow
```
for smart commits
Use Skill tool to invoke:
```
dev-workflow:code-quality
```
for pre-commit reviews

How to activate integration skills:

undefined

编辑模式已在上文详细说明。关键提醒：

开始/完成实现时更新状态标题
若需统计任务数量，使用Grep命令：
```
grep -c "^\- \[x\] Task" tasks.md
```
可选更新测试覆盖率：运行
```
npm run test:coverage
```
并编辑tasks.md

自动触发代码质量评审：

每次提交前：

使用技能工具调用：
```
dev-workflow:code-quality
```
评审变更以发现问题
提交前解决关键问题

激活方式：

Use Skill tool: Skill(skill: "dev-workflow:code-quality")

集成点：

使用技能工具调用：
```
dev-workflow:test-driven-development
```
获取严格的TDD指导
使用技能工具调用：
```
dev-workflow:git-workflow
```
实现智能提交
使用技能工具调用：
```
dev-workflow:code-quality
```
进行提交前评审

激活集成技能的方式：

undefined

For TDD enforcement

用于TDD强制执行

Use Skill tool: Skill(skill: "dev-workflow:test-driven-development")

For git operations

用于Git操作

Use Skill tool: Skill(skill: "dev-workflow:git-workflow")

For code review

用于代码评审

Use Skill tool: Skill(skill: "dev-workflow:code-quality")


**Completion Criteria:**

Feature is complete when:
- [ ] All tasks checked off
- [ ] All tests passing
- [ ] No linter errors
- [ ] No type errors
- [ ] Code review passed
- [ ] Documentation updated
- [ ] Manual testing complete

**Final Output:**

✅ Feature Complete: [Feature Name]

Summary:

Total tasks: [N]
Tests added: [N]
Test coverage: [X%]
Commits: [N]
Files changed: [N]

Ready to create PR or merge to main?

---

Use Skill tool: Skill(skill: "dev-workflow:code-quality")


**完成标准：**

功能完成需满足：
- [ ] 所有任务已勾选完成
- [ ] 所有测试通过
- [ ] 无代码规范错误
- [ ] 无类型错误
- [ ] 代码评审通过
- [ ] 文档已更新
- [ ] 手动测试完成

**最终输出：**

✅ Feature Complete: [Feature Name]

Summary:

Total tasks: [N]
Tests added: [N]
Test coverage: [X%]
Commits: [N]
Files changed: [N]

Ready to create PR or merge to main?

---

Test-Driven Development (TDD) Principles

测试驱动开发（TDD）原则

The Red-Green-Refactor Cycle

红-绿-重构循环

RED (Write Failing Test):

Write a test that describes what the code should do.
The test MUST fail because the code doesn't exist yet.
This proves the test is actually testing something.

GREEN (Make Test Pass):

Write the MINIMUM code needed to make the test pass.
Don't worry about elegance or optimization.
Just make it work.

REFACTOR (Improve Code):

Now that tests pass, improve the code:
- Remove duplication
- Improve naming
- Simplify logic
- Optimize performance
Run tests after each change to ensure they still pass.

RED（编写失败的测试）：

编写描述代码应实现功能的测试。
由于代码尚未实现，测试必须失败。
这能证明测试确实在验证目标功能。

GREEN（使测试通过）：

编写最简代码使测试通过。
不要考虑优雅性或优化。
先让代码能运行。

REFACTOR（优化代码）：

测试通过后，优化代码：
- 移除重复代码
- 优化命名
- 简化逻辑
- 优化性能
每次变更后运行测试，确保仍能通过。

TDD Best Practices

TDD最佳实践

DO:

Write test before production code (always RED first)
Write smallest test possible
Run tests frequently
Commit at each phase (RED, GREEN, REFACTOR)
Keep tests fast and independent

DON'T:

Write production code without a failing test
Write multiple tests before implementation
Skip the refactor phase
Test implementation details (test behavior)
Let tests become slow or flaky

应做：

先写测试，再写生产代码（始终从RED阶段开始）
编写尽可能小的测试
频繁运行测试
在每个阶段（RED、GREEN、REFACTOR）提交代码
保持测试快速且独立

不应做：

未编写失败测试就写生产代码
在实现前编写多个测试
跳过重构阶段
测试实现细节（应测试行为）
让测试变得缓慢或不稳定

Examples

示例

Example 1: Starting Task Breakdown

示例1：启动任务拆分

User: "/dev-workflow:spec tasks"

Assistant:

Activating spec-driven-implementation skill at Phase 4: Task Breakdown

Found feature: docx/features/01-user-authentication/
✅ requirements.md exists
✅ design.md exists

Reading design to create TDD tasks...

Breaking down into testable tasks:

[ ] Task 1: User model with password hashing
    [ ] RED: Test password hashing on save
    [ ] GREEN: Implement bcrypt hashing
    [ ] REFACTOR: Extract hashing to utility

    Acceptance Criteria:
    [ ] Passwords are hashed before storage
    [ ] Original password is not stored
    [ ] Hash is verifiable

[ ] Task 2: JWT token generation
    [ ] RED: Test token generation with user ID
    [ ] GREEN: Implement JWT signing
    [ ] REFACTOR: Extract to auth service

    Acceptance Criteria:
    [ ] Token contains user ID
    [ ] Token expires in 24 hours
    [ ] Token is properly signed

[...8 more tasks...]

Tasks defined. Ready to begin implementation?

用户： "/dev-workflow:spec tasks"

助手：

Activating spec-driven-implementation skill at Phase 4: Task Breakdown

Found feature: docx/features/01-user-authentication/
✅ requirements.md exists
✅ design.md exists

Reading design to create TDD tasks...

Breaking down into testable tasks:

[ ] Task 1: User model with password hashing
    [ ] RED: Test password hashing on save
    [ ] GREEN: Implement bcrypt hashing
    [ ] REFACTOR: Extract hashing to utility

    Acceptance Criteria:
    [ ] Passwords are hashed before storage
    [ ] Original password is not stored
    [ ] Hash is verifiable

[ ] Task 2: JWT token generation
    [ ] RED: Test token generation with user ID
    [ ] GREEN: Implement JWT signing
    [ ] REFACTOR: Extract to auth service

    Acceptance Criteria:
    [ ] Token contains user ID
    [ ] Token expires in 24 hours
    [ ] Token is properly signed

[...8 more tasks...]

Tasks defined. Ready to begin implementation?

Example 2: Executing Implementation

示例2：执行实现

User: "Yes, let's start"

Assistant:

Activating Phase 5: Execution

[Using Edit tool on docx/features/01-user-authentication/tasks.md]
[Changing "**Status:** Not Started" to "**Status:** In Progress"]

[Using Edit tool to mark Task 1 in progress]
[Changing "[ ] Task 1: User model with password hashing" to "[→] Task 1: User model with password hashing"]

[Using Edit tool to mark RED phase in progress]
[Changing "    [ ] RED: Test password hashing on save" to "    [→] RED: Test password hashing on save"]

Starting Task 1: User model with password hashing

RED Phase: Writing failing test...
[Creates test file tests/models/user.test.js with failing test]
Running tests... ❌ 1 failing (expected)

[Using Edit tool to check off RED phase]
[Changing "    [→] RED: Test password hashing on save" to "    [x] RED: Test password hashing on save"]

Commit: test: Add test for user password hashing

[Using Edit tool to mark GREEN phase in progress]
[Changing "    [ ] GREEN: Implement bcrypt hashing" to "    [→] GREEN: Implement bcrypt hashing"]

GREEN Phase: Implementing minimal code...
[Implements password hashing in src/models/user.js]
Running tests... ✅ All passing

[Using Edit tool to check off GREEN phase]
[Changing "    [→] GREEN: Implement bcrypt hashing" to "    [x] GREEN: Implement bcrypt hashing"]

Commit: feat: Implement user password hashing with bcrypt

[Using Edit tool to mark REFACTOR phase in progress]
[Changing "    [ ] REFACTOR: Extract hashing to utility" to "    [→] REFACTOR: Extract hashing to utility"]

REFACTOR Phase: Extracting to utility...
[Refactors code to src/utils/crypto.js]
Running tests... ✅ All passing

[Using Edit tool to check off REFACTOR phase]
[Changing "    [→] REFACTOR: Extract hashing to utility" to "    [x] REFACTOR: Extract hashing to utility"]

Commit: refactor: Extract password hashing to utility module

[Using Edit tool to mark Task 1 complete]
[Changing "[→] Task 1: User model with password hashing" to "[x] Task 1: User model with password hashing"]

[Using Edit tool to update Progress Summary]
[Changing "- Completed: 0/10" to "- Completed: 1/10"]
[Changing "- In Progress: Task 1 - User model with password hashing" to "- In Progress: Task 2 - JWT token generation"]

✅ Task 1 complete

🔄 Checkpoint Update:
- ✅ Tests: 3/3 passing
- ✅ Type check: No errors
- ✅ Lint: Clean
- 📝 Completed tasks: 1/10
- 🎯 Next: Task 2 - JWT token generation

[Confidence: 0.9]

Continue to Task 2?

用户： "Yes, let's start"

助手：

Activating Phase 5: Execution

[Using Edit tool on docx/features/01-user-authentication/tasks.md]
[Changing "**Status:** Not Started" to "**Status:** In Progress"]

[Using Edit tool to mark Task 1 in progress]
[Changing "[ ] Task 1: User model with password hashing" to "[→] Task 1: User model with password hashing"]

[Using Edit tool to mark RED phase in progress]
[Changing "    [ ] RED: Test password hashing on save" to "    [→] RED: Test password hashing on save"]

Starting Task 1: User model with password hashing

RED Phase: Writing failing test...
[Creates test file tests/models/user.test.js with failing test]
Running tests... ❌ 1 failing (expected)

[Using Edit tool to check off RED phase]
[Changing "    [→] RED: Test password hashing on save" to "    [x] RED: Test password hashing on save"]

Commit: test: Add test for user password hashing

[Using Edit tool to mark GREEN phase in progress]
[Changing "    [ ] GREEN: Implement bcrypt hashing" to "    [→] GREEN: Implement bcrypt hashing"]

GREEN Phase: Implementing minimal code...
[Implements password hashing in src/models/user.js]
Running tests... ✅ All passing

[Using Edit tool to check off GREEN phase]
[Changing "    [→] GREEN: Implement bcrypt hashing" to "    [x] GREEN: Implement bcrypt hashing"]

Commit: feat: Implement user password hashing with bcrypt

[Using Edit tool to mark REFACTOR phase in progress]
[Changing "    [ ] REFACTOR: Extract hashing to utility" to "    [→] REFACTOR: Extract hashing to utility"]

REFACTOR Phase: Extracting to utility...
[Refactors code to src/utils/crypto.js]
Running tests... ✅ All passing

[Using Edit tool to check off REFACTOR phase]
[Changing "    [→] REFACTOR: Extract hashing to utility" to "    [x] REFACTOR: Extract hashing to utility"]

Commit: refactor: Extract password hashing to utility module

[Using Edit tool to mark Task 1 complete]
[Changing "[→] Task 1: User model with password hashing" to "[x] Task 1: User model with password hashing"]

[Using Edit tool to update Progress Summary]
[Changing "- Completed: 0/10" to "- Completed: 1/10"]
[Changing "- In Progress: Task 1 - User model with password hashing" to "- In Progress: Task 2 - JWT token generation"]

✅ Task 1 complete

🔄 Checkpoint Update:
- ✅ Tests: 3/3 passing
- ✅ Type check: No errors
- ✅ Lint: Clean
- 📝 Completed tasks: 1/10
- 🎯 Next: Task 2 - JWT token generation

[Confidence: 0.9]

Continue to Task 2?

Back to Planning

返回规划阶段

If during implementation you discover:

Missing requirements
Design needs changes
Unclear specifications

STOP implementation and return to planning:

"Implementation blocked: [issue]. Need to revisit [requirements/design]. Use
/dev-workflow:spec [requirements/design]
to update planning documents."

Then use Skill tool to invoke:

dev-workflow:spec-driven-planning

to update planning documents before continuing implementation.

How to return to planning:

Use Skill tool: Skill(skill: "dev-workflow:spec-driven-planning")

若在实现过程中发现：

需求缺失
设计需要变更
规格说明不明确

停止实现并返回规划阶段：

"Implementation blocked: [issue]. Need to revisit [requirements/design]. Use
/dev-workflow:spec [requirements/design]
to update planning documents."

然后使用技能工具调用：

dev-workflow:spec-driven-planning

更新规划文档后再继续实现。

返回规划阶段的方式：

Use Skill tool: Skill(skill: "dev-workflow:spec-driven-planning")

Notes

注意事项

Critical Requirements

关键要求

NEVER write production code without a failing test first
ALWAYS use Edit tool to update tasks.md checkboxes - don't just announce progress
ALWAYS use Edit tool to update Progress Summary after each task completion
Use Edit tool to update Status header when starting/completing implementation

绝对不要在没有失败测试的情况下编写生产代码
必须使用编辑工具更新tasks.md的复选框 - 不要仅口头宣布进度
每次任务完成后必须使用编辑工具更新进度汇总
开始/完成实现时必须使用编辑工具更新状态标题

Task Tracking Best Practices

任务跟踪最佳实践

Mark in progress: Use Edit tool to change
```
[ ]
```
→
```
[→]
```
before starting task
Mark complete: Use Edit tool to change
```
[→]
```
→
```
[x]
```
after finishing task
Update Progress Summary: Use Edit tool after every task to keep counts accurate
File updates are mandatory: Actually modify tasks.md, don't just announce

标记为进行中： 开始任务前，使用编辑工具将
```
[ ]
```
→
```
[→]
```
标记为完成： 完成任务后，使用编辑工具将
```
[→]
```
→
```
[x]
```
更新进度汇总： 每次任务完成后使用编辑工具保证计数准确
文件更新是强制性的： 实际修改tasks.md，不要仅口头宣布

Implementation Guidelines

实现指南

Provide checkpoint updates every 2-3 tasks
Use Skill tool to invoke:
```
dev-workflow:code-quality
```
before commits
Use Skill tool to invoke:
```
dev-workflow:git-workflow
```
for smart commit messages
Follow TDD cycle religiously (RED → GREEN → REFACTOR)
Stop and return to planning if design issues discovered

每完成2-3个任务提供检查点更新
提交前使用技能工具调用：
```
dev-workflow:code-quality
```
使用技能工具调用：
```
dev-workflow:git-workflow
```
生成智能提交信息
严格遵循TDD循环（RED → GREEN → REFACTOR）
若发现设计问题，停止实现并返回规划阶段

Remember

谨记

Announcing progress ≠ Updating files

Wrong:

✅ Task 1 complete
Moving to Task 2...

Right:

[Using Edit tool to mark Task 1 complete: [→] → [x]]
[Using Edit tool to update Progress Summary]
✅ Task 1 complete

口头宣布进度 ≠ 更新文件

错误：

✅ Task 1 complete
Moving to Task 2...

正确：

[使用编辑工具标记Task 1完成：[→] → [x]]
[使用编辑工具更新进度汇总]
✅ Task 1 complete