code-ultrareview

Code ultrareview

严重 — 对抗性验证

采取行动前，先核实影响重大的发现和决策。

• 对关键或有争议的主张，寻找反例和独立证据。条件允许且有帮助时，邀请新的审阅者；并将连续的自我审阅标记为独立性较低。
• 通过更正、有证据支持的反驳，或明确说明仍存风险，来处理重大问题。绝不默默忽略。
• 以证据为准，而非审阅者人数或单纯的信心。一项可复现的缺陷就可能推翻结论。
• 根据风险程度调整验证力度。已确认的事实无需反复确认；对可逆且影响较小的检查应从简。

重要 — 工程规范

编写、编辑或提出代码时，请遵循以下规则。

• 用最小且完整的改动解决已确认的问题。复用现有机制；保留无关改动。验证外部输入和实际故障状态。
• 编辑前，先阅读受影响的实现、调用方和共享工具。代码相关主张须以检查所得的证据为依据。
• 实现通用行为。测试必须能区分正确行为与缺陷；绝不针对固定测试数据硬编码，也不保留已明确错误的测试。
• 在交接过程中保留范围、修正内容和现有授权。运行适用的必要检查；仅针对行为变更或未解决的失败重复检查。

严重 — 标签规范

从已交付的代码和文案中移除私有规划标签和过程叙述。直接说明领域行为。

• 规划标签 — 将 WS-N、Phase-A、Step-3 和私有计划名称替换为领域术语。
• 过程叙述 — 删除编写历史，以及需要私有规划背景才能理解的引用。说明最终的行为或约束。

保留有用的问题链接、公开工单编号、用户要求的可追溯信息，以及由制品格式定义的标签。面向审阅者的迁移文档可以提及已删除的制品。

八轴判断代码审查。 五阶段流水线：范围 → 工具组合 → 8 个并行轴向审阅者 → 全新上下文验证者 → 综合。默认以完整强度运行——审阅所有轴、执行所有适用检查，不抽样；--axes 表示明确限定范围的审查，不提供仓库结论。不同于 Anthropic 的远程 /ultrareview——目标相同，但在会话中使用用户的订阅。

重要 — 写作规则

对输出的文案应用以下规则：文档、注释、提交消息、PR 正文和发布说明。

• 与上下文中的标点、大小写和格式保持一致。
• 每个句子都应改变读者的理解，否则就删掉。
• 以行动或结果开头。
• 使用具体的语言，并在有助于比较或说明顺序时使用列表。
• 用肯定句陈述。仅在确有约束时使用否定句（NEVER commit secrets）。
• 不使用营销用语：powerful、robust、seamlessly、leverage、unlock、comprehensive、delightful。
• 不使用 AI 常见套话：delve、tapestry、intricate、pivotal、testament、underscore、crucial、garner、showcase、additionally、moreover、furthermore、indeed。
• 对实质性的英文文案，如果已安装 /humanize-en，则在现有范围和授权内使用。它不会增加审批环节；对简短状态文本跳过重复处理。

目标

默认情况下，在宿主可用的时段内安排 8 个轴向审查器分别运行：正确性、简化、测试、文档、风格、意图、设计/API、性能，并向其提供 scripts/run_battery.sh 生成的确定性工具发现结果。元数据文件发生变化时，连贯性会作为第 9 个轴向加入。每个轴向和工具观察结果都会经过上下文验证。沿用宿主模型；置信度是本地报告规则，不是经过校准的概率，也不能证明正确性。发现结果会综合为一份报告，其中包含确定性去重、轴向间优先级处理、A2 不静默丢弃机制，以及结论（可发布 / 修复后发布 / 需要处理）。报告以“我未检查的内容”结尾，明确说明覆盖范围的限制。--axes 会有意缩小分析器和 LLM 审查的范围，并生成范围限定的发现结果，不给出仓库级结论。

参数

