SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场open-code-review-loop

open-code-review-loop

编程与开发

查看项目

更新于 10-30 16:20

技能介绍

用途

open-code-review-loop 用于在 Git 工作区上执行一个有轮次上限的 OCR 委派审查循环：审查方（Reviewer）提出发现，修复方（Fixer）修改源码，主机重建证据并复审，直到得到经校验的 NO_FINDINGS 或 CLEAN，或明确返回 HUMAN_GATE、MISSING_DEPENDENCIES、UNVERIFIED 等终止状态。

仅当用户同时要求“修复已核实发现”和“独立复审直至通过”时才使用本技能。仅请求一次 ocr delegate / open-code-review-delegate 调用不足以触发本技能，应改用 open-code-review-delegate。一次性或只读审查、非 Git 文件、commit/push/deploy 及破坏性操作均被排除。协议包、.review-handoff、review-loop run 或 Grok 咨询属于 agentic-review-handoff；命名路径加架构扫描修复属于 architecture-hardening-loop。

主要能力与约定

  • ocr delegate 不依赖 LLM：它只负责选择文件并解析规则；只有经校验、覆盖完整的审查结果才能给出 NO_FINDINGS，OCR 从不判定代码干净。
  • 审查方负责发现和干净结论，修复方负责源码修改与验证，可见主机负责 OCR 证据、schema 校验、分流、轮次记账和最终结果。
  • 默认轮次预算 3 轮（上限，不等于成功许可），每次审查或修复调用限时 10 分钟。
  • 仓库为当前 Git 根目录，不推断更大范围；目标默认是工作区变更，也支持 --from/--to 与 --commit。
  • 审查方默认未指定时询问一次，并推荐可见主机之外、已安装且能力安全的产品；同一产品担任两个角色时必须是不同会话。
  • 审查方以最强只读控制加 dontAsk 调用；调用前后冻结并重算受审 Git 身份，审查期间发生改动返回 UNVERIFIED: REVIEWER_MUTATED_SUBJECT。

使用方式

按 Fast Path 顺序执行：

  1. 确认是 Git 仓库，否则停止。
  2. which ocr：缺失则返回 MISSING_DEPENDENCIES，不得擅自安装 OCR，也不得打开适配契约或调用审查方。
  3. 解析审查方/修复方产品 ID，只打开 adapter-contracts.md 中对应产品段落。
  4. 仅在 Phase 2 打开 review-contract.md 与 review-schema.json；仅在 Phase 4 对独立核实的修复行打开 fix-contract.md 与 fix-schema.json。
  5. 历史 --commit / --from/--to 目标在任何修复前返回 HUMAN_GATE，不加载修复契约。

阶段流程：

  • Phase 1 建证据：用 mktemp -d 在仓库外创建 ROUND_DIR，运行 python3 <skill-dir>/scripts/build_review_bundle.py（支持 --repo、--output、--from-ref/--to-ref、--commit、--exclude、--allow-excluded-reason、--rule、--background 或 --background-file）。--exclude 可重复，选择每轮保持；OCR 排除的 .md/.mdx 转为强制补充审查范围；零可审文件、零补充文件、零未接受排除 → CLEAN（0/0 覆盖），存在未接受排除 → UNVERIFIED: INCOMPLETE_COVERAGE。
  • Phase 2 调用审查方：提供冻结契约、背景、完整 bundle.json（含 evidence_id）、只读上下文、非变更检查及 JSON 契约。审查集合是 reviewable_files 与 supplemental_reviewable_files 的并集，每个（路径、状态）恰好出现一次。用 extract_product_output.py 提取结构化结果，再用 validate_round.py 校验；格式错误可同会话纠正一次，仍无效 → UNVERIFIED。
  • Phase 3 检测证据漂移：用相同目标与排除重建 bundle 并比较 evidence_id；不同则丢弃结论、记录漂移、重审新 bundle，绝不跨快照沿用发现或 NO_FINDINGS。
  • Phase 4 分流与修复：逐条独立打开路径核实，分为 Fix、Reject、Human decision；只把已核实的 Fix 行交给修复方，并附目标路径、修复要求、验收检查、当前 evidence ID 和写边界。修复方只做最小一致改动，不 commit、push、merge、rebase、deploy 或越界写入；主机重算 Git 状态与 diff、拒绝越界写入并运行检查，不信任修复方声称的 FIXED 或测试结果。任何源码或测试改动都会使先前证据、校验、测试和结论失效，回到 Phase 1。
  • Phase 5 复审与停止：产品支持会话恢复时复用审查方，否则以发现台账和新 bundle 启动新的只读会话；修复方从不给出终局结论。

适用场景

适用于已在本地安装 ocr、具备 Git 工作区，并希望将“审查—修复—复审”闭环交给独立只读产品把关的开发者。对历史提交范围、外部修复方、破坏性或安全敏感选择，技能会直接进入 HUMAN_GATE 或失败关闭。

限制

  • 需 Git 仓库和已安装的 ocr；缺失时停止，不自动安装。
  • 审查方须支持只读、结构化输出与非交互运行；不满足则 HUMAN_GATE，自动选择时尝试下一个已安装能力安全产品。
  • 外部修复方需要用户授权的隔离检出，缺失则 HUMAN_GATE，且不自动创建 worktree。
  • 轮次预算耗尽绝不是 CLEAN，需报告剩余台账并询问是否追加轮次。
  • 零文件 CLEAN 路径不产生审查响应；其他状态必须点名确切停止点，不得声称 OCR 或 AI 已批准当前代码。

输出约定

结果以“OCR Review Loop Result”呈现，包含 Result（CLEAN | HUMAN_GATE | MISSING_DEPENDENCIES | UNVERIFIED）、仓库/目标、范围/排除、审查方/修复方、已用轮次/预算、最终 evidence id、覆盖率、已修复/已拒绝/未决发现、验证、会话/恢复，以及“Git 和外部操作：无”。

暂未提供

资料未提供价格、收费、平台兼容性细节或安装步骤。