先定义审查任务，不要先看工具名称
代码审查包含多个不同判断：理解改动、识别安全敏感路径、验证行为，或收集可重复证据。把这些全部塞给一个 Skill，往往只会得到噪声和模糊的责任边界。
SkillSignal 建议使用精简的角色组合：核心 Skill 解释差异及影响；保护角色执行有明确局限的定向检查；证据角色运行最小相关测试或浏览器流程。最终批准仍由理解仓库和发布背景的人负责。
四个实用 Skill，以及各自边界
当 PR 需要以变更为中心的安全推理时，differential-review 是合适起点。它关注差异与周边影响范围，但不能证明运行安全，也不能替代架构知识。
Semgrep 适合快速规则检查和 SARIF 证据；CodeQL 在语言与数据库设置受支持时，可进行更深入的跨过程数据流分析。两者都可能漏掉模型范围外的问题，也都会产生需要人工分诊的结果。
webapp-testing 为本地 Web 应用增加浏览器证据。它能验证明确流程，但截图与通过步骤不能覆盖所有状态、浏览器、无障碍路径或生产依赖。
保持可审计的四步审查组合
第一步明确目标分支、预期行为、敏感文件与审查决策；第二步先读差异，再决定是否运行自动化，避免无边界扫描；第三步运行最小相关检查并保留命令、范围与输出；第四步对照验收标准记录证据和未解决风险，不把工具结果自动升级为批准。
- 核心审查说明行为变化和可能的影响范围。
- 每项自动检查都注明文件、规则、语言支持与排除项。
- 行为证据覆盖真实改动流程，而不是无关的冒烟测试。
- 由明确的人工审查者负责最终判断和例外。
比原生标签更重要的是可重复边界
同一个 Skill 可能对某个 Agent 提供原生路径，对另一个 Agent 只提供可移植 SKILL.md。可移植很有价值，但不能证明测试程度、工具访问或权限行为完全相同。安装前要检查所选 Agent 的路径与依赖。
审查场景中，更重要的问题是：另一位审查者能否看到同一来源提交、运行同一项有边界的检查，并理解结果为何重要？如果不能，增加更多 Skills 往往只会增加歧义。
选择检查清单
选择能回答当前审查问题的最小组合。只有当新 Skill 拥有独立职责，并能产生真正会被使用的证据时，才增加它。
- PR 审查必须支持哪个具体决策？
- 每个 Skill 可以访问哪些文件、命令、网络与外部服务？
- 上游来源是否固定？是否做过独立运行测试？
- 什么结果会触发停止、升级或拒绝？