review-fix

Review fix

从已解析的 Review Policy 开始，运行 Review Round，直到审查通过：

/review-fix [target] [free-form review brief]

示例：

/review-fix
/review-fix #123
/review-fix over-engineering
/review-fix #123 specification compliance and authorization boundaries
/review-fix ponytail-review and ask-exemplar

明确的审查简述会选择 Review Policy；未提供简述时使用 Default Review Policy。此技能负责审查者编排、证据核验、修复和检查。

解析请求

仅当开头的参数可明确解析为现有 Git 引用、当前仓库中的 PR 或 MR 编号，或 PR 或 MR URL 时，才将其视为目标。否则，将当前分支和工作树作为目标，并将整个参数视为 Review Brief。

将明确指定的目标解析为可编辑的本地检出，且不得干扰未提交的工作。如果无法安全检出 目标，则结果为 incomplete。按以下顺序从 Forge 元数据、上游分支或仓库默认分支确定 目标的基准分支。

如果请求未包含简述，则使用下方的 Default Review Policy。这也适用于仅指定目标的请求， 例如 /review-fix #123。

解析审查策略

Review Request 以仅报告的审查角色运行。Leaf Review Skill 只有一个角色；Composite Review Skill 包含其必需的审查角度和综合分析。编排器会直接安排每个角色，并执行组合 综合分析。这些调度规则优先于被调用技能中的嵌套委派和新建 Agent 要求；其审查标准和 必需报告保持不变。

• 每个明确指定的审查技能都会创建一个 Review Request。
• 明确指定的技能会取代 Default Review Policy，而不是在其基础上追加。
• 在预检阶段读取每个指定的技能。接受能在不写入或进行外部更改的情况下完成请求的 Leaf 和 Composite Review Skill。拒绝存在循环的技能，以及其必需的后代技能无法解析 或无法保持仅报告模式的技能。
• 未指定技能时，将简述与已安装的 Review Skill 匹配。若有一个明确匹配项，则使用该技能； 若没有匹配项，则根据简述创建一个临时 Reviewer；若有多个合理匹配项，则需要使用原生 结构化输入选择一个。在完成选择前，不启动 Reviewer，也不更改目标。只有调用方明确 要求多个 Review Request 时，才提供多技能面板。
• 不涉及技能的简述即使包含多个关注点，仍作为一个临时 Review Request 处理。绝不将 普通文本拆分为隐式面板。
• 明确指定的技能名称周围的文本会细化这些请求。如果文本明确增加了一个未分配的独立 关注点，则询问该关注点应归属于某个指定的 Reviewer，还是由单独的临时 Reviewer 处理。

在启动任何 Reviewer 之前，预检所有审查角色。将指定技能及其必需审查技能解析为绝对 目录，以便即使模型调用被禁用，每个 Agent 也能直接读取其技能。运行时负责选择模型和 推理力度；此技能不包含模型矩阵。

安排审查者

每种审查角色都需要一份单独的报告，而不是单独的 Agent 线程。 检查可用的容量和生命周期工具，然后在有限的池中安排各个角色。审查者负责检查并报告；只有编排者可以委派任务。

• 如果可以关闭已完成的线程，优先安排新的审查者。收集其最终报告，并在替换前使用可用的生命周期工具关闭线程。仅凭任务完成或中断，不能证明已释放名额。
• 如果无法关闭线程，则通过后续任务依次复用空闲的审查者。每项任务都要说明其角色、当前快照、评判标准和仅报告的边界。要求重新检查源内容并提交报告；先前的结论是需要质疑的证据，而非权威依据。披露保留的上下文和独立性降低的情况，不要将复用的审查者称为新审查者。
• 遇到容量限制而被拒绝时，收集尚未提交的报告，并复用一名空闲审查者。只有在容量或生命周期状态发生变化后，才重试创建审查者。如果没有审查者能够执行某个必需角色，则返回 incomplete；容量限制不能成为省略某个角色的理由。

记录角色与 Agent 的分配关系、池的峰值规模，以及审查者是新安排还是复用。依次分配任务和综合分析期间，始终遵守轮次屏障。

默认审查策略

如果调用者没有提供审查简报，则每行使用一份审查请求。该模式将具备写入能力的技能限定为仅用于报告的评估。