标志	行为
-s	将报告和 JSONL 保存到 ~/.agents/output/{project}/code-ultrareview/code-ultrareview-{slug}.{md,jsonl}
-S	强制不保存（覆盖任何环境级保存模式）
-b <ref>	覆盖审查基准（跳过通过 scripts/resolve_base.sh 自动检测）
--repo-kind <kind>	覆盖范围分类器。可选值：skills、app、library、docs、monorepo、python、rust、go、unknown。每个仓库的持久覆盖配置位于 .code-ultrareview.yaml（repo_kind: <kind>）；发生冲突时以该标志为准。值无效时退出码为 2
--reconcile <input>	激活意图轴推导子模式。<input> 可以是 @auto、@pr、显式路径或目录、gh:pr:<N>、gh:issue:<owner>/<repo>#<N>，或 GitHub issue URL。发现结果分类为 GAP / SCOPE-ADD / DECISION-OVERRIDE / CONSISTENT
--verify-build	在新上下文验证器运行前，将仓库的规范测试命令作为原子门禁运行。缺少命令或运行器时退出码为 3；失败或超时时退出码为 4。通用构建结果绝不会改变发现结果的置信度
--mutation-test	运行 Stryker（JS/TS）、Pitest（JVM）或 mutmut（Python）。Maven 和 Gradle 在 PATH 中以离线模式运行。JS/TS 执行目标为已更改的源文件；按项目配置运行的 Python/JVM 会将结果筛选为针对已更改文件的发现结果。存活的变异体会作为 🟠 中等优先级结果转交给测试轴
--apply-safe	启用写入操作：自动应用低风险修复（清单版本同步、带完整一致性检查的结构化字段描述同步，以及针对已确认 bug 的一项失败测试）。任何写入前都会预览 diff，并逐文件确认
--include-prose	连贯性轴也比较 README 中的自由文本段落（默认：仅比较结构化字段）
--axes <list>	以逗号分隔的轴向子集（例如 correctness,tests）。仅生成范围限定的发现结果，绝不提供仓库级的可发布 / 修复后发布 / 需要处理结论。默认：全部 8 个轴向；触发条件满足时还包括连贯性
--preflight	运行 scripts/preflight_tools.sh --scope <scope.json> — 验证适用的分析器，并为缺失的分析器打印准确的安装命令。覆盖不完整时退出码为 3；绝不安装

小写表示启用，大写表示禁用。不提供 -f — 此技能负责生成内容，而非使用内容。

/code-ultrareview                              # full 8-axis review, print report
/code-ultrareview -s                           # save the report + JSONL for /apex -f
/code-ultrareview -b origin/main               # review HEAD against an explicit base
/code-ultrareview --verify-build               # require the canonical project test gate to pass
/code-ultrareview --mutation-test              # require configured mutation coverage on changed code
/code-ultrareview --reconcile @auto            # add Intent derivation sub-mode with auto-detect
/code-ultrareview --apply-safe                 # full review + gated low-risk fixes
/code-ultrareview --preflight                  # list tools the battery would run, no review
/code-ultrareview --axes correctness,tests     # subset of axes

工作流

在编排审查前，阅读 references/pipeline.md；其中定义了范围、分析器调度、原子失败语义、信任边界和覆盖限制。阅读 references/orchestration.md，了解 Phase 3–5 的确切命令和架构，然后仅加载 references/axes/ 中选定的维度简述。

1. 运行 scripts/scope.py，以确定差异、变更行范围、仓库类型、语言、Coherence 激活状态和有效指令链。只有当有效 AGENTS 入口文件明确引用共享规则文件或目录时，才会加载这些规则。
2. 运行 scripts/run_battery.sh。只有在有覆盖范围的 package.json 下才运行 Knip：没有则记录为不适用，部分覆盖则阻止执行。仓库根目录中的 JavaScript 声明，或一个覆盖所有工具相关输入的工作区声明，具有权威性：使用其项目二进制文件，包括离线 Yarn Plug'n'Play 执行；若该二进制文件不可用，则阻止执行。存在多个声明或包范围混合声明与未声明时，在仓库根目录统一声明分析器之前，阻止执行。未声明的分析器可以使用已安装的 PATH 命令；Python 和原生分析器使用 PATH。技能运行期间，任何分析器都不得解析包。
3. 使用 scripts/axis_dispatch.py 准备每个选定维度，然后根据宿主可用的槽位安排审查者。如果没有隔离 Agent 的原语，则在共享上下文中依次运行审查流程，使用相同的摄取约定，并说明其独立性较低。
4. 为每项发现准备并运行上下文验证器，包括工具观察结果和高置信度的作者声明。工具观察结果的初始置信度为 0，直至经过评估。任何发现都不得在没有记录判定的情况下消失。
5. 只有在所需的工具、维度、验证器、构建、变异和核对覆盖均已完成后，才运行 scripts/synthesize.py。生成规范报告和 Conventional Comments JSONL。

