comet-any

Comet Any

调查与用户目标相关的真实 Skill，然后编写应用的文档、工作流和业务实现。使用 comet creator 保存计划和进度。每个阶段结束后，读取当前操作并继续，直到完成、需要用户决策或遇到外部能力阻碍。

Agent 编写入口 Skill、业务 Rule、执行端口和验证器。SDK 保留文档，追加执行协议和通用保护规则，并组装 Runtime。业务 Rule 描述业务约束；Runtime 和 Guard 控制操作、审批和写入权限。安装使用正式 SDK 分发。

开始或继续

1. 已知创建名称时，运行 comet creator status <name> --project <project> --json，然后运行 comet creator next <name> --project <project> --json。保留原始名称和 Run；中断后，检查原始 Action，不要重复已完成的工作。
2. 新建时，读取 comet creator guide --project <project> --json。根据用户的描述确定目标和安装位置；只询问那些无法调查且会改变结果的选项。使用 comet creator start <name> --project <project> --goal <user-goal> --install-target <relative-directory> --host codex|claude-code --json 开始。
3. 首次声明或提交操作前，阅读创建操作与恢复。使用返回的 Action、attempt、inputHash 和当前主机的会话标识；如果当前操作缺少必需能力，请报告阻碍并保留当前工作。

分析与计划

主机在 analyze 阶段进行调查和编写。需要委派时，提供原始目标、当前操作、范围和固定依赖项。

1. 使用 comet creator candidates --project <project> --json 发现候选项；阅读每个候选项的 SKILL.md、脚本和必要资源。检查实际输入、输出、授权、主机能力、完成条件、失败和恢复方式。不要根据名称推断能力，也不要修改第三方原件。

2. 对计划所需的每个 Skill：

   立即执行： 使用 Skill 工具加载 skill。禁止跳过此步骤。

   加载 Skill 后，根据其实际内容完成适配器契约和内容哈希。自行审批或发布的 Skill 必须声明这些能力及其副作用。

3. 选择用户所需的起点：向 Native 添加步骤、指导和审核；在允许的位置将 Classic 完整组合到 full、hotfix 和 tweak 中；或声明独立工作流的顺序、分支、汇合、子工作流和有限修复。在 Runtime 中加入用户交互、共同理解确认和实施步骤。

4. 编写完整的入口 Skill：其 frontmatter 中的 name 必须等于应用 ID，description 说明其适用场景。正文说明输入、依赖 Skill 调用、交互与审批、产物、验收、失败和恢复方式。业务 Rule 必须约束实际业务行为。必要时将详细材料放入参考文档，并说明何时阅读。

5. 按照参考文档中的 documents 结构返回文档，以及工作流和业务端口。为每个执行阶段声明 manifest.artifactContracts：提供真实文件引用、内容要求和必要的业务验证器；若无需文件，则填写 noArtifactsReason。为每个需要产物的阶段提供一个正向 artifactTests 用例；业务验证器还需要提供通过通用文件检查的反向用例。编写文档前，先澄清未知需求。结构详见创建操作与恢复。在分析阶段补齐缺失的文档、实现、验证器、依赖项或能力；若已有计划，则使用 revise 和 reconfirm。

确认、验证与交付

1. 当 next 进入计划确认阶段时，展示完整文档、内容哈希、实际步骤、Skill 绑定、制品、检查项、失败路径和能力限制。说明编译后可选进行 Eval。
2. 用户明确批准当前计划后，提交用户对当前 confirm-plan 的决定。哈希仅用于标识计划；拥有哈希并不代表获得授权。拒绝会保留当前工作；如需更改计划，请使用 revise，并重复受影响的确认和验证。
3. 继续调用 next 以编译、加载应用并验证必需制品。在隔离目录中，SDK 会检查正向用例是否完成，并自动构建缺失文件、空文件和内容已更改的用例，验证被拒绝的结果是否保留原始 Action。实际业务验证器必须拒绝其负向用例。安装前必须通过这些本地检查；跳过模型 Eval 不会跳过这些检查。失败时，保留当前工作，修正计划或制品，然后继续原始 Action。
4. 在 confirm-eval 阶段，展示 Agent、模型、用例数、交互轮数和总超时时间，然后让用户选择评估、跳过或修订。选择评估后，调用 next 执行并保存报告。重试会复用原始用例；修订时优先保留这些用例。评估失败或未完成时，会停在 review-eval；展示报告和未覆盖的路径，然后让用户选择重试、修订或明确跳过。跳过会保留实际状态。
5. 安装前，展示导出目录、平台入口、固定依赖项、Runtime、Rule/Hook 配置、冲突和 Eval 状态；预览不会写入安装目标。请使用与平台入口分开的 install-target 导出目录，例如 .comet/creator/exports/<application-name>。用户明确批准当前预览后，提交 confirm-install；Creator 会导出并正式安装应用。预览失败或安装中断后，遵循参考文档中的恢复步骤。更改目标、依赖项、文件、配置或评估报告后，必须重新确认。
6. 交付软件包和入口位置、实际检查、Eval 报告、未执行的项目及限制。分别报告实际的 Skill 加载、Rule 配置、Hook 执行、SDK Run 和业务断言；已安装的配置并不能证明 Hook 已激活。

恢复边界

• 继续使用原始 Run ID、当前 Action/Wait 和输入哈希；不要重复使用过期请求。
• 根据原始实验、进程或制品核对不确定的执行情况。无法核对时，保留当前工作并阻止继续；不要盲目重试。
• 仅通过执行环境注入凭据，绝不要将凭据写入计划、源代码、生成的软件包、Run 或报告。