Devlab Spec Driven Dev

devlab-spec-driven-dev

用途

将"AI 协作开发"从"边聊边改代码"升级为spec 驱动：先把需求沉淀为结构化提案（requirements / design / tasks），经人类审查确认后，再由 AI 分任务顺序执行并回归。适用于任何支持 spec 工作流的 AI IDE / Agent —— Kiro 的 .kiro/specs/ 只是其中一个具体实现（见 references/REFERENCE-KIRO-SPEC-EXAMPLE.md）。

核心价值：把"意图"显式化、可审查、可追溯、可分任务并行/续跑，避免大改动中途失焦、返工、上下文丢失。

适用场景

• 中大型功能/重构：需求有多个子任务、需要拆解与阶段验收。
• 多轮协作 / 跨会话续跑：需要一份稳定的"事实源"承接进度。
• 需要人类在关键决策点把关（架构、破坏性变更）的 AI 协作开发。

不适用场景

• 一次性小改动（改个文案、修个明显 typo）——直接改即可，不必起 spec。
• 纯探索性调研（用 ask/研究类流程）。

输入

• 需求描述（自然语言）。
• 目标代码库现状。
• 约束与偏好（语言、是否允许破坏性变更、测试力度等）。

输出

• specs// 提案三件套：requirements.md（需求+验收标准）、design.md（技术设计）、tasks.md（可勾选任务清单）。
• 可选：README.md 概览、ADR 架构决策记录、STATUS.md/UPDATE_SUMMARY.md 进度跟踪。
• 分任务执行后的实现 + 回归结果。

工作流

Phase 1: 需求 → requirements.md
  → 澄清目标、边界、验收标准（每条需求可验证）
  → ⛔ Gate G1（human）：需求是否完整/无歧义

Phase 2: 设计 → design.md
  → 技术方案、模块划分、数据流、正确性属性、破坏性变更影响面
  → 调研是否有成熟库/方案可复用
  → ⛔ Gate G2（human）：设计与取舍确认

Phase 3: 任务拆解 → tasks.md
  → 拆为可独立勾选、可验证的任务（含依赖顺序）
  → ⛔ Gate G3（human）：任务粒度与顺序确认

Phase 4: 执行（Run all tasks）
  → 按 tasks.md 顺序执行；可委派子代理逐任务实现
  → 每完成一个任务勾选状态、同步 tasks.md
  → 变更调用侧同步（破坏性变更）

Phase 5: 回归与收尾
  → 跑测试/评测；更新 STATUS；必要时回写 design（实现偏差）

提案质量约束（默认规范，可按团队覆盖）

1. 语言一致：提案与代码注释使用团队约定语言（本团队默认中文）。
2. 破坏性变更策略：允许破坏性变更，但必须同步变更所有调用侧，不保留无意义的向后兼容代码。
3. 工程化思维：方案要面向可维护性与复用，而非"为解决问题而解决"。
4. 测试力度适配：保留必要的属性/单元测试，减少不必要的测试以加快提案落地；关键正确性属性必须覆盖。
5. 提案-实现一致：实现偏离设计时，回写 design/tasks，保持事实源一致。

human-on-the-loop 决策门禁

| Gate | 时机 | 人类确认 | |------|------|---------| | G1 | requirements 完成 | 需求完整性/验收标准 | | G2 | design 完成 | 架构取舍、破坏性变更影响面 | | G3 | tasks 完成 | 任务拆解粒度与顺序 |

> 关键决策给选项 + 推荐，由人类拍板（"方向1(推荐)/方向2…你怎么决策？"），而非 AI 直接定夺。

与其他 devlab-* / 平台 Skill 的关系

| Skill | 关系 | 说明 | |-------|------|------| | devlab-ai-agent-engineering | 上游 | 提供架构方法论，本技能把架构落地为 spec 并执行 | | devlab-eval-driven-agent | 下游 | Phase 5 回归用评测体系验证 | | devlab-tech-debt-ops | 并行 | 重构类 spec 引用其重构编排方法 | | 各 AI IDE 原生 spec 能力 | 载体 | Kiro spec / 其他工具的 spec 均为本方法论的具体实现 |

reference

• references/REFERENCE-KIRO-SPEC-EXAMPLE.md — 以 Kiro .kiro/specs/ 为例的一个具体落地范例（目录结构、Run all tasks、子代理编排）。

约束

• spec 是事实源：进度、决策、变更都要回写 spec，不散落在对话里。
• 不硬编码具体 IDE 的路径/命令为唯一方式——Kiro 仅为 example，方法论与工具解耦。
• 每条需求必须可验证；每个任务必须可独立勾选。
• 破坏性变更必须同步调用侧并在 design 记录影响面。

推荐触发方式

按 spec 驱动方式做这个需求：先出 requirements/design/tasks 提案，我确认后再 Run all tasks

用 devlab-spec-driven-dev 把这个重构拆成提案三件套，关键决策给我选项

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: seed-forge
• Source: seed-forge/harness-ai-kit
• License: Apache-2.0
• Homepage: https://pypi.org/project/harness-ai-kit/

Install and usage instructions live in the source repository linked above.