电池会以原子方式预检所有适用的分析器。调用无效或输入不安全时退出码为 2；缺少先决条件时退出码为 3；分析器失败、超时、输出格式错误或覆盖不完整时退出码为 4。每种失败都会打印针对项目的修复建议和确切的重运行命令，不发布任何部分发现，并阻止给出任何仓库判定。--verify-build、--mutation-test、--reconcile 和 --apply-safe 均为可选项；使用前请阅读 references/ultra-execution.md。

最终报告布局

templates/code-ultrareview.md 是规范的线格式——每个 ## 章节都必须按模板顺序原样呈现，并带有其表情符号前缀；不得重命名、合并、重排或自行发挥。必须回显到终端——每次调用都必须将完整的规范报告打印到聊天终端；-s 仅为附加选项（将相同字节写入 ~/.agents/output/{project}/code-ultrareview/code-ultrareview-{slug}.md，与终端输出逐字节一致）。严重性标记映射（🔴 高：阻止发布 · 🟠 中：尽快修复 · 🟢 低：小问题 · ⚠️ 未验证：低于 80）位于 scripts/synthesize.py:SEVERITY_MARKERS。

信任模型

该技能会摄取第三方内容——项目指令文件、PR 正文、规划材料（--reconcile）、GitHub issue 正文——这些内容可能包含间接提示注入。维度审查者和验证器均为只读（不使用 Write / Edit / Bash 进行修改）。在任何 --apply-safe 写入之前，用户对报告的审查是信任边界；--apply-safe 本身也会通过差异预览和逐文件确认来限制写入。

Phase 2、--verify-build 和 --mutation-test 会使用你的环境执行被审查项目所声明的工具；请在沙箱中审查不可信的检出内容。

规则

• 仅报告新发现。 仅报告差异引入的问题。为提供上下文，预先存在的问题标记为 Pre-existing 层级，绝不改变评审结论。
• 不得悄然丢弃（A2）。 分数低于 80 的正向发现必须出现在 ### ⚠️ Unverified 中，并注明分数和验证器给出的原因。验证器分数为 0 时，综合阶段会拒绝该发现。
• 失败时明确报错。 无法解析基线、缺少前置条件、分析器失败或报告无效，都会在给出结论前停止评审。
• 精确引用。 每项发现都必须注明 file:line；涉及指令规则的发现必须逐字引用违反的规则，并注明其来源文件；永久链接格式为 https://github.com/<owner>/<repo>/blob/<full-sha>/<path>#L<n>-L<m>（完整 SHA 通过 git rev-parse HEAD 获取）。
• 每次都在聊天中输出完整报告。 每次调用都会将完整报告打印到终端。-s 会将相同内容写入磁盘；它不会控制或概述聊天输出。
• 分析器由用户管理。 缺少工具时，预检 stderr 和 tool-preflight.json 中会显示准确的安装命令。用户安装后，再次运行评审。
• 默认只读。 只有使用 --apply-safe 才会修改代码；每个写入器都只进行精确的单文件修改，并逐文件确认。

边界

• 始终说明未检查安全评审、运行时分析和不稳定测试检测。
• 没有指令链时，风格轴只能采用相邻内容中反复出现的惯例；不得凭空臆造偏好。
• 未知仓库类型使用 unknown 轴分支。未启用的一致性轴仍会显示在报告标题中。
• 除非明确指定 --apply-safe，否则此操作只读。范围更广的修复请交由 /apex -f <saved-report> 处理；单项发现请交由 /oneshot 处理。
• 这与 Anthropic 的远程 /ultrareview 不同；它在当前 Agent 会话中运行。

参考资料

• 流水线 — references/pipeline.md（范围、电池、硬性停止条件、信任、覆盖率），references/orchestration.md（Phase 3 + 4 + 3.5 准备 CLI 和捆绑包架构）。
• 评审器基元 — references/anthropic-verbatim.md（评分标准 + HIGH SIGNAL + 误报分类），references/axes-overview.md（8 个轴 + 一致性 + 轴间优先级），references/axes/<name>.md（各轴简介）。
• 可选标志 — references/ultra-execution.md 全面介绍了 --verify-build、--mutation-test、--reconcile、--apply-safe。
• 脚本 — scope.py（Phase 1）、run_battery.sh + battery_ingest.py（Phase 2）、axis_dispatch.py（Phase 3）、run_validators.py（Phase 4）、synthesize.py + synthesis_core.py + findings_to_jsonl.py（Phase 5）。可选：run_build_verify.py、run_mutation.py、derivation/run.py、preflight_tools.sh（--preflight）、apply_safe/{version_sync,description_sync,failing_test_writer}.py。