pstack-why 是一个面向前端编码代理的调查类技能，核心问题是“为什么要这样写”，即追溯一段代码、一个模式、一项功能或某个命名设计决策背后的动机、权衡、外部约束或历史遗留原因。它与 /pstack-how 配套使用：后者回答代码做什么、如何运作，前者回答是什么力量塑造了它当前的形态。
主要能力方面，技能先解析调用项目所配置的产物，并声明只读调查与评审会报告文档漂移但不做修改，创建或实现则通过对应负责人协调已接受的模型变更。调查过程默认采用完整的并行覆盖，而不是最小范围搜索，对没有结果的来源也会记录，而不是跳过搜索。
使用方式上分为若干步骤。第一步明确目标与问题；若目标含糊，则根据对话上下文（打开的文件、最近编辑、光标位置、刚讨论的内容）做出最佳猜测并简要说明解释，便于用户纠正。第二步建立代码锚点：收集文件路径与行号范围、关键符号、触及目标的最近提交、合并提交中的 PR 编号及关联工单编号，并运行 git blame、git log、gh pr view 等命令提取 PR 正文与讨论，该锚点会传给每位调查者和综合者。第三步按当前宿主可用的 MCP 列出证据类别，包括源码控制、工单跟踪、长文档、实时团队聊天、基础设施可观测性、错误追踪和产品分析仓库；源码控制始终通过 git 与 gh 可用，其余六类根据 MCP 名称、服务器说明、工具名称和资源描述归类。每个有匹配 MCP 的类别各派一名调查者，在单条消息中并发运行，每人只负责一个工具或 MCP。若目标代码呈防御性特征（空值检查、重试、超时、限流、特性开关、出口防护、OOM 处理等），还会附加事故复盘来源手册。第四步由一名综合者汇总调查结果、代码锚点、原始问题与置信度框架。第五步呈现结果，可做轻度编辑或补充上下文，但不得改写置信度措辞。
输出结构包括：问题、所涉代码、我们发现什么、可合理推断什么、竞争假设、我们不知道什么、已查阅来源、置信度总结。已查阅来源按每位调查者一行记录，包括无结果或被跳过者及原因。若用户的“为什么”问题是为修改代码做准备，还会把沿革发现转化为保留、变更、规避、风险四类约束，供规划改动使用。
适用场景包括：理解设计理由与权衡、排查回归、识别历史约束、核对阈值背后的证据、审查死代码或做广泛历史梳理。限制与注意事项：环境缺少某类 MCP 时只能标记为缺口；跳过调查者需要明确书面理由，且门槛较高（来源可证明无关，而非“大概无关”）；派出的调查者必须保留宿主的 MCP 访问，不能使用会剥离 MCP 工具的只读模式；调查者不应写入任何内容；需避免近因偏差，不能假定最近提交就是权威。