用途：对代码改动进行对抗式评审，适用于“interrogate”“对抗式评审”“多模型评审”“挑战这段代码”“压力测试”“找盲点”等场景。核心思路是让多个模型各自独立审查，靠模型多样性而非设定人格来产生对抗信号，交付物是一份综合裁决，不自动应用更改。
主要流程：1）界定范围，根据用户指定的文件或 diff 确定评审对象；若在功能分支上可运行 git diff main...HEAD 获取完整改动，并把 diff 或文件内容与必要的上下文打包。2）明确意图，在启动审查者之前用一段清晰文字说明意图，来源包括用户消息、提交信息、PR 描述和代码；若不确定应先询问用户。3）启动审查者，用 Task 工具在一条消息中按 interrogate reviewers 角色逐条启动，标注 Reviewer A、B 等，默认模型依次为 fable、opus、sonnet，设置 subagent_type: general-purpose 与 readonly: true；若某条被拒绝，可用 pstack-harness 技能处理，必要时另开 PR 更新默认模型表与 pstack-models.md，不因该问题阻塞评审。每位审查者填充统一模板，包含意图、diff 或文件内容、rubric 与代码质量视角。4）合成，记录各审查者所用模型，同一模型的多条只算一名；合并重复发现并标注提出者，两个或以上模型独立提出的发现信号最强，单独模型的发现照读但权重相应降低，并记录分歧。5）主导判断，由资深工程师主导而非中立汇总，将每条发现归入 Act on、Consider、Noted、Dismissed 四类并说明理由。
输出格式包含意图、审查者（标签、模型名、发现数）、Act On、Consider、Noted、Dismissed 以及一致性图，说明模型在何处一致与分歧及其含义。限制：不自动应用修改；默认模型仅为表格所列；具体平台与安装方式资料未提供。