tianemon/easymint/code-review

代码审查

检查改动是否实现需求、逻辑自洽、影响面完整，或指定模块是否兑现其功能契约。默认只读，给出结论和建议；已有明确修复授权时执行该范围，不重复询问，也不自动扩展到整理工作树、提交或发布。

适用于不同项目与技术栈。按项目实际使用的语言、运行库、构建与验证能力选择证据；界面、并发、持久化和模型工具等检查只在相关模块存在时适用，不预设特定产品、SDK、框架、命令或目录结构。

先确认范围和基线

用户指定的提交、区间、工作树差异或模块优先。没有临时指定时，默认检查当前分支未推送的提交。项目已明确发布远端和分支时遵循该约定，可显式使用已核实的引用；否则再核对分支与远端/跟踪关系。记录实际比较的基线及终点，不将某项目的远端约定推广到其他项目，也不认为本地远端引用一定最新。

同时区分提交、暂存、未提交和未跟踪内容，不把其他在制改动算成本次交付。范围有影响结论的歧义时澄清；可确定的部分继续，不默认扫全仓。无 Git 项目按指定源码范围检查，不要求初始化仓库。

按需加载方法

• 变更审查、修复复核、断言有效性：读取 references/change-review.md。重点是需求对账、逻辑/安全、列举清单、旧数据和变更归属。
• 模块、页面或子系统审查：读取 references/module-audit.md。重点是实际入口、声明/实现/消费、关键字段与用户结果的闭环。
• 提示词、项目规则、技能或工具指令发生行为变化：补读 references/prompt-review.md。检查语义、作用域、优先级和实际组装，不只找重复词；普通界面文案不因此加载本专项。
• 组合任务：沿用户目标补充另一份参考，避免把模块审查扩大为全仓重构。

本技能自带所需参考，可独立使用。若本次已有其他审查或健康检查结果，复用已取得的证据，只补未覆盖的相关风险，不依赖额外技能存在，也不重复执行整套审查。

结论的最低证据

把用户要求、验收条件和说明中的声称对应到实际路径及结果。每条问题给出触发条件、位置/输出证据、预期与实际差异、影响和建议；区分已复现、源码可确定和未验证。部分完成时明确差额。

复核结论所依赖的判断前提，而不只核对执行是否符合原结论。先自行查证、筛选和判定，只将确实缺失的用户意图或方向取舍交还用户；发现是否成立与修复是否获授权分别判断。

检查按名称枚举的注册、校验、保护和显示映射；接口变化追踪声明、实现、调用方及已有数据。第三方行为按实际版本核对；合并 diff 不用于单独证明历史引入者。

修复复核关注守护能否拒绝已知错误实现。反向探针在隔离环境中执行，确认失败原因属于目标行为；不能用改坏用户工作树、通用失败或恒真反例证明测试有效。

对 UI，尺寸等可量化结论用计算值，视觉与交互判断结合实际渲染；无渲染条件时标注推断，不把截图作为每次审查的固定要求。

环境提供 web-ui-metrics-verify 且本次涉及 Web UI 几何或视觉量测时，优先复用其方法；不可用时使用项目已有的渲染/浏览器验证工具，不要求安装该技能。

修改和验证边界

只读审查不修改源代码、暂存区或历史。已授权修复时保留其他在制改动；发现同文件有其他修改先看实际 hunk，不机械地全部停工，也不移动、覆盖或一起提交它们。

运行与本次风险相关的项目检查，再完成约定的验证。区分源码、环境、其他改动和平台原因；退出成功或测试数量不代表结论已被证实。只有新变化、失败或未解疑点才扩大或重复验证。

需要 Git 修复、提交拆分或历史整理时，按该动作的实际授权处理；stash、整文件还原和重写提交不作为默认审查步骤。审查技巧不能替代对用户工作成果的保护。

输出

每次都以一行可机读的摘要收尾。字段顺序与分隔符固定，不要改写（跨会话统计要能直接抽）：

审查摘要：范围 <基线..终点>（<N> 文件）｜P0 <a>｜P1 <b>｜P2 <c>｜未覆盖 <清单或"无">

摘要里的计数必须能从正文逐条数出来，不写正文里没有的数字。未覆盖 填实际没查的面（渲染、真实设备、并发压测、旧数据迁移等），真没有才写"无"。

范围 用一个不含空格的标识，三选一：<基线>..<终点>（如 9653e940..753b8493）、工作树、单个 commit。不要写成「工作树 vs HEAD」这类短语——空格会让这一行无法按固定格式解析。

没有发现也输出：0 发现是合法结论，用同一行摘要（三个计数全 0）加两三行「检查过什么」。不为凑内容而提问题，也不把「没发现问题」说成「没有问题」。缺少这一行时，读的人无法区分「审干净了」和「没审」。

按规模分档写正文，但摘要行和 未覆盖 在任何档位都不能省：

硬例外——命中即走完整，不看行数：权限 / 沙箱 / 凭据 / 加密、数据落盘格式或迁移、网络外发、进程生命周期、并发与竞态；改变授权、指令优先级、自动写入或确认边界的规则改动；以及会改变「某个读接口是否顺带触发写操作」这类结构性约定的改动。拿不准按完整走。

有问题时先给有证据且可行动的发现，再简述范围、验证和限制。没有发现时明确检查过什么、未覆盖什么，不宣称软件没有缺陷。

沿用项目严重度标准；没有标准时采用 references/change-review.md 中的默认 P0/P1/P2 分级表，并说明影响及触发条件。分级定义只维护在该参考文件中。

风格偏好和无证据的未来风险与缺陷分开。只读审查写建议，不写“已修复”；修复后报告具体变化与验证结果。

复盘记录

审查结束后（含 0 发现），在用户家目录留一份简短记录，用于事后评估这个 skill 本身有没有用、缺什么：

~/.skill-runs/code-review/<YYYY-MM-DD>T<HHmm>-<范围标识>.md

放在家目录而不是项目里：不属于任何仓库、不受 git 追踪、不同工具（不同 agent）写到同一处才能汇总。不要写进项目目录，也不要为此改项目的 .gitignore。

记录只写结论，不复制代码、不贴 diff、不列文件路径清单：

---
skill: code-review
when: <ISO 时间>
scope: <与摘要行相同的范围标识>
files: <N>
tier: <light|full>
p0: <a>
p1: <b>
p2: <c>
uncovered: [<未覆盖的面>]
verified: <通过实际执行或受控复现确认的发现数>
---
## 发现
-P1 <一句话结论>
## 未覆盖
-<为什么没查：缺环境 / 超出授权 / 归属别的模块>
## 复盘备注
-<哪条靠复现确认、哪条只是源码推断；本轮哪里最费时间>

verified 只记录以实际执行或受控复现确认的发现数量，不是可信发现总数或质量分；源码已能确定的问题同样是有效证据，不为增加该数字重复实测。它不代表“没有技能就发现不了”的数量。

后续复盘抽样核对：发现是否误报，证据是否支持影响，后续是否暴露重要遗漏，修复是否必要。用户采纳、严重度分布和复现数量都不能单独证明技能提升了审查效果；没有对照时不声称相对提升。区分报告缺失、完成且零发现与审查中断。

复盘记录只承担本次审查留痕，不强制提炼长期经验或继续调用其他工具。保留当前字段与摘要格式，不为统计增加流程。

写不了文件（权限、无家目录、环境限制）时跳过并说一句，不要中断审查，也不要编造记录。