用途
pstack-interrogate 用于对具体的代码差异（diff）或存在争议的设计进行 Pstack 对抗式审查，产出独立的批评意见。其对抗信号来自模型多样性，而不是被分配的角色人设。最终交付物是一份综合裁决，且不会自动应用任何变更。
主要能力
- 确定审查范围：从上下文中识别要审查的内容。如果用户指向特定文件或 diff，则使用该内容；如果在功能分支上，则运行
git diff main...HEAD（或适当的基础分支）获取完整变更集；如果用户消息提及近期工作，则收集相关文件。将 diff 或文件内容与审查者理解代码所需的周边上下文文件打包，包括原始规格说明和相关测试。 - 明确意图：在启动审查者之前，根据用户消息、提交信息、PR 描述（如存在）和代码，用一段清晰的文字陈述意图。如果不确定意图，先询问用户。
- 启动审查者：对于代码 diff，调用
/code-review进行 Standards/Spec 覆盖，除非已有等效证据覆盖当前产物；对抗视角补充其余覆盖并保持其证据独立。使用/pstack-swarm一次性启动所有审查者，每个已配置模型一名，标记为 Reviewer A、B 等，优先采用跨厂商批评。为每位审查者以相同方式填写提示词，包含所述意图、diff 或文件内容、评分标准和代码质量视角。审查者直接检查，不做编辑、不发表评论、不进一步委派。 - 综合：随着结果返回，构建统一图景。解析每位审查者的发现，合并描述同一问题的不同表述，并记录哪些模型提出了每项发现。两个或更多模型独立提出的发现信号最强。单独模型的发现也需阅读，但相应加权。记录分歧：如果一个模型标记了某问题而另一个明确表示相反，这构成裁决的上下文。对照代码验证每个候选发现；一致提高信号但并非证明。将共享的 Standards/Spec 报告保留为独立轴，其发现不会消失在本主导者的排名中。
- 主导判断：作为主导审查者，是务实的资深工程师，而非中立的聚合器。阅读主导判断框架，将每项发现放入四个桶之一，并附上提出该发现的模型和一行理由。
- 行动分类：
- Act on（需处理）：影响正确性、安全性或可维护性的真实问题，会阻止真实 PR 合并。
- Consider（需考虑）：合理，但不确定现在处理是否值得成本，值得用户关注。
- Noted（已记录）：技术上有效但不可操作，依赖上下文、过早优化或当前阶段影响低。
- Dismissed（已驳回）：错误、吹毛求疵或缺少上下文，附简要原因。
使用方式
该技能通过调用 /domain-modeling 来解析并读取调用项目配置的产物。只读调查和审查报告文档漂移而不做编辑；创建或实现则通过该所有者协调已接受的模型变更。
输出格式包含以下部分：
- Intent：第 2 步陈述的意图段落。
- Reviewers：Reviewer [标签]：[模型名称]，[N 项发现]（每位审查者一条）。
- Act On：每项包含描述、提出该发现的模型、为何重要。
- Consider：每项包含描述、提出该发现的模型、权衡。
- Noted：简要列表。
- Dismissed：每项附简要理由。
- Agreement Map：模型在何处一致与分歧，以及该模式说明了什么。
适用场景
适用于对具体代码差异或存在争议的设计进行对抗式审查，尤其适合需要独立批评意见、希望借助多模型多样性发现问题的场景。
限制
- 只做只读调查与审查，报告文档漂移而不做修改。
- 不会自动应用任何变更。
- 审查者直接检查，不做编辑、不发表评论、不进一步委派。
- 对抗信号来自模型多样性，而非预设角色。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。