> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 用 Any 定制 Classic 工作流

> 选择 full、hotfix 或 tweak，用团队 Skill 替换阶段执行，并追加有产物和恢复路径的检查。

你的团队使用 Classic 的 Spec 流程，但已有自己的 API 设计 Skill 和兼容性审查 Skill。用 `/comet-any` 创建 Classic 组合应用，让团队 Skill 执行指定工作，同时保留 Classic 的阶段文档、真实检查、用户批准和归档要求。

本教程创建一个 full 应用：用团队 Skill 执行 Design，并在 Verify 的检查通过后追加接口兼容性审查。应用安装完成后，用一个小接口改动验证它。

## 1. 选择基础流程

| 流程 | 适合的任务 | 定制前确认什么 |
| - | - | - |
| full | 需要完整需求、设计、实现、验证和归档的功能。 | 要替换哪个阶段的执行 Skill，原阶段输入和文档要求是什么。 |
| hotfix | 范围明确的局部缺陷。 | 是否仍适合快速修复，新增工作放在哪个允许的检查位置。 |
| tweak | 单个 change 的轻量调整。 | 新要求是否已经超出轻量调整，应否改用完整流程。 |

替换针对执行 Skill。领域机器检查、用户批准和机器归档步骤不属于执行 Skill 的替换范围。追加步骤也只能放在原流程允许的检查位置，不能仅靠入口文字把 Verify 或 Archive 移走。

本例选择 full。若希望保留已有 Design Skill、只增加设计审查，请明确说“追加审查”，避免把整个设计执行绑定替换掉。

### 哪些阶段的执行 Skill 可以定制

你只需说清阶段和想改变的做法，Any 负责调查实际步骤、替换绑定和输入输出要求。一个阶段可能包含多个执行步骤，方案应分别列出，不能只替换其中一个就认为整个阶段都已替换。

| 执行位置 | 适用流程 | 可以定制什么 | 必须保留什么 |
| - | - | - | - |
| Open 的需求整理 | full、hotfix、tweak | 替换需求调查、问题澄清和文档编写的 Skill。 | 原范围要求、必要文档和适用的用户确认。 |
| Design 的交接与设计文档 | full；轻量流程升级到 full 后 | 用团队 Skill 编写架构、接口或数据设计。 | 原交接输入、设计产物、检查与批准。 |
| Build 的配置与计划 | full；轻量流程升级到 full 后 | 定制实现指导和任务计划编写。 | 原计划要求和计划证据检查。 |
| Build 的实现执行 | full、hotfix、tweak | 换用团队实现或测试先行的 Skill。 | 真实代码、允许的工作范围和机器检查。 |
| Verify 的验证报告执行 | full、hotfix、tweak | 换用领域验证 Skill，组织测试和报告。 | 原验证报告要求与真实命令结果，不替换机器验收。 |
| Archive 的交付提案与执行指导 | full、hotfix、tweak | 定制交付说明、提交摘要和按批准执行交付的 Skill。 | 当前交付批准、归档预检、机器归档及实际交付核验。 |

### 哪些位置可以追加检查

| 原流程中的位置 | 可以追加什么 | 适用范围与限制 |
| - | - | - |
| Open 产物检查通过后 | 需求完整性、业务约束或领域审查。 | 所选流程；原用户确认仍按该流程处理。 |
| 已批准 Open 产物复核通过后 | 进入设计前的需求审查。 | full；不替代已确认内容的复核。 |
| Design 文档检查通过后 | 架构、接口、安全或可维护性审查。 | full，或轻量流程升级后的 full 路径。 |
| Build 计划检查通过后 | 任务覆盖、依赖或实现范围审查。 | full，或升级后的 full 路径。 |
| Build 真实检查通过后 | 代码质量、性能或额外回归检查。 | full、hotfix、tweak；原检查失败时不能用扩展通过来绕过。 |
| Verify 真实检查通过后 | 接口兼容性、合规或交付前业务审查。 | full、hotfix、tweak；通过后继续原 Archive 条件。 |
| 同一检查位置内的多个扩展 | 调整新增检查的先后顺序。 | 不能把步骤跨阶段移动，也不能改变原领域检查的顺序。 |

新增检查都要声明实际产物、通过条件和失败恢复。需要多个阶段定制时，可以组合多项替换与追加；Any 应展示每项的执行位置及与原流程的关系，再由你确认。

## 2. 准备设计和审查 Skill

先安装 Comet 并运行 `comet doctor`。Creator 使用 Codex 或 Claude Code 的实际加载与交接能力。

本例使用项目内的两个目录：

```text theme={null}
team-skills/
  api-design/
    SKILL.md
    references/api-conventions.md
  api-compatibility-review/
    SKILL.md
```

替换为你的实际路径。设计 Skill 需要读懂当前需求、已有接口和项目规范，生成 Classic 所需的实际设计文档。兼容性审查应能比较旧、新接口行为，说明调用方影响，并产生可验证的报告。