审查技能	模式
code-review	标准与规范审查
simplify	仅报告的综合审查技能，包含复用、简化、效率和层级审查者
improve-codebase-architecture	使用 codebase-design 术语进行受差异范围限制的深入分析，并设置一个仅报告的探索角色；返回调查结果，不得创建 HTML、打开浏览器、启动反复追问循环或写入文件
ask-exemplar	内嵌式评估

确立范围约定

开始第一轮之前，根据用户简报、目标问题或 PR、仓库术语、仓库说明和相关持久文档，制定精简的范围约定。

记录预期行为、规范术语、负责的依赖项或模块边界、明确的非目标事项，以及所需的验证。缺陷主张必须维护范围约定中的某项条款或具体的仓库标准，并指出其在受审查更改中造成的后果。将缺乏依据的观察记录为建议，而不是已验证发现或修复工作。

运行直至干净

在各轮中，始终以已解决的 Review Policy 为准。完整审查轮会派发每个审查请求；增量审查轮只会派发受影响的审查请求。第一轮为完整审查轮。修复后，只有在能够明确证明受影响集合完整、每项已接受声明均已验证并关闭、修复关卡通过，且修复未改变公共接口、跨模块行为、依赖边界、安全边界或契约条款时，干净的增量审查轮才可以结束本次运行。存在歧义时，必须在后续进行完整审查轮。

在编排状态中维护两个精简台账，切勿将其放入目标中：

• 运行台账记录每轮的范围、HEAD、状态、差异哈希、审查者角色与 Agent 的分配及池大小、报告、目标变更结果、修复、检查和 CI 分类。
• 声明台账按位置和含义为每项声明建立键，并记录其范围契约或仓库标准依据、来源、证据、所需验证，以及以下一种发现状态：已接受—待处理、已接受—已修复、已拒绝（附理由）、未验证（附证据缺口）或已验证—关闭。分别记录每项拟议补救措施的来源和处置结果：已接受、已拒绝（附理由）或已被替代（附替代方案）。合并重复声明时，不得抹去补救措施的处置决定。只有在新证据回应了已记录的拒绝理由时，才重新考虑已拒绝或已被替代的补救措施。

修复后，根据修复差异推导受影响的审查请求。纳入报告了已接受声明的每项请求，以及其审查标准涵盖变更文件、接口、同级路径或行为的每项请求。存在歧义时，扩大集合。如果该集合涵盖完整 Review Policy，则下一轮为完整审查轮。

轮次屏障

每个审查轮对应一个不可变的目标快照。提前收到的审查者报告应排队等待，不得据此采取行动。只有在所有必需角色均已提交报告，且目标仍与本轮记录的 HEAD、状态和差异哈希一致时，屏障才会关闭。只有屏障关闭后，才能开始直接检查、综合、验证和编辑。审查失败或超时，或目标发生变化，都会使结果变为 incomplete；不完整的轮次绝不授权修复。

