Skip to main content
comet bundle 是 /comet-any 和 comet publish 使用的高级后端。它创建平台无关的 Skill Bundle,将其编译为目标平台的 install plan,并处理 Engine metadata、Eval 证据和人工批准状态。 日常创建使用 /comet-any。恢复和查看创建状态使用 comet creator。评审与分发使用 comet publish。只有审计底层状态,或调试编译、能力缺口、评估证据、可执行文件披露这类问题时,才直接运行 Bundle CLI。
如果你只是想创建、评估、发布一个 Skill,请不要从 comet bundle 开始。常规路径是 /comet-any 创建,comet eval 验证,comet creator next/status 看下一步,再用 comet publish 完成评审、发布和分发。

日常使用该看哪里

什么时候需要直接用

  • 审计 Bundle draft 和编译输出。
  • 调试平台 compile、capability gap 或 executable disclosure。
  • 手工记录结构化 eval evidence。
  • 自动化集成需要 JSON 后端命令。

常见后端阶段

Skill Creator 命令已移到 comet creator

0.4.0-beta.1 起,comet creator 是 Skill Creator 对应的命令行入口。下面这些旧的预发布 Bundle 别名不再是当前命令:
对应关系:

创作协议(authoring)

0.4.0-beta.1 起,/comet-any 生成的 Skill 不再只有一个固定流程骨架,而是携带真实人工创作内容。这通过创作协议(authoring protocol)实现:一个由创作通道(lane)组成的有向无环流程,每条通道的输出都经过 schema 校验,最后做一次多轮投票的 Skill 评审。

创作流水线

创作按**波次(wave)**推进,每个 lane 是一个可并行的子任务: 运行创作协议时请用 comet creator authoring-plan 和 comet creator authoring-record。这些命令会:
  • 返回创作计划:要跑哪些 lane、每个 lane 的预期产出、深度(quick 只覆盖必要 lane,full 覆盖全部)。
  • 校验并记录某个 lane 的产出。
  • schema 校验:lane 输出 JSON 必须符合该 lane 的 schema(status ∈ DONE/DONE_WITH_CONCERNS/NEEDS_CONTEXT/BLOCKED,artifacts、findings、evidence 等字段齐全)。
  • claim 校验:lane 声称产出哪些内容(claims),实际产物文件必须存在且匹配。
  • 写入状态:校验通过后把 lane 产出固化到 Bundle 的创作状态(BundleAuthoringState),记录 lane status、findings(severity ∈ critical/important/minor)和 review evidence。
  • review evidence:skill-review lane 的 evidence source ∈ deterministic-check-only/llm-single/llm-multivote,记录真实评审结论(voters、lenses、findings),不再硬编码 approved。

Authored 内容分区

生成的 SKILL.md 由两部分组成:
  • Auto zone(自动区):frontmatter、路由表、Entry/Exit 检查、证据格式、恢复。不变的控制面,由模板生成。
  • Authored zone(创作区):入口的 ## Decision Core、节点的 ## Guidance。由 skill-core / workflow-entry 子 Agent 动态创作。
节点分为 delegates(覆盖层 → 安装富 Skill,薄指导正确)和 substance(工作流内核,必须有富创作指导)。一个 substance 节点如果缺少创作内容会渲染显式的 AUTHORING PENDING stub,并出现在 unauthoredSubstanceNodes 里。这会阻止发布就绪,确保生成器不能再以假完整的薄 Skill 冒充完成。

draft 和 compile 命令

eval 命令

eval-plan

返回 BundleEvalPlan { level, components[], estimatedRuns, tokenWorkload, explanation },是描述性估算,不是 token 承诺:

eval-record

结果必须绑定当前 draft hash 和当前 eval manifest hash。校验规则:
  • result.schemaVersion !== 2 或 result.provider !== "comet-eval" → 拒绝。
  • result.draftHash !== state.currentHash → 只写文件,不推进状态。
  • result.evalManifestHash 不等于当前生成的 comet/eval.yaml hash → 只写文件,不推进状态。
  • 全部通过(result.passed 且 failures 为空)→ status 推进到 eval-passed。
  • 否则回退到 draft,清除 review/ready/conflict。
eval-result JSON 的 schema 见发布和分发 Skill · eval-record 证据契约。

review 和 publish 命令

发布前必须读取 review summary 的 readiness,未满足发布门禁时不得发布 ready。各阻塞码的含义、触发条件与恢复建议以发布和分发 Skill为准。面向用户的发布命令参考见comet publish。

通用选项

Bundle 和 publish 的关系

comet creator 是创建和恢复入口,comet publish 是发布入口。comet bundle 是高级后端,直接操作内部状态。
面向用户的发布路径请优先使用 comet publish。comet bundle 只在排障或审计时直接使用。

下一步

最后修改于 2026年9月4日