Open Code Review 技能
让 AI 代理以后台方式运行 OpenCodeReview 代码审查，按严重程度分级发现并安全应用修复。
技能仅调用一个已知的 npm CLI（@alibaba-group/open-code-review），以用户请求为触发，修复前要求确认（仅 review 时不改代码），运行于用户本地环境，权限面可控；但第三方 LLM 审查服务会把代码 diff 发送到外部 LLM 提供商，数据流披露不完整（telemetry 存在但未说明），无回滚机制说明，发布者身份未经验证。扣分点：外部数据流向与遥测披露、无恢复/回滚路径。
指令自洽、路径清晰（预览→后台运行→轮询→分类→修复），对已知的看门狗/缓冲问题给出具体规避方案和会话日志排查路径，失败反馈较好；但全部依赖 ocr CLI 可安装且 LLM provider 已配置，无测试覆盖证据，错误场景（安装失败、provider 未配置）处理薄。静态审查上限为 10，扣分点：依赖可用性未验证、异常输入处理不足。
触发条件明确（被要求审查代码变更时），场景清晰（agent 辅助代码审查），前置条件与不适用情形（未安装 ocr）有说明；但未声明能力边界（如仅支持 git diff 审查）、无中文环境说明，ocr 与其 LLM 后端依赖海外服务，对中国大陆用户可达性存疑。扣分点：边界声明不完整、海外服务依赖未提示。
结构分层良好（前置条件→步骤→注意事项），引用仓库内 review-configs/ocr/ 作为配置来源，许可证为 Unlicense（公共领域），仓库 README 有版本跟踪 issue；但技能本身无版本号/changelog，维护责任不明确，发布者未验证。扣分点：版本治理缺失、维护者承诺不明。
编码了一个真实、非平凡的工作流（后台运行规避看门狗、严重度分类、按需修复），对 agent 比手动摸索有明确边际价值；但输出质量完全取决于 ocr 后端，且无代表性输出的可用性证据。静态上限 7，扣分点：结果可用性无验证、替代方案（直接跑 ocr 或 CodeRabbit）对比未充分论证。
关键命令和配置路径可审计、与仓库内 review-configs/ocr/ 交叉对应，README 引用了一项已发布的 AI 审查研究作为间接佐证；但无测试、无 CI 覆盖该技能路径，无第三方执行证据。静态上限 5，扣分点：核心行为无可复现的执行证据。
- 代码 diff 会被发送到 ocr CLI 配置的外部 LLM 提供商，敏感/专有代码使用者应先审查遥测与数据流设置。
- 依赖 @alibaba-group/open-code-review npm 包及可用 LLM 提供商，未验证安装路径；中国大陆网络环境下该 CLI 及其 LLM 后端可能不可达。
- 技能无版本号和变更记录，行为可能随仓库更新而变化；发布者身份未经验证。
- 全部结论基于静态源码阅读，未实际执行任何命令。
这个 Skill 能做什么，适合哪些场景？
open-code-review 是 vibetools 仓库中的一个代理技能，指示代理如何用 Alibaba 的 ocr CLI 审查代码变更。它的核心价值在于解决两个实际问题：ocr 在 --audience agent 模式下会缓冲全部输出直至完成，前台运行会被 shell 的约 2 分钟看门狗杀掉；以及 ocr 默认排除测试文件。技能要求先预览审查范围，再用 nohup 分离运行并设置至少 20 分钟超时，轮询完成后把发现分为 High/Medium/Low 三级报告，仅在用户要求时才应用 High 和 Medium 修复。仓库整体采用 Unlicense（公有领域），仓库内还附带 senior-engineer 评审规则配置。
1) 检查前置条件：安装 ocr CLI（npm i -g @alibaba-group/open-code-review）并用 ocr llm test 验证 LLM 提供方；可选地把 review-configs/ocr/rule. 复制到 ~/.opencodereview/rule. 以纳入测试文件和应用评审规则。2) 用 ocr review --preview --from <base> --to <head> 即时预览将被审查的文件。3) 用 nohup 在后台分离启动 ocr review --audience agent --timeout 20，输出重定向到 /tmp/ocr_review.log，记录 PID 后以约 90 秒间隔轮询。4) 审查完成后读取日志（或 --format 获取结构化发现），将发现分为 High（明确 bug、安全问题）、Medium（可维护性、边界情况）、Low（疑似误报、风格）。5) 若用户要求"审查并修复"，直接应用安全的 High/Medium 修复；若只要求"审查"，修改前先询问。超时约 25 分钟无输出则视为挂起，可在 ~/.opencodereview/sessions/ 的 .l 日志中找回发现。
- 在 git 工作流中让代理审查一个 feature 分支相对 base 的 diff（--from/--to）并汇总分级意见
- 团队要求测试文件也必须被审查时，用全局 rule. 重新纳入 *.test.* / __tests__ 文件
- 代理需要自主完成"审查并修复"循环，且只应用明确、安全的 High/Medium 修复
- CI 之外做整目录的全文件扫描（ocr scan --path），同样遵循全局规则
- 审查运行意外中断（stdout 丢失）后，从会话日志恢复发现结果
这个 Skill 有哪些优点和局限？
- 明确规避了两个真实陷阱：前台运行被约 2 分钟看门狗杀掉（缓冲输出全丢），以及 ocr 默认排除测试文件
- 强制 20 分钟超时下限并给出 ~25 分钟总耐心上限和会话日志恢复路径，失败模式处理具体
- 发现按 High/Medium/Low 分级，且尊重用户意图：只审查时不擅自改动代码
- 规则优先级清晰：--rule > 项目级 .opencodereview > 全局 rule. > 内置
- 来自包含已发表 OCR 研究的仓库，review-configs 提供配套的评审 rubric
- 强依赖 Alibaba OpenCodeReview CLI 及其配置好的 LLM 提供方，更换审查引擎需要重写
- 审查流程慢：单次至少以 20 分钟超时运行，总计可能等待约 25 分钟
- 仓库未提供针对该技能的独立测试套件；Topics 为空，README 说明部分区域仍在建设（如 #15 跟踪）
- Unlicense 意味着完全无担保
- 仅覆盖 ocr 工作流；CodeRabbit 流程属于同仓库的另一个技能，不包含在此
如何安装这个 Skill？
1) 安装整个技能集合：skills/install.sh 安装到平台用户技能目录，或 skills/install.sh /path/to/project 安装到指定项目。2) 安装 ocr CLI：npm i -g @alibaba-group/open-code-review。3) 用 ocr llm test 验证 LLM 提供方已配置。4) 推荐：mkdir -p ~/.opencodereview && cp review-configs/ocr/rule. ~/.opencodereview/rule. 复制全局评审规则。SKILL.md 未单独说明各代理平台的具体发现路径。
如何使用这个 Skill？
对代理发出触发提示，例如："请审查从 main 到 HEAD 的代码变更"。技能会先执行 ocr review --preview --from <base> --to <head> 预览范围，然后 nohup ocr review --audience agent --timeout 20 --from <base> --to <head> > /tmp/ocr_review.log 2>&1 & 后台运行并轮询，最后给出 High/Medium/Low 分级报告。如需修复，在提示中明确写"review and fix"。要结构化输出可加 --format 。
这个 Skill 与同类方案有什么区别？
同仓库的 skills/coderabbit-review/ 是直接替代方案：它运行 CodeRabbit CLI 而非 ocr，支持自主实现-审查-修复循环。仓库的 review-configs/ 同时提供两者的配置，且其研究结论是两者互补而非孰优孰劣——匹配审查发现了不同的已验证缺陷。