1. 记录目标的 HEAD、状态和完整差异。这会开启本轮屏障。
2. 选择 Full 或 Delta 轮次，并记录纳入每项请求的原因。在 Schedule reviewers 下分配所有纳入的角色。为每位审核者提供相同的目标、基准、差异范围、Scope Contract、Claim Ledger 和仓库说明。将账本结论标记为先前证据，而非权威依据：每位受指派的 Reviewer 都必须独立检查当前目标，并可对这些结论提出质疑。具名技能 Reviewer 应阅读并遵循该技能及其必需的参考资料；临时 Reviewer 则以 Review Brief 作为审核标准。
3. 要求每位 Reviewer 只检查并报告分配给自己的角色，不得委派。对于组合技能，保留各自独立的角度报告；本轮屏障关闭后，由协调者应用其聚合规则。任何 Reviewer 均不得修改文件、提交更改、在代码托管平台发表评论或推送更改。每项发现都必须包含其位置、主张、证据和建议的补救措施；确认无问题的 Reviewer 应明确说明。
4. 继续之前，先关闭本轮屏障。
5. 对于无法通过检查源代码判定的可观察主张，安排最小范围内的直接检查。无法进行该检查时，保留一项自动化缺口，不要将同一主张重新派发为新的请求。未验证的主张不构成发现，也绝不能据此修复。
6. 编辑之前通过 Synthesis Gate。按根本原因合并主张，同时保留每位 Reviewer 的来源信息；针对确切源代码、Scope Contract、仓库规范或可观察行为独立验证每项假设，并解决补救措施之间的冲突。根据契约、可能的回归路径及同级调用方测试每项拟议补救措施。拒绝推测性加固和范围扩张，然后将兼容的最小根因修复合并为一批。补救措施冲突未解决时，结果为 incomplete。
7. 以小幅修改应用综合修复批次。不得扩大目标范围；若没有 Verified Finding，不得修改相邻代码。
8. 记录任何结果之前，先通过 Verification Gate：运行 Scope Contract 要求的验证，以及范围内最相关的测试、lint 和类型检查。如果现有测试无法观察到更改后的输出界面，则应直接测试该界面。修复后，此步骤即为 Repair Gate：还必须独立确认每项已修复主张均已消除，并检查根因相同的同级路径。代码或测试失败、未满足必需的验证要求，或修复不安全，都会使结果变为 incomplete。 仅当目标没有未提交的更改，且本次运行的 head SHA 与本轮记录的 HEAD 相符时，才能将远程 CI 视为针对已审核快照的证据。否则，该运行只是先前背景信息，不属于 Verification Gate 证据。如果已有匹配的 CI，应检查；不要等待、触发或重新运行 CI。 检查已执行的步骤和注释，并将每项未成功的远程 CI 结果归类为代码或测试失败、基础设施或账户故障、已取消或被取代的运行，或证据不可用。如果由于基础设施原因未运行任何步骤，则运行最接近的安全本地等效检查，并报告远程 CI 证据不可用，绝不能报告为通过。如果本地等效检查满足必需的验证要求，则仅由基础设施导致的 CI 故障不会阻止结果为 clean。
9. 记录本轮的 Review Outcome。没有 Verified Findings 的 Full 轮次结果为 clean。完成修复的轮次结果为 fixed，并根据 Impacted Review Requests 选择下一轮：若集合包含完整的 Review Policy，则选择 Full；否则选择 Delta。没有 Verified Findings 的 Delta 轮次，如果满足上述窄范围修复的收尾条件，则结果为 clean；否则结果为 ready-for-full-review，并开始 Full 轮次。incomplete 会终止本次运行，不再进行其他编辑。 只有在每个 fixed 轮次都更改目标并通过修复门槛时，才继续。没有新证据却重复出现已验证发现，或任何轮次无法做出有依据的修复，都会使结果变为 incomplete，而不是继续循环。

返回结果

在任一输出形式中，都要包含每个请求所选的模式和仅报告的预检结果，以便交接内容说明接受了哪些标准和边界。

选择一种输出形式：

• 对于单轮 clean 运行，只返回精简的下游交接内容。包含策略来源、精确的审查请求数量、范围契约、轮次范围、审查者分配和池大小、目标和基准引用、最终 HEAD 和差异哈希、检查和 CI 分类，以及一次性的终止结果。不要另行叙述工作流，也不要包含空类别；省略表示该类别不存在，而不是显示为 None。
• 其他情况则报告策略来源、已解析的审查请求、范围契约、每轮的范围和审查者分配、非空的声明账本状态、已验证发现、被驳回的声明及补救措施、未经验证的声明及证据缺口、已被取代的补救措施、自动化缺口、修复、验证门槛和修复门槛、检查和 CI 分类，以及审查结果。使用精简表格或列表，省略空类别，并且对重复的 clean 来源只说明一次。最后附上精简的下游交接内容，其中包含目标和基准引用、最终 HEAD 和差异哈希、终止结果、非空的修复和声明摘要、检查和 CI 分类、自动化缺口以及审查者分配。

对于每个已修复轮次，明确指出综合门槛、修复门槛和 fixed 结果。每个已修复声明都要在账本中单独占一行，并列出其审查者来源和完整状态变化过程。预检结果为 incomplete 时，需说明目标、仓库历史和 Forge 状态均保持不变。对于每项复合审查技能，来源信息都要列出每个必需角色、其分配的 Agent，以及编排者的综合结果。记录峰值池大小和任何审查者复用情况。说明精确的审查请求数量，并解释每个 Delta 子集，同时确认权威审查策略保持不变。

最后只给出一个终止结果。下游交接内容是后续历史或发布技能所需的本次运行唯一输入。

• clean：完整当前差异的完整轮次没有已验证发现，或后续的 clean Delta 轮次满足范围有限修复的闭环条件。
• incomplete：无法安全地完成所请求的策略。

所有修复均保持未提交状态。不要提交、变基、评论或推送。仓库历史和发布工作流由调用方负责。