why

用途

why 是一个调查代码动机与意图的技能。它的同伴技能 how 回答代码做什么、如何运作；why 回答的是：是什么力量塑造了这段代码的当前形态。

典型问题类型包括：设计理由（design rationale）、权衡取舍（tradeoff）、触发它的边界情况、外部约束、死代码，以及大范围的历史梳理。触发方式包括：名称以粗体或反引号标出、以 /<name> 运行，或直接以“为什么 X 是这样工作的”“为什么我们选了 Y”这类问题提出。

主要能力

• 建立代码锚点：文件路径与行区间、关键符号（函数、类、常量）、触及目标的最近若干次提交、合并提交主题行中形如 (#1234) 的 PR 编号、以及任何关联的工单 ID。
• 通过 git blame、git log --follow -p、git log --oneline、git log -1 --format=%B 等命令获取最后改动提交、跨重命名的完整历史（含补丁）、带 PR 编号的近期提交，并用 gh pr view 拉取 PR 正文与讨论。
• 发现并归类可用 MCP：按服务器对 MCP 工具分组，把每个 MCP 映射到一个证据类别（源码控制历史、工单/任务追踪、长文档、实时团队聊天、基础设施可观测性、错误/异常追踪、产品分析数据仓库）。源码控制始终通过 git 和 gh 可用；其余六类依据 MCP 名称、服务器说明、工具名称与资源描述符分类，模糊情况记录在覆盖率映射中。
• 并行派出调查子代理：每个有匹配 MCP 的类别派出一个，单轮内并发运行，每个子代理只负责一个工具或 MCP。
• 合成调查结果：由 why synthesizer 汇总，输出中严格区分事实与推断，保留置信度语言。

使用方式

1. 理解目标与问题。若目标含糊（如“为什么我们要这么做？”且无明确指代），从对话上下文（打开的文件、最近编辑、刚讨论的内容）做最佳猜测，简要说明你的理解以便用户纠正，然后继续。
2. 建立代码锚点，作为种子上下文，发送给每个调查者和合成器。
3. 默认执行完整的并行调查，目标是完整的覆盖率映射而非最小集合；记录“空结果”，不跳过搜索。
4. 合成：派出一个 why synthesizer，接收调查者发现（含空结果与带理由跳过的类别）、代码锚点、用户原始问题、认识论框架与合成器提示模板。
5. 呈现：将合成器输出交给用户，可轻量编辑以提升清晰度或补充对话上下文，但不得改写置信度语言。

输出结构为：The Question、The Code in Question、What We Found、What We Can Reasonably Infer、Competing Hypotheses、What We Don't Know、Sources Consulted、Confidence Summary。可按需调整，但须保持置信度分层，且 Sources Consulted 中每个调查者一行，包括返回空结果或被跳过者并注明原因。在 Sources Consulted 之后，若用户的 why 问题是为修改此代码做准备，则把溯源发现转化为 Preserve / Change / Avoid / Risk 约束集，用于规划改动。

子代理配置方面：每次 spawn 都是 mode 为 "async" 的 delegate_task 子任务，对应 ~/.config/pstack/pstack-models.md 中的角色行。条目 <providerInstanceId>/<model> (<effort>) 会被转成 target 对象，effort 选项 id 由 orchestrator_capabilities 为该模型列出。当值为 auto 或 inherit-parent，或文件/行缺失时省略 target，子代理在父线程模型上运行；无文件时说明并建议运行 /setup-pstack；若 delegate_task 拒绝某条目，改用同一提供方中 orchestrator_capabilities 列出的最接近模型并说明。每个 spawn 继承运行时模式，不传更弱的模式（会剥离 MCP 访问，从而禁用基于 MCP 的调查者和合成器的引用抽查）。所有 spawn 均为只读：仅检查，不写入，不执行改变状态的 git 命令。子代理只拿到自己的简报，因此需把其要用的参考文件粘贴进简报，或给出绝对路径。

调查者名单（每个可用证据类别一个）

• 源码控制（git 历史、gh 查 PR、代码注释、测试）。始终派出，唯一保证可用的来源。最擅长：评审时记录下的实现期理由。
• 工单/任务追踪（如 Linear、Jira、GitHub Issues、Plane、Shortcut MCP）。最擅长：产品或业务层面的驱动因素。
• 长文档（如 Notion、Confluence、Google Docs、Coda MCP）。最擅长：在变成代码之前写下的长篇设计理由。
• 实时团队聊天（如 Slack、Discord、Microsoft Teams、Mattermost MCP）。最擅长：从未进入文档的实时讨论。
• 基础设施可观测性（如 Datadog、New Relic、Honeycomb、Grafana、Splunk MCP）。最擅长：促成该代码的基础设施与运行时现实。
• 错误/异常追踪（如 Sentry、Rollbar、Bugsnag、Airbrake MCP）。最擅长：促成防御性或纠正性代码的具体异常与错误轨迹。
• 产品分析数据仓库（如 Databricks、Snowflake、BigQuery、ClickHouse、dbt、Redshift MCP）。最擅长：塑造代码的产品与数据现实。

当目标代码看起来是防御性的（空值检查、重试逻辑、超时处理、限流、功能开关、出口守卫、OOM 处理）时，还会附加 incident-postmortem 来源手册。

适用场景

• 追问某段代码、某个模式、某个功能或某个具名设计决策的动机。
• 设计理由、权衡取舍、触发它的边界情况、外部约束、死代码、大范围历史梳理。
• 回归问题与事后复盘。
• 有数据支撑的阈值来源（“这个数字从哪来的”）。
• 在改动某段代码之前，先弄清必须保留什么、可以改什么、应当避免什么、存在哪些风险。

限制

• 多数 pstack 技能仅限用户调用，技能工具无法加载它们。
• 跳过某个调查者需要明确写入的正当理由，且该理由会记入最终的 Sources Consulted。仅两种有效理由：该环境中该类别没有可用 MCP（标为缺口而非选择）；来源可证明无关（高门槛，例如“目标是无运行时代码路径的构建期脚本”）。
• 仅当可以确认全部七类可用类别的搜索都将是冗余时，才可在行内直接作答，且须明确说明，这种情况应当很少见。
• 子代理依靠 ~/.config/pstack/pstack-models.md 中的角色行配置；该文件缺失时需说明并建议运行 /setup-pstack。
• 每次 spawn 保持继承运行时模式，不得传更弱的模式，否则会因剥离 MCP 访问而禁用基于 MCP 的调查者与合成器的引用抽查。
• 所有 spawn 均为只读。

运行姿态

以谨慎、细致、精确的调查者姿态运作，诚实区分自己知道的内容与正在推断的内容。完整置信度框架与措辞指南见 references/epistemics.md，合成器必须遵循。常见失败模式是“近因偏差”：假定最近的提交最具权威性，而当前形态往往是许多更早决策层层累积的结果，需要回溯。

关于安装命令、收费与价格、平台支持等具体信息，所给资料中暂未提供。