comet-review

Comet 手动代码审查

对当前选定的 Comet 变更执行一次按需、只读的代码审查。此条目不是工作流阶段，也不会取代 Build 或 Verify 检查与审查。

此条目独立于 review_mode。该字段控制工作流中的自动审查；/comet-review 是用户明确请求的一次单独审查。此次调用期间，不要读取、修改或覆盖当前变更的 review_mode。

执行只读操作

整个 Skill 调用必须保持只读：

• 不要修改、创建或删除文件。
• 不要暂存、提交、切换分支、创建分支或创建工作树。
• 不要运行 comet state select、comet native select、comet state set、comet state transition、阶段守卫、comet native next 或归档命令。
• 不要修复发现的问题、推进阶段，也不要更新任务、状态、验证报告或审查记录。
• 不要将此审查称为 Verify 通过，也不要把“未发现问题”当作测试已通过的证明。

只运行读取文件、查询状态和检查 Git 差异所需的命令。可能会执行项目代码、安装依赖项或生成文件的检查不在此条目的范围内。

1. 定位项目和当前变更

1. 使用只读 Git 查询查找项目根目录。在 Git 仓库之外，使用当前 Comet 项目根目录。

2. 在项目根目录运行：

   comet status . --json
   

3. 读取 .comet/current-change.json，并按以下顺序选择审查目标：

   • 如果文件包含有效的 comet.selection.v2，则使用其 workflow 和 change。
   • 如果不存在选择项，且状态仅列出一个未归档的 Comet 变更，则仅在本次审查中使用该变更；不要写入选择项。
   • 如果不存在选择项，且存在多个变更，则列出其名称、工作流和阶段，请用户选择一个，然后结束此次调用。
   • 如果选择项指向缺失、已归档或无效的变更，则报告选择项已过期或无效，并停止，不要修复它。

忽略 Comet 不管理的常规 OpenSpec 变更。即使所选工作流与默认工作流不同，也不要将所选工作流替换为默认工作流。

2. 收集审查上下文

只读取此变更所需的上下文。每项事实都要保留对应的源路径或命令。

Classic

1. 阅读并遵循 comet-classic/reference/classic-layout.md，以确定项目的 Classic 逻辑根目录。

2. 阅读当前变更的 proposal.md、design.md、tasks.md 和 specs/*/spec.md。同时阅读任何链接的 Design Doc。

3. 使用以下只读查询获取阶段、基线和现有证据引用：

   comet state get <change-name> phase
   comet state get <change-name> base_ref
   comet state get <change-name> plan
   comet state get <change-name> verification_report
   

4. 阅读 comet status . --json 返回的现有计划、验证报告和 Build/Verify 命令检查。将缺失的证据标记为“未提供”；不要推断失败或成功。

Native

运行以下只读命令：

comet native show <change-name> --json
comet native status <change-name> --details --json

遵循返回的引用，阅读 brief、完整的拟议 Specs、验收标准、Builder 交接内容、检查、验证、风险、阻碍事项和验证报告。仅使用当前候选项/迭代的证据。历史迭代可用于说明仍然存在的风险，但不得覆盖当前状态。

3. 确定实现差异

1. 运行 git status --short --untracked-files=all，列出工作树中所有已暂存、未暂存和未跟踪的文件。
2. 根据当前变更的需求、工作区绑定、Git 历史记录和工作树状态，确定最可靠的相关范围。对于 Classic，优先使用有效的计划 base-ref；如果该值缺失或无效，则回退到状态中的 base_ref。这两个值不必一致。只有两者都无效时，Classic 基线才算缺失。对于 Native，使用状态中的工作区关系，以及界定当前候选项实现范围的证据。
3. 检查从可靠基线到当前工作树的完整差异，包括已提交、已暂存和未暂存的变更。阅读属于此变更的所有未跟踪文件，包括源代码、测试、文档、配置和元数据，例如 SKILL.md 和 agents/openai.yaml。明确标出这些文件为未跟踪文件。
4. 排除明显属于其他变更或无关用户工作的内容。只有当歧义会实质影响审查结论时才询问用户。否则，依据现有证据继续，并在报告中说明范围假设。

如果现有证据仍无法确定可靠且可验证的基线，则审查可见的工作树差异，并显著标明审查范围不完整。

4. 执行审查

审查需求、任务和当前差异，仅关注以下内容：

• 实现是否正确，以及明显的逻辑错误。
• 安全、权限和路径边界风险。
• 错误处理、兼容性和重要边缘情况。
• 遗漏的任务，或与本次变更明确需求相矛盾的实现。
• 测试是否覆盖变更行为，以及现有测试证据是否支持结论。

不要报告风格偏好、无关重构，或没有具体影响的猜测。每项发现都必须指出文件和行号，并说明触发错误或风险的输入或情况。证据不足时，应降低严重性，或将其列入“待确认问题”。

仅使用以下严重性级别：

• CRITICAL：安全遭到破坏、数据丢失，或核心工作流无法使用。
• IMPORTANT：明显的正确性错误、缺失核心验收要求，或可能导致回归。
• WARNING：真实但不会阻塞的边缘风险或测试缺口。
• SUGGESTION：具体改进建议，不影响当前正确性。

5. 报告结果

先按严重性排序列出发现。使用以下格式：

[IMPORTANT] Short title — path/to/file.ts:123
Impact: The input or situation and the resulting error.
Evidence: The specific relationship to the diff, task, spec, or verification record.

然后包含：

• Review scope：工作流、变更、阶段、基线、纳入的差异，以及任何范围限制。
• Evidence status：检查过的测试、构建和验证记录，以及这些记录是否仍适用于当前变更。不要重新运行测试。
• Open questions：仅列出确实妨碍判断的问题。
• Conclusion：发现数量，或明确写明“没有具体发现”。

即使没有发现，也要说明剩余风险和未执行的检查。最后以此提醒结束：

这是一次只读的人工审查，不会推进 Comet 阶段，也不能替代 /comet-verify 或 Native Verify。

如果用户随后要求修复，则将其视为新的写入任务：离开此 Skill，并按照仓库当前的工作流规则恢复开发。