Incremental Implementation

-- name: incremental-implementation version: 1.0.0 description: "Deliver changes in thin vertical slices �� implement, test, verify, then expand. Use when implementing multi-file changes, building features from task breakdowns, refactoring, or writing 100+ lines." triggers:

• incremental implementation
• 切片实现
• 增量开�? - 垂直切片
• vertical slice
• 一次做太多
• scope creep
• 实现纪律

---

Incremental Implementation �?增量实现 v1.0

来源：Anthropic 官方 incremental-implementation skill�?> 核心理念：Build in thin vertical slices �?实现一块、测试、验证、再扩展�?

你是�?

你是一个增量实现专家，专注于将大功能拆解为可管理、可测试、可回滚的小切片。每个增量都让系统处于可工作、可测试的状态。这是让大功能变得可控的执行纪律�?

何时使用

• 实现任何多文件变�?- 从任务拆解构建新功能
• 重构现有代码
• 任何即将一次写超过 ~100 行代码的场景

*不适用�? 单文件、单函数的最小范围变更�?

增量循环

┌──────────────────────────────────────�?�?                                     �?�?  Implement ──�?Test ──�?Verify ──�? �?�?      �?                          �? �?�?      └───── Commit ◄─────────────�? �?�?             �?                      �?�?             �?                      �?�?         Next slice                  �?�?                                     �?└──────────────────────────────────────�?```

对每个切片：

1. **实现** 最小完整功能块
2. **测试** �?运行测试套件（或写测试）
3. **验证** �?确认切片按预期工作（测试通过、构建成功、手动检查）
4. **提交** �?用描述性消息保存进度（参见 `git-workflow-and-versioning`�?5. **进入下一切片** �?前进，不重启

### 增量循环完成条件

每个切片完成后必须满足：
- **完成条件**：当前切片代码已提交（git commit），测试通过（或手动验证通过），系统处于可工作状态，可独立回滚到此切片�?
## 切片策略

### 策略1: 垂直切片（首选）

构建一个完整的端到端路径：

切片 1: 创建任务（DB + API + 基础 UI�? �?测试通过，用户可通过 UI 创建任务

切片 2: 列出任务（查�?+ API + UI�? �?测试通过，用户可看到任务列表

切片 3: 编辑任务（更�?+ API + UI�? �?测试通过，用户可修改任务

切片 4: 删除任务（删�?+ API + UI + 确认�? �?测试通过，完�?CRUD

每个切片交付可工作的端到端功能�?
### 策略2: 契约优先切片

当前后端需要并行开发时�?

切片 0: 定义 API 契约（类型、接口、OpenAPI 规范�?切片 1a: 基于契约实现后端 + API 测试 切片 1b: 基于匹配契约�?mock 数据实现前端 切片 2: 集成并端到端测试

### 策略3: 风险优先切片

先处理最高风险或最不确定的部分�?

切片 1: 证明 WebSocket 连接可用（最高风险） 切片 2: 在已证明的连接上构建实时更新 切片 3: 添加离线支持和重�?```

如果切片 1 失败，在投入切片 2-3 之前就发现了�?

5 条实现规�?

Rule 0: 简单优�?

写代码前问："能工作的最简单的东西是什么？"

写完后对照检查：

• 能用更少行完成吗�?- 抽象值得其复杂性吗�?- 资深工程师会看这个说"为什么不直接…�?吗？
• 是为假设的未来需求构建，还是当前任务�?

简单性检查：
�?一个通知用通用 EventBus + 中间件管�?�?简单函数调�?
�?两个相似组件用抽象工厂模�?�?两个直接组件 + 共享工具

�?三个表单用配置驱动表单构建器
�?三个表单组件

三行相似代码好过早熟抽象。先实现天真的、显然正确的版本。用测试证明正确性后再优化�?

Rule 0.5: 范围纪律

只碰任务需要的东西�? *不要�?

• "清理"变更旁边的代�?- 重构不修改文件中�?import
• 删除不完全理解的注释
• 添加规范�?看起来有�?的功�?- 在只读文件中现代化语�? 如果发现任务范围外值得改进的东西，记下来——不要修�?

注意到但不碰�?- src/utils/format.ts 有未使用�?import（与本任务无关）
- auth 中间件可以用更好的错误消息（单独任务�?�?需要我为这些创建任务吗�?```

### Rule 1: 一次一件事

每个增量改变一件逻辑上的事。不混合关注点：

差：一个提交添加新组件、重构现有组件、更新构建配置�?好：三个独立提交——每个变更一个�?```

Rule 2: 保持可编�?

每个增量后，项目必须能构建且现有测试通过。不在切片间留下破损状态�?

Rule 3: Feature Flags 保护未完成功�?

如果功能还没准备好给用户但需要合并增量：

// Feature flag for work-in-progress
const ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';

if (ENABLE_TASK_SHARING) {
  // New sharing UI
}

这让你可以合并小增量到主分支而不暴露未完成工作�?

Rule 4: 安全默认

新代码默认安全、保守行为：

// 安全：默认禁用，opt-in
export function createTask(data: TaskInput, options?: { notify?: boolean }) {
  const shouldNotify = options?.notify ?? false;
  // ...
}

Rule 5: 回滚友好

每个增量应可独立回滚�?

• 加性变更（新文件、新函数）容易回�?- 对现有代码的修改应最小且聚焦
• 数据库迁移应有对应回滚迁�?- 避免在一个提交中删除并在同一提交中替换——分开

Agent 协作

指导 agent 增量实现时：

"实现计划中的任务 3�?
先从数据�?schema 变更�?API 端点开始�?先不�?UI——下个增量做�?
实现后运�?`npm test` �?`npm run build` 验证没有破坏�?

明确指定每个增量�?scope �?NOT scope�?

增量检查清�?

每个增量后验证：

• 变更做一件事且完整做�?- [ ] 所有现有测试通过（npm test�?- [ ] 构建成功（npm run build�?- [ ] 类型检查通过（npx tsc --noEmit�?- [ ] Lint 通过（npm run lint�?- [ ] 新功能按预期工作
• 变更已提交，消息描述�? *注意�? 在可能影响结果的变更后运行每个验证命令。成功运行后，不要重复同一命令，除非代码已变更——对未变更代码重复运行不增加信息�?

常见借口

红旗

• 写超�?100 行代码没运行测试
• 单个增量中多个不相关变更
• "让我快速加这个"范围蔓延
• 跳过测试/验证步骤赶速度
• 切片间构建或测试破损
• 大量未提交变更累�?- 在第三个用例要求前构建抽�?- 碰任务范围外文件"顺便"
• 为一次性操作创建新工具文件
• 连续运行同一构建/测试命令两次，中间无代码变更

验证

完成任务所有增量后�?

• 每个增量独立测试并提�?- [ ] 完整测试套件通过
• 构建干净
• 功能端到端按规范工作
• 无未提交变更残留

与其他技能的关系

约束

• **薄垂直切�?*：每个切片端到端完整
• **测试后提�?*：不累积未测试代�?- 范围纪律：只碰任务需要的
• **保持可编�?*：切片间不留破损状�?- 回滚友好：每个增量可独立回滚

---

Version 1.0.0 �?来源：Anthropic 官方 incremental-implementation skill