Skip to main content
本页面向需要排查发布状态或接入自动化的用户。常规流程由 /comet-any 引导评估、审批、发布和分发。
本页是 Skill 发布状态机、readiness 与阻塞码的权威说明。命令级参考见 comet publish。 发布前,Comet 会检查当前 hash 的 eval 证据、人工批准和目标平台要求。全部门禁通过后,Skill 才能发布和分发。

发布状态链

每个状态都有明确的门禁: 还有一个异常状态 drift-conflict:处于 ready 状态的 Bundle,如果 draft hash 和 ready hash 都发生变化,会进入冲突状态,并带上 conflict: {draftHash, readyHash}。只有其中一个变化则直接回退到 draft。

readiness 结论

readiness 会给出四种结论:

小鱼检查 eval evidence v2 的 draftHash 和 evalManifestHash,再通过 creator status/next、review、approve 和 publish preview 推进发布

发布前先确认 eval evidence 绑定当前 draft 和 manifest,再用 creator 看状态,用 publish 做评审、批准、发布和分发预览

非 JSON 输出会用这些标题:published → “Already published”。can-publish → “Ready to publish”。needs-confirmation → “Ready for review approval”。blocked → “Cannot publish yet”。

发布流程

comet publish 是 /comet-any 产物的发布入口。它只处理 eval 证据就绪后的 review、approval、publish 和 distribute。创建状态、恢复状态和唯一的下一步由 comet creator 负责。

用户命令

如果包含 hooks 或脚本,分发时需要确认可执行披露:
如果用户明确选择跳过 optional 能力:

status 和 next 怎么选

comet creator next 不暴露后端 Bundle 命令。它会把后端 next action 翻译成日常可执行的命令,例如 comet eval ... --html、comet publish review ...、comet publish approve ...,或提示你回到 /comet-any 解决候选、确认方案、重新生成。

阻塞码(blocker codes)

readiness blockers 会阻止 publish。每个 blocker 都有一个前缀码,告诉你问题出在哪。当 Readiness: blocked 时,按下面的表定位:
每个 blocker 都带 nextAction: ,直接给出恢复建议。想看完整上下文用 comet creator status。只想复制下一条用户命令时,用 comet creator next。

Warning(非阻塞)

这些不阻塞,但会在评审摘要里提示:
  • [preference] advisory 模式下的偏好漂移
  • [review] approval 对应旧 hash
  • [capability] optional 能力缺口
  • [agent] 平台 agent 预览缺失
  • [executable] 可执行披露待确认

评审摘要

发布前必须先看 readiness。comet publish review 的评审摘要至少包含:
  • Bundle 名称、版本、hash
  • 多个 entry 与 internal Skill 列表
  • planHash、preferenceHash 与 reference/resolved-skills.json 真实 Skill 证据
  • 推荐调用顺序与 preferenceIndex
  • 偏离偏好顺序的项和原因
  • .comet/skill-preferences.yaml 是否在 Factory 初始化后发生漂移
  • 稳定组合 Skill Bundle 的 required capability set 是否声明完整
  • 能力缺口和可执行披露
  • Eval 选择、token 消耗和结果摘要
  • Validate this Skill 与下一步提示
非 JSON 输出也会明确展示 Readiness:、Blockers:、Warnings:、Evidence:,让你能直接看懂 readiness 为什么可发布或被阻塞。

分发预览是强制的

执行真实分发前,必须先跑 preview:
preview 是强制检查,不是可选附加项。它会展示:
  • Install preview
  • planned files
  • unsupported capability
  • executable disclosures
  • No files were written
只有你确认 preview 结果后,才可以移除 --preview 执行真实分发。

能力缺口和可执行披露

分发前必须处理平台能力差异: hooks/*.yaml 是 Comet portable hook descriptor,只在 comet publish distribute 编译到目标平台配置后生效。直接把 hook 文件拷到平台目录不会生效。

eval-record 证据契约

如果用 comet bundle eval-record 手工记录 eval 证据,结果 JSON 必须满足这个 schema:
draftHash 必须等于当前 currentHash,evalManifestHash 必须等于当前生成的 comet/eval.yaml hash。旧 hash 或旧 manifest 的证据会被保留到磁盘,但不能推进 readiness。日常使用不需要手写这个文件。/comet-any 会通过 comet eval 自动产出。

Bundle 和 publish 的关系

comet creator 是创建和恢复入口,comet publish 是发布入口。comet bundle 是内部后端,负责 Bundle 状态管理、hash、readiness、publish 和 distribute。除非排障或审计,你不需要直接操作 Bundle 状态文件。 需要排查后端状态时可以参考 comet bundle。

下一步

最后修改于 2026年9月4日