用途：用于 Pstack 设计理由、回归、历史约束或阈值背后证据的调查。该技能回答“为什么代码是这个样子”，与回答“代码做什么、如何运作”的 /how 技能互补。
主要能力：技能以只读方式调查代码背后的动机与意图。首先理解目标与问题，然后建立代码锚点（文件路径与行范围、关键符号、最近提交、PR 编号、关联工单），再将可用 MCP 映射到七类证据来源：源代码管理历史、问题/工单跟踪器、长文档、实时团队聊天、基础设施可观测性、错误/异常追踪、产品分析仓库。每个有匹配 MCP 的类别会并行启动一名调查员，各自只负责一个工具或 MCP，并保持宿主 MCP 访问权限。调查完成后由合成器整合发现，输出包含问题、所涉代码、发现内容、可合理推断、竞争假设、未知内容、来源清单和置信度总结的结构化报告。
使用方式：通过 /swarm 启动每个子代理并解析角色模型。调查员提示由 references/investigator-prompt.md 填充，并附带对应来源的 playbook。若目标代码具有防御性特征（空检查、重试逻辑、超时处理、限流、功能标志、出口守卫、OOM 处理等），还会附加事件复盘来源。只读调查和评审只报告文档漂移而不做编辑；创建或实现则通过所属方协调已接受的模型变更。若目标模糊，会根据对话上下文做出最佳猜测并简要说明解释，以便用户纠正。
适用场景：设计理由调查、权衡分析、触发边缘案例、外部约束、死代码、广泛历史追溯；也适用于在修改代码前将历史沿革发现转化为保留/变更/避免/风险约束集。
限制：只有存在匹配 MCP 的类别才会启动调查员；跳过调查员需要明确书面理由并记入来源清单，例如该类别无匹配 MCP（标记为缺口而非选择）或来源可证明无关。只有在确认全部七类可用类别搜索均冗余时，才可内联回答，且应极少发生。调查员不应写入任何内容。合成器必须遵循 references/epistemics.md 中的置信度框架和措辞指南。输出结构可调整，但置信度区分和来源清单（每个调查员一行，包括空结果或跳过及原因）须保持完整。