kscz0000 审查集群
何时使用
当需要对当前 git diff 或指定文件范围进行并行只读多智能体审查，以发现行为回归、安全或隐私风险、性能或可靠性问题，以及契约或测试覆盖缺口时使用此技能。当用户要求审查集群、并行审查、diff 审查时使用。
用四个只读子智能体并行审查一个 diff，然后由主智能体过滤、排序并仅汇总真正重要的问题。此技能仅用于审查：子智能体不编辑文件，主智能体也不在此工作流中实施修复。
步骤 1：确定范围和意图
优先按以下顺序确定范围：
- 用户明确指定的文件或路径
- 当前 git 变更
- 用户明确请求的分支、提交或 PR diff
- 最近修改的已跟踪文件，仅在用户要求审查且没有更明确的 diff 时使用
如果没有明确的审查范围，停下来简要说明。
使用 git 变更时，选择最小且正确的 diff 命令：
- 未暂存的工作：
git diff - 已暂存的工作：
git diff --cached - 混合暂存和未暂存的工作：两者都审查
- 明确的分支或提交比较：使用用户请求的精确命令
在启动审查者之前，阅读最近的本地指令和涉及区域的任何相关项目文档，例如：
AGENTS.md- 仓库工作流文档
- 涉及模块的架构或契约文档
为审查者构建简短的意图包：
- 预期改变的行为是什么
- 应保持不变的行为是什么
- 任何已声明或推断的约束，例如兼容性、发布、安全或迁移期望
如果用户没有清楚说明意图，从 diff 推断并说明推断可能不完整。
步骤 2：并行启动四个只读审查者
当范围足够大、并行审查有帮助时，启动四个子智能体。对于极小的 diff 或非常小的单个文件，本地审查即可。
对每个子智能体：
- 给出相同的范围和相同的意图包
- 声明子智能体为只读
- 不允许子智能体编辑文件、运行
apply_patch、暂存变更、提交或执行任何其他状态变更操作 - 仅要求简洁的发现
- 要求提供：文件和行号或符号、问题、为何重要、建议后续操作和置信度
- 告知子智能体避免吹毛求疵、风格偏好和没有具体影响的推测性担忧
- 告知子智能体仅将发现发送回主智能体
使用以下四个审查角色。
子智能体 1：意图与回归审查
审查 diff 是否符合预期行为变更，且未引入额外的行为偏移。
检查：
- 超出声明范围的意外行为变更
- 损坏的边界情况或回退路径
- 调用方与被调用方之间的契约偏移
- 应一起变更但缺少更新的相邻流程
此子智能体为只读。不得编辑文件、应用补丁或进行任何其他工作区变更。
推荐子智能体角色：reviewer
子智能体 2：安全与隐私审查
审查 diff 中的安全回归、隐私风险和信任边界错误。
检查：
- 缺失或削弱的认证或授权检查
- 不安全的输入处理、注入风险或验证缺口
- 密钥、令牌或敏感数据暴露
- 危险的默认值、权限扩大或对未验证数据的信任
此子智能体为只读。不得编辑文件、应用补丁或进行任何其他工作区变更。
推荐子智能体角色：reviewer
子智能体 3：性能与可靠性审查
审查 diff 中的新增成本、脆弱性或运维风险。
检查：
- 重复工作、冗余 I/O 或不必要的重复计算
- 在启动、渲染、请求或其他热路径上增加的工作
- 泄漏、缺失清理、重试风暴或订阅偏移
- 使变更变得脆弱的排序、竞态或故障处理问题
此子智能体为只读。不得编辑文件、应用补丁或进行任何其他工作区变更。
推荐子智能体角色：reviewer
子智能体 4：契约与覆盖审查
审查 diff 中的兼容性缺口和缺失的安全网。
检查：
- API、schema、类型、配置或 feature-flag 不匹配
- 迁移或向后兼容性影响
- 对变更行为缺失或薄弱的测试
- 缺失的日志、指标、断言或错误路径，使回归更难检测
此子智能体为只读。不得编辑文件、应用补丁或进行任何其他工作区变更。
推荐子智能体角色：reviewer
仅报告对正确性、安全性、隐私、可靠性、兼容性或对变更的信心有实质性影响的问题。宁可漏掉一个小问题，也不要用低价值噪音淹没用户。
步骤 3：汇总和过滤发现
主智能体负责综合。将子智能体输出视为原始审查输入，而非最终输出。
合并所有四个审查者的发现并进行严格过滤：
- 去除重复项
- 去除薄弱或推测性的断言
- 去除与声明意图冲突的问题
- 去除次要的风格或可读性意见，除非它们掩盖了真正的 bug 或维护风险
将存活的发现规范化为此格式：
- 文件和行号或最近符号
- 类别：regression、security、reliability 或 contracts
- 严重程度：high、medium 或 low
- 为何重要
- 建议的修复或后续操作
- 置信度：high、medium 或 low
如果审查者可能正确但意图不明确，将其转为开放问题而非发现。
步骤 4：排序输出
按以下顺序呈现发现：
- 高严重程度、高置信度的问题
- 可能值得在合并前修复的中严重程度问题
- 可以等待的较低严重程度问题或后续事项
保持审查简洁。发现应当可操作且有证据支撑。
如果没有实质性问题，直接说明，而非制造反馈。
步骤 5：推荐明确的前进路径
在发现之后，给用户简短的前进路径：
- 合并前必须修复的
- 如果时间允许应改进的
- 可以安全搁置的
适当时将前进路径分组为：
fix nowfix soonoptional follow-up
不要在此技能中实施修复。输出是只读审查加优先级推荐。
局限性
- 仅当任务明确匹配其上游来源和本地项目上下文时使用此技能。
- 在应用变更之前，验证命令、生成的代码、依赖项、凭证和外部服务行为。
- 不要将示例替代为环境特定的测试、安全审查或用户对破坏性或高成本操作的批准。