Github链接 https://github.com/rpamis/comet

快速安装

npm install -g @rpamis/comet
cd your-project
comet init
/comet 开发一个用户登录功能

基于巨人的肩膀如何做出一个更好用的Spec工具

最近我做了一个Skill，叫 Comet 。

它的核心不是重新发明一个新的 spec 工具，也不是再造一套 AI 编码提示词，而是把两个我很喜欢的 GitHub 项目组合起来：

OpenSpec + Superpowers

我做 Comet 的原因，是因为我在分别使用 OpenSpec 和 Superpowers 的过程中，发现它们各自都很强，但单独使用时都会遇到一些流程断点。

OpenSpec 很适合管理需求、proposal、spec 生命周期和归档。

Superpowers 很适合做头脑风暴、深度设计、计划执行和代码 review。

但我在真实使用时发现：

只用 OpenSpec，容易出现 WHAT 清楚，但 HOW 不够细 的问题，直接采用OpenSpec的task显得有点单薄。
只用 Superpowers，容易出现 HOW 很强，但 WHAT 没有完整生命周期闭环 的问题，中间产出的Spec文档回过头来看不知道哪些是已经做完了，哪些是没做完，缺乏Spec归档能力。

所以 Comet 的出发点不是替代它们，而是把它们各自最强的部分接起来。

单独使用 OpenSpec 时，我遇到的问题

OpenSpec 的优点很明显。

它非常适合管理一次变更的 WHAT ：

这次要做什么？
为什么要做？
proposal 怎么写？
spec 应该怎么变化？
delta spec 最后怎么同步？
完成后怎么 archive？
这些能力对长期维护项目很重要。

因为项目做久了，最怕的不是“代码没人写”，而是：

这次变更为什么做？
当时需求边界是什么？
spec 有没有同步？
最后有没有归档？
以后还能不能追溯？
OpenSpec 在这方面做得很好。

但也遇到了一个很明显的问题：

它可以帮我把“要做什么”说清楚，
但不太能把“具体怎么做”推进得足够细。

比如：

proposal 写完之后，技术方案要不要再展开？
多个实现路径怎么比较？
复杂功能要不要先做 brainstorming？
Design Doc 应该怎么沉淀？
任务如何拆成更适合 AI 执行的步骤？
AI 什么时候应该开始写代码？
写代码时如何结合 TDD、计划执行和 code review？
这些更偏工程执行层的问题，OpenSpec 不是最强项。

所以只用 OpenSpec 时，我经常会觉得：

前面的提案和 spec 生命周期是清楚的，
但进入实际设计和实现时，流程还不够细。

单独使用 Superpowers 时，我遇到的问题

Superpowers 给我的感觉正好相反。

它非常适合管理一次变更的 HOW 。

它会让 AI 不要一上来就写代码，而是先做：

brainstorming
Design Doc
plan writing
TDD
subagent-driven development
code review
收尾检查
这对 AI 编码特别有价值。

因为 AI Agent 最大的问题之一，就是太容易直接进入实现。

你说“加一个登录功能”，它可能马上开始改文件。
但如果没有充分设计，后面很容易出现边界不清、架构不稳、任务失控的问题。

Superpowers 能把 AI 拉回到一个更工程化的节奏：

先思考，再设计，再计划，再实现，再 review。

但也遇到了另一个问题：

它的设计和执行很强，
但完整的 spec 生命周期和归档闭环不够明显。

也就是说，它可以帮助我把一个功能设计得很细、实现得很稳。

但最后我还是会遇到这些问题：

这次变更最终对应哪个 proposal？
delta spec 最后怎么同步到 main spec？
变更完成后怎么 archive？
设计文档和计划文档如何标记最终状态？
以后回头看，怎么知道这次变更为什么发生、如何完成、是否已经归档？

Superpowers 更像是强大的工程执行方法论，
但它不是一个完整的 spec 生命周期管理系统。

所以只用 Superpowers 时，我经常会觉得：

设计和执行过程很扎实，
但最终缺少一个把变更沉淀下来的闭环。

Comet 的定位：不是替代，而是连接

Comet 不是要替代 OpenSpec。

因为 OpenSpec 的提案、spec 生命周期、delta spec 和 archive 这些能力本来就很好。

Comet 也不是要替代 Superpowers。

因为 Superpowers 的 brainstorming、Design Doc、plan writing、TDD、code review 这些执行方法论也很强。

Comet 做的是中间这一层：

工作流编排。

我希望它解决几个问题：

当前变更现在处于哪个阶段？
这个阶段应该使用 OpenSpec 还是 Superpowers？
这个阶段的产出物是什么？
当前阶段完成了吗？
是否允许进入下一阶段？
验证没通过能不能归档？
delta spec 最后如何同步？
整个变更如何形成闭环？
所以我把 Comet 的定位总结成一句话：

OpenSpec 管 WHAT，Superpowers 管 HOW，Comet 管 WHEN & NEXT。

Comet 如何把它们接起来

Comet 把一次开发变更整理成五个阶段：

Open → Design → Build → Verify → Archive

第一阶段：Open
用 OpenSpec 打开变更，生成 proposal、design、tasks，先明确这次到底要做什么。

第二阶段：Design
用 Superpowers 做深度设计、头脑风暴、Design Doc，并补充 delta spec。

第三阶段：Build
用 Superpowers 生成实现计划，并按任务推进代码提交。

第四阶段：Verify
检查测试、任务状态、实现结果和设计目标是否完成。

第五阶段：Archive
回到 OpenSpec，把 delta spec 同步到 main spec，更新状态，并完成归档。

这样一来，OpenSpec 的提案和归档能力没有丢，
Superpowers 的深度设计和执行能力也被接进来了。

两者不再是两个分散的流程，而是一条完整的 AI 编码流水线。

状态机机制

只把流程写进提示词还不够。

因为 AI Agent 很容易出现这些问题：

跳阶段
漏验证
忘归档
状态混乱
重复执行
不知道下一步该做什么
所以 Comet 增加了 .comet.yaml 状态文件，用来记录一次变更的真实状态：

workflow：当前是 full、hotfix 还是 tweak
phase：当前处于 open、design、build、verify 还是 archive
design_doc：关联的设计文档
plan：关联的实现计划
build_mode：选择的构建方式
isolation：使用 branch 还是 worktree
verify_mode：轻量验证还是完整验证
verify_result：pending、pass 或 fail
verified_at：验证通过时间
archived：是否已经归档

同时，Comet 还提供了几个自动化脚本：

comet-guard.sh
用于阶段转换守护，检查是否满足进入下一阶段的条件。

comet-archive.sh
用于一键归档，同步 delta spec、标注文档状态、移动归档目录。

comet-yaml-validate.sh
用于校验 .comet.yaml ，避免字段缺失、枚举错误或路径错误。

comet-state.sh
用于统一读写状态，减少 AI Agent 直接乱改 YAML 的风险。

这样 AI 不再是凭上下文猜下一步，而是根据状态、条件和阶段推进。

后记

市面上的知名Spec SKILL众多，学会组合这些Skill做出适合自己的SKILL也是很重要的能力，在Comet中你能看到嵌套Skill场景下是如何做到底层Skill自动触发，Skill链怎么自动流转的，相信这个项目不仅仅是一种Spec工作流，也是一种学习的方式~