如果现有 Skill 只会输出聊天总结，先要求 Agent 说明如何适配阶段文件。仅把它改名为“Classic Design”不能使输出自动符合阶段要求。

## 3. 提交定制目标

在项目 Agent 会话中输入：

```text theme={null}
/comet-any
把本次创作命名为 classic-api-review，创建 Classic full 组合应用。
读取 ./team-skills/api-design 和 ./team-skills/api-compatibility-review 的真实内容。
用团队 API 设计 Skill 替换 full 流程中的 Design 执行 Skill。
它必须读取当前需求和已有接口，产出原 Design 阶段要求的完整文档。
在 Verify 的实际检查通过后追加兼容性审查，再进入原 Archive 路径。
生成 reports/api-compatibility.md，包含“接口变化”“调用方影响”“验证依据”“结论”。
行为变化必须逐项说明兼容性；未处理的破坏性变化或缺少验证依据时不通过。
失败时保留实现和报告，修复后重新执行受影响检查与兼容性审查。
保留原阶段用户批准、真实检查和归档条件，不代替我提交或推送 Git。
先展示完整方案和正常、异常验收样例，安装到 Codex 项目前再单独请我确认。
```

Agent 会根据 full 的实际步骤选择执行绑定和允许的检查位置。你无需手写步骤 ID，但需要确认“替换 Design 执行”与“新增兼容性检查”是两项不同的工作。

## 4. 阅读替换前后的职责

| 原工作 | 定制后谁执行 | 保留的要求 |
| - | - | - |
| Design 阶段的设计编写。 | 团队 API 设计 Skill。 | 当前需求输入、必要设计文档和用户确认。 |
| Build 的实现与检查。 | 原 Classic 执行与检查入口。 | 实际代码、检查计划、真实命令与当轮证据。 |
| Verify 的验证。 | 原验证步骤，再追加兼容性 Skill。 | 原验证报告与检查，以及新增审查的真实产物。 |
| Archive 与交付。 | 原 Classic 流程和 Agent 执行平台。 | 当前批准、归档证据及实际 Git 交付授权。 |

确认前让 Agent 展示设计 Skill 接收哪些输入、生成哪些文件，以及新增审查读取哪个已通过的验证结果。产物路径按实际方案确定，不应写进 Runtime 控制目录或覆盖核心状态文件。

想进一步修改阶段执行方式，可以要求设计 Skill 增加接口版本策略、错误码规范等指导。涉及新增职责、产物或失败条件时，把变化放进完整方案重新确认，不能只改一段入口说明。

## 5. 让异常样例验证业务检查

要求临时项目覆盖以下场景：

| 场景 | 预期行为 |
| - | - |
| 新增可选参数，旧调用仍通过，报告有检查依据。 | 兼容性审查通过。 |
| 报告四节完整，但删除旧字段且没有迁移或验证依据。 | 业务检查拒绝，不能因格式正确而通过。 |
| 必需设计或审查文件缺失。 | 阶段产物检查拒绝。 |
| 审查后接口或检查输入发生变化。 | 原证据不能证明当前结果，需要重验受影响工作。 |

新增报告不能替代经典流程的原检查。兼容性 Skill 回报成功，也不能把失败的测试命令变成通过。

本地验收之后可选择模型 Eval，关注团队设计 Skill 是否实际生成阶段文件、审查是否识别破坏性变化，以及失败后能否继续修复。跳过模型 Eval 会保留跳过状态，见 [创作、验收与安装](/zh/skill-creator/workflow.md)。

## 6. 安装后跑一个接口任务

检查完整包导出目录、平台入口、固定依赖和 Rule/Hook，确认安装当前预览。应用与默认 Classic 入口分开使用；入口名称以安装结果为准。

加载新应用的入口 Skill，提出：

```text theme={null}
使用已安装的 classic-api-review 应用，为列表接口增加可选分页参数。
现有调用方不传参数时仍保持原行为。
设计文档需说明默认值，验证报告与兼容性报告需包含旧调用和新调用的实际检查依据。
```

在 Design 阶段核对团队 Skill 的实际文档，再提交当前设计决定。Build 和 Verify 使用真实命令；兼容性报告不通过时先修复并重验，不能为了进入 Archive 填写“已完成”。

最后仍需确认实际交付范围。批准本地归档、提交、推送或 PR 是不同选择，应用创作或安装的批准不替代业务任务的交付批准。

## 7. 恢复与修改应用

创作中断时读取原记录：

```bash theme={null}
comet creator status classic-api-review --project . --json
comet creator next classic-api-review --project . --json
```

如果中断的是已经安装应用的业务任务，继续原应用 Run，不要重新运行 Creator 再建同名流程。执行结果未知时核对原操作，详见 [恢复与未知结果](/zh/sdk/recovery.md)。

以后更换团队设计 Skill 或改审查条件时，提供原应用包、明确新增要求，并重新准备和确认版本。升级保留活动 Run 使用的旧版本。hotfix、tweak 要改成完整流程时，要求 Agent 使用领域允许的升级路径，不直接改状态文件里的 profile。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.