| name | dev-lifecycle |
| description | Structured 8-phase development lifecycle for AI-assisted coding. Use when starting a new project, module, or feature that involves writing code. Enforces: PRD → Architecture → Technical Spec → Task Breakdown → Test Spec → Implementation → Review → Evolution. Invoke with /skill:dev-lifecycle to start.
|
Dev Lifecycle — 结构化开发流程
概述
8 个阶段，从需求到长期治理。不可跳过任何阶段。
Phase 1: PRD（需求定义） → 对齐锚点 + 做什么 / 不做什么
Phase 2: Architecture（架构设计） → 怎么组织 + 代理可读性设计 + 机械强制规则
Phase 3: Technical Spec（技术规格）→ 增量生成 + 每个字节怎么做（最关键）
Phase 4: Task Breakdown（任务拆解）→ ≤4h 的可执行任务（区分探索型/承诺型）
Phase 5: Test Spec（测试规格） → TDD：先定义什么是对的
Phase 6: Implementation（实现） → 代理熵检查 + 写代码让测试通过
Phase 7: Review & Deploy（审查） → Agent/Human 审查分工 + 确认质量，部署上线
Phase 8: Evolution（演化治理） → 决策日志 + ADR + 复杂度预算 + 交接地图
使用方法
启动新项目/模块
当用户说"开始开发 X"或"实现 X"时，执行以下流程：
- 检查当前进度 — 查看
<project>/docs/ 下已有哪些阶段文档
- 从缺失的最早阶段开始 — 不可跳过
- 使用模板 — 读取对应模板文件（见下方路径），按模板填写
- 验收后再进入下一阶段 — 每个模板底部都有验收标准
如果用户说"直接写代码"
回复：
本项目遵循 dev-lifecycle 方法论。在写代码之前，需要先完成技术规格（Phase 3）和测试规格（Phase 5）。
我先帮你创建技术规格，可以吗？
如果已有架构文档但没有技术规格
直接从 Phase 3 开始。Phase 1/2 可以引用已有文档（白皮书、架构设计等），不需要重复编写。
分形应用
本方法论适用于所有粒度级别：
- 项目级：整个项目完整经历 8 个阶段
- 模块级：每个子模块（如 agent-arena、chain-hub、indexer、SDK 等）独立经历各自的 8 个阶段
- Phase 1/2 可引用：子模块可以引用项目级的 PRD/架构文档，无需重写
- Phase 3 必须重写：每个子模块的技术规格必须独立编写，这是不可妥协的硬性要求
启动子模块时的检查清单：
- 查看项目级
docs/ 中已有的阶段文档
- 判断哪些可以引用、哪些必须重写
- Phase 3 永远重新编写，即使项目级已有技术规格
模板
模板文件在 dev-lifecycle 仓库中，项目中通常位于 docs/methodology/templates/。
如果项目中没有 submodule，使用以下内联模板要点：
Phase 3 技术规格（最关键的模板）核心要求
技术规格必须精确到：
- 数据结构：每个字段名、类型、字节大小、约束
- 接口定义：参数、返回值、错误码、前置/后置条件
- 状态机：当前状态 + 触发动作 + 条件 → 新状态 + 副作用
- 常量：所有硬编码值集中定义
- 算法：非 trivial 计算的伪代码/公式
- PDA/地址推导：种子定义（Solana 项目）
- 边界条件：至少列出 10 个特殊情况
Phase 5 测试规格核心要求
每个接口/函数必须有三类测试：
- Happy Path：正常输入 → 正常输出
- Boundary：边界值（最小/最大/刚好等于阈值）
- Error/Attack：异常输入 → 预期错误码
测试代码骨架先于实现代码编写。
6 条强制规则
- 不可跳过阶段
- 技术规格是代码的契约 — 代码必须与规格 100% 一致，不一致时先改规格
- TDD 不可商量 — 测试先于实现
- 输入完整才能开始 — 上一阶段输出是下一阶段输入
- 必填项不可省略
- 摩擦即判断力 — 代理审查通过 ≠ 人类可跳过；高风险变更（DB/auth/API/不可逆操作）必须人类判断
关键概念：探索型 vs 承诺型任务
Phase 4 任务拆解时，每个任务必须标注性质：
- 探索型 (Explore): 验证方向，可跳过 Phase 3/5，代码不合入 main，分支用
explore/ 或 prototype/
- 承诺型 (Commit): 生产代码，必须走完整 8 阶段
- 探索成果要进生产 → 必须从 Phase 3 重新走承诺型流程
代理熵管理
实现前检查代码库健康度（Phase 6.0.1），每完成 3 个任务暂停监控代理漂移。
如果发现 bare catch、默认值 fallback、重复函数等代理漂移模式 ≥ 2 项，立即停止实现，先清理。
文档命名
<project>/docs/
├── 01-prd.md
├── 02-architecture.md
├── 03-technical-spec.md ← 最重要
├── 04-task-breakdown.md
├── 05-test-spec.md
├── 06-implementation-log.md
├── 07-review-report.md
└── 08-evolution.md
完整模板
完整模板在 dev-lifecycle 仓库：https://codeberg.org/davirain/dev-lifecycle
如果项目有 submodule，路径为 docs/methodology/templates/01-08.md。
需要时用 read 工具读取对应模板文件。
