用途：对代码变更做对抗式、多模型审查，适用于“interrogate”“adversarial review”“stress test this code”“find blind spots”等场景。
主要能力：为每个已配置模型启动一名审查者，所有审查者收到相同提示与评分标准，对抗信号来自模型多样性而非预设角色。最终产出综合裁决，不自动应用改动。
使用方式：先阅读 T3 execution 以了解全局配置、容量选择与传输约束。确定审查范围：用户指定文件或 diff 时直接使用；在功能分支上运行 git diff main...HEAD（或合适的基础分支）获取完整变更集；若消息涉及近期工作则收集相关文件。打包 diff 或文件内容及必要上下文。启动前明确陈述意图，来源包括用户消息、提交信息、PR 描述或代码本身，写一段清晰文字，不确定时先询问用户。随后在单轮中启动所有审查者，每个审查者一个 delegate_task，mode 为 "async"，使用 pstack-models.md 中的 interrogate reviewers 行，按条目数标记 Reviewer A、B、C 等，并通过 orchestrator_capabilities 解析各条目的 provider 与 model；该行缺失时使用该角色的内置默认值。每个审查者的简报自包含，仅含简报不含你的上下文，且为只读：只检查，不写入，不执行改变状态的 git 命令。auto 或 inherit-parent 条目省略 model，使其运行在父模型上。容量选择的审查者不可用时，通过 execution 参考解析其他合适账户或模型；固定或用户选定模型失败时报告并询问后再替换。读取 references/reviewer-prompt.md 并填入模板：陈述的意图、diff 或文件内容、references/rubric.md 的评分标准、references/code-quality-review.md 的代码质量视角。同一份模板发给所有审查者。用 task_status 收集结果，留意停滞的审查者。全部返回或停滞后再综合：两个及以上返回时，取消停滞者且不补员，并在 Reviewers 中列为 stalled；少于两个时补员。
综合与裁决：解析所有发现，识别共识（2 个及以上模型独立提出信号最强）、单独模型发现、去重并记录提出模型、记录分歧。作为主导审查者，按 act on、consider、noted、dismissed 分类每条发现，并注明提出模型、类别与一行理由。输出结构包括 Intent、Reviewers、Act On、Consider、Noted、Dismissed、Agreement Map。
限制：不自动应用修改；审查者只读；依赖配置与参考文件；具体模型、容量与失败处理细节以资料所述为准，其他信息暂未提供。