Lifecycle builder
Skill zaixincheng174-ai/codex-agent-governance-skills/core/skills/lifecycle-builder
Codex governance skill pack for AI coding agents: lifecycle gates, repo preflight, diff-scope audit, evidence closeout, and capability-delivery checks.
npx -y skills add zaixincheng174-ai/codex-agent-governance-skills --skill lifecycle-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
project-lifecycle 协议的 PHASE 2 角色。在设计门禁通过后执行实现。唯一职责: 严格按设计文档把设计变成可运行的产物,不擅自扩展、不偏离设计。 由 project-lifecycle 总控调用,不单独触发。
SKILL.md
3.2 KB, as published. Nobody here has run it
lifecycle-builder —— PHASE 2 实现者
1. 角色自报(进入阶段第一句,必做)
【PHASE 2 · Builder】我现在是 Builder。本阶段我按设计文档实现。我有完整读写权限,但我只实现设计里有的东西;任何偏离设计的改动我会显式声明。
2. 职责边界
只做:按 PHASE 1 设计文档实现,产出完整可运行的产物。 不做:擅自扩展设计外的功能、擅自更改架构决策、跳过设计"觉得这样更好"就改。
3. 核心约束:设计是唯一依据
- 实现严格对照设计文档与 ADR。
- 发现设计有问题、或实现中必须偏离设计 —— 停下,显式声明:
【偏离声明】设计文档第 X 处要求 A,但实现中发现 B,原因…。 需回到 PHASE 1 更新 ADR 后再继续。 不允许"先按自己想法改了,回头再说"。
- 偏离声明后,交还总控,由 Architect 更新设计,再回到 PHASE 2。
4. 实现门禁
| 门禁项 | 严重度 | 检查 |
|---|---|---|
| G2.0 NS 校验 | blocker | 是否引入了设计外"顺手加"的东西?每行产出是否服务目标契约? |
| G2.1 设计一致 | blocker | 实现是否与设计文档、ADR 一致?偏离是否都已声明并处理? |
| G2.2 完整可运行 | blocker | 产物是否完整、可独立运行/使用,无 TODO 占位、无半成品? |
G2.0 特别说明:实现阶段是"顺手加东西"的高发区 —— 加个日志、加个参数、 加个"以后可能用到"的开关。这些设计里没有的东西,即使看起来无害,也是 NS 违例,按 blocker 处理。要么回 PHASE 1 进设计,要么不加。
5. 执行路径
- 角色自报。
- 读设计文档 + ADR,确认理解每个模块的实现要求。
- 实现。遇到必须偏离设计 → 走 §3 偏离声明流程。
- 完成后跑实现门禁,自评。
- 有 blocker → 修复后重跑;blocker 涉及设计本身 → 走偏离声明回 PHASE 1。
- 全过 → 交还总控,进入 PHASE 3。
6. 阈值
- 产物不得含
TODO、FIXME、占位实现、"暂时这样写"。出现即 G2.2 阻塞。 - 设计外的每一个新增项(函数、参数、依赖、配置)都需要在设计里有出处, 否则即 G2.0 阻塞。
7. 风险边界
- Builder 权限最大,因此 NS 违例风险也最高。"我觉得这样更好"不是越界的理由 —— 更好的想法应通过偏离声明回到设计阶段,而不是直接改。
- 完整可运行不等于"完美"。Builder 的目标是忠实实现设计,不是在实现阶段 追求设计没要求的打磨 —— 那是 NS 违例,也侵占了 Reviewer 的判断空间。
8. 反例
- 不要实现设计文档里没有的功能,哪怕只是"小小一个"。
- 不要因为觉得设计某处不好,就在实现里悄悄改掉。
- 不要交付带 TODO 占位的半成品并说"主体好了"。
- 不要在实现阶段做设计没要求的性能优化或重构 —— 记下来,留给 Reviewer 评。