| name | upaseo-reviewer |
| description | 本地代码自审与质量监督技能。融合 open-code-review (ocr) 大代码审查引擎与 Agent 模拟审计分层,在提交 PR 前对当前改动进行全面的安全性、稳健性、风格契合度审查,发现隐藏的 bug 和坏味道。 |
Upaseo Reviewer (本地代码自审技能)
在代码推送 (git push) 或提 PR 之前,必须强制加载并调用此技能,从一个挑剔的、极其专业的外部资深代码审计师角度,对当前 diff 进行全方位审查。
Scope Boundary
- 默认只审查当前
git diff 及其直接影响面;不得把历史遗留问题扩展成无关重构。
- 发现的问题若来自本次 diff,必须本地闭环修复;若来自旧代码且未被本次改动放大,只在报告中标注为"既有风险",不顺手修改。
- 当用户直接调用本技能做只读 review 时,先输出 findings;只有用户明确要求修复,才进入本地闭环修改。
审查黄金法则
-
绝对客观与严格:
- 绝不因为"代码是自己写的"而手软。必须像审查陌生人的提交一样对待当前的 diff。
- 重点关注:边缘用例是否处理、类型定义是否完备、是否存在资源泄漏、异步调用是否未 catch 错误。
-
零容忍代码坏味道 (Zero Smell):
- 是否存在硬编码的魔术字、魔术数字、本地的硬编码绝对路径?
- 是否存在潜在的安全性漏洞(如 SQL 注入风险、日志中打印了敏感密码/Token、不安全的动态执行)?
-
与项目生态的和谐度 (Harmony):
- 变更是否引入了重复的逻辑?是否可以使用项目已有的 utils/helpers 替代?
前置避障读取
执行标准避障前置读取,见 upaseo/references/learnings-precheck.md。本技能相关 category 为 command_error|tool_misuse。提炼的规则作为审查清单的补充——若 diff 中的改动可能触犯某条历史教训,必须在审计报告中专项标注。
审查引擎分层 (Review Engine Tiers)
本技能采用分层审查引擎,强度挂靠 using-upaseo 执行模式(微改跳过 / quick 可选 / full 默认 Tier 1):
Tier 1:open-code-review (ocr) —— 完整模式默认
完整仪式模式默认调用 ocr CLI 进行大代码审查。ocr 是可选外部依赖(open-code-review,ocr 命令),不可用时降级到 Tier 2。
ocr 可用性判定(执行前自检):
command -v ocr >/dev/null 2>&1 && ocr llm test >/dev/null 2>&1
两项都通过 = Tier 1 可用;任一失败 = 降级 Tier 2 并在报告中标注"ocr 不可用(未安装/未配 LLM/超时),已降级 Agent 模拟审计"。
Tier 1 调用规程:
ocr review \
--audience agent \
--format text \
--from <迭代基线 base 分支或 SHA> \
--to HEAD \
--background "<本迭代目标一句话,作审查上下文>"
--audience agent:输出 summary-only,便于 Agent 解析而非人类进度条。
--from/--to:限定审查范围为本次迭代 diff;单 commit 场景用 --commit <sha>。
--background:传迭代目标作业务上下文,让 ocr 聚焦本次意图而非泛泛而谈。
- 可选
--rule .opencodereview/rule.json:项目级自定义规则文件(本技能不自动生成,仅文档化位置;缺省走 ocr 内置规则)。
- 可选
--model <model>:覆盖默认 LLM。
ocr findings 处理:
- 把 ocr 输出的 findings 按 §严重度分级 归类。
- blocker 必须本地闭环修复;minor 记录进报告不阻断。
- ocr 若整体超时/报错(非单条 finding),降级 Tier 2 重审。
Tier 2:Agent 模拟审计 —— 降级 / quick / 微改
ocr 不可用、快速模式可选、或微改快速通道(仍需最小自审)时,走 Agent 模拟审计,对照下方 §自审清单 输出"自审报告"。
自审清单 (Agent Audit Checklist, Tier 2)
Agent 在提 PR 之前(Tier 2 路径),必须模拟审计师的角色,对照以下条目输出一份"自审报告":
-
正确性与边缘情况 (Robustness):
- 所有的异步操作(Promises, async/await)是否有妥善的错误处理?
- 传入的参数是否进行了空值/非法边界防御?
- 是否有任何潜在的线程/异步并发冲突、竞态条件 (race condition)?
-
资源与内存控制 (Resources):
- 创建的文件流、定时器、事件监听器、网络连接等,是否在生命周期结束时被 100% 妥善释放/注销?
-
日志与可观测性 (Observability - 核心要求):
- 本次改动是否留下了清晰、有意义的关键事件调试日志?
- 日志输出是否足够支持我们执行"日志优先验证 (Log-Based Verification)"?如果日志过于空泛(例如仅有
error occurred),必须在此阶段补充详细的上下文。
-
审计报告输出 (Report Output):
- 梳理出自审发现的所有问题,按严重度分级处理(见下)。
- 最终在 PR 描述或 Note 中包含一份极简的自审确认单(含 ocr findings 摘要或 Agent 清单结论)。
严重度分级 (Severity Triage)
无论 Tier 1 (ocr) 还是 Tier 2 (Agent),findings 按严重度分级处理:
- blocker(安全/正确性/资源泄漏/数据丢失风险):必须本地 100% 闭环修复,未修复不得提 PR。
- minor(风格/可读性/命名/可选优化):记录进自审报告,不阻断 PR;可登记为
type: debt 到 .paseo/todos.md 留待后续。
这修正了旧版"自审发现任何缺陷必须 100% 闭环修复"的一刀切:blocker 闭环、minor 记录,避免为琐碎风格问题阻塞交付。
自审报告模板
### upaseo-reviewer 自审报告:
- 引擎:Tier 1 (ocr) / Tier 2 (Agent 模拟审计) [ocr 不可用降级]
- ocr findings 摘要:blocker N / minor M(或"未启用 ocr")
- [x] 无未使用变量/冗余导入
- [x] 所有异步处理均有 error catch
- [x] 日志覆盖度充足,已在关键节点输出 events
- [x] 未引入魔术字/敏感数据
- blocker 闭环:全部修复 / 无 blocker
- minor 登记:N 条已记入 .paseo/todos.md (type: debt)