Skip to main content
Comet 把项目配置保存在根目录的 .comet/config.yaml。运行 comet init 时会生成可用配置,大多数项目不需要手工调整。只有你想改变默认工作流、文档语言、澄清方式、记忆策略或交付方式时,才需要修改它。

推荐的 Native 配置

下面这份配置适合使用中文文档的新项目:
这会让 /comet 默认进入 Native,把 change 文档保存在 docs/comet/,使用中文生成正式产物,并以 Batch 模式完成需求澄清。
优先使用 comet init --workflow native 创建配置,使用 comet update 补齐或升级配置。

默认工作流与自然语言恢复

default_workflow 只影响入口,不会把已有 change 从 Native 转成 Classic,也不会把 Classic change 转成 Native。 如果需要同时启用两套工作流,运行:
要关闭自然语言触发的恢复探测,可以设置:
显式调用 /comet 时仍会按照 default_workflow 路由。

Native 核心字段

产物目录

artifact_root: docs 对应 <project>/docs/comet/artifact_root: . 对应 <project>/comet/。路径必须位于项目内。 已有项目需要迁移目录时,不要直接改 YAML 并手动搬文件。让 Runtime 完成检查、切换和恢复记录:

文档语言

native.language 决定之后新建 change 的正式产物语言。已有 change 会继续使用创建时记录的语言,不会因为配置变化而自动改写。

澄清模式

  • batch:一次提出本轮所有前提已经明确、彼此独立的问题,适合减少往返。
  • sequential:每轮只提出一个最上游或影响最大的问题,适合答案会改变后续问题的需求。
两种模式都会先调查仓库事实,并在进入 Build 前要求你确认完整的目标、范围、选择点、验收标准和非目标。切换模式不会清除 brief.md 中尚未回答的 [blocking] 问题。

归档确认

  • automatic:最终 Verify 通过后,Runtime 可以继续完成归档。
  • required:最终 Verify 通过后,再等待你明确同意归档。
automatic 只控制是否额外等待归档确认,不会替你执行 merge、push 或创建 PR 的决定。使用 branch 或 worktree 时,Comet 仍会让你选择实际的交付方式,选项说明见归档与交付

Verify 失败上限

max_verify_failures 限制同一份已确认需求可以经历多少个失败实现轮次。达到上限后,Native 会暂停并让你决定继续、修改需求或停止,不会无限重试。 Runtime 执行错误、缺少外部信息和无法安全恢复的状态会单独返回 await-userblocked,不应通过修改计数绕过。

个人记忆

memory 同时适用于 Native 和 Classic,两个开关默认都是 true 例如,只使用已有记忆但不继续自动学习:

项目知识

knowledge.provider 默认是 local。Comet 会使用内置项目语料,你也可以追加项目中的 Markdown 文档:
knowledge.local.include 只接受项目内的 Markdown glob。路径使用 /,不能越出项目根目录,这些路径会追加到内置语料。 如果团队已经有 RAG 知识库系统,也可以切换为远程 Provider:
endpoint 是你的服务实际接收请求的完整 URL。Comet 会直接向这个地址发送 POST;示例域名需要替换为你的真实接口地址。 远程地址必须使用 HTTPS;只有 localhost 和其他 loopback 地址可以使用 HTTP。token_env 填环境变量名,建议不要把 Token 直接写进配置。超时时间允许 10030000 毫秒。

Hook 写入放行

hook.allow_paths 是 Native 与 Classic 共用的高级配置。它允许指定目录在原本受保护的阶段继续写入,默认为空。 如Shape 阶段不允许Agent写代码,但你拥有其余Hook功能,希望在Shape阶段允许 docs/team-notes 下的文件写入,可以配置:
路径必须是项目相对目录,并使用 /。配置 docs/team-notes 会同时放行其下所有文件。
这个配置会绕过对应目录的阶段写入限制。不要为了避免 Shape、Verify 或 Archive 的正常拦截而放行源码目录。.comet、Native 正式产物区和 Classic 正式产物区仍受专用规则保护,不能通过 allow list 绕过。

自定义 PR 创建命令

默认情况下,归档选择推送并创建 PR 时,Comet 直接运行 gh pr create --fill,用提交信息自动填充标题和正文。如果仓库要求 PR 必须套用自己的模板(例如包含 Checklist、关联 issue 字段),或创建后要跑远端校验脚本,--fill 生成的 PR 就过不了仓库规则。native.finish.pull_request 允许把“创建 PR”这一步换成你自己的脚本,Comet 调用脚本拿回 PR 结果,其余交付步骤不变:
PR 的标题、正文和模板由仓库命令生成,仓库特有的校验也在命令里完成;提交代码、推送分支、查找已有 PR、核对 base/head/head SHA 以及失败后的重试,仍由 Comet 处理。 注意以下限制:
  • provider 当前只支持 repository-command
  • command 必须是非空参数数组;首项使用 PATH 中的命令名或项目相对路径,不能使用绝对路径。
  • timeout_ms 默认 120000,最大 600000
  • 命令在项目根目录执行,通过 stdin 接收 comet.native.pull-request-finish-input.v1 JSON,并通过 stdout 返回 comet.native.pull-request-finish-result.v1 JSON。
  • 即使配置自定义命令,也需要安装并认证 GitHub CLI(gh),供 Comet 独立核验远端状态。
继续阅读:用户选择点与需求澄清协议产物与状态恢复手册
最后修改于 2026年9月4日