尧图网页设计 
pstackwhy技能实战以 Linear 工单为证据源还原代码设计动机的完整取证手册【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins本文是 pstack 插件why技能中「Issue / 工单追踪器」证据源的专项取证指南。why技能用于回答这段代码为什么会这样写、当时为什么选了方案 B、这个阈值是哪来的一类动机溯源问题而 Linear 正是产品与业务上下文为什么做最集中的存放地。读完本文你将掌握从 seed 提交/PR 出发、沿工单 ID、关键词、父子工单树、项目文档与标签里程碑五条路径定位真实动机的完整流程并理解如何把 Linear 证据按置信度分级、规避 scope drift 等典型陷阱最终产出可被合成器直接引用的结构化取证结果。Linear 在why技能证据架构中的定位why技能的工作方式是在确认代码锚点目标文件与行号、关键符号、最近提交、PR 号、工单 ID之后并行派出多个调查子代理每个子代理只负责一个证据类别、只持有对应的一类 MCP 工具最后统一交给合成子代理产出带置信度分级与引用证据的结论。在 source-playbook.md 的类别索引表中Linear 对应的是Issue / ticket tracker问题 / 工单追踪器类别证据类别对应 Playbook文档所演示的 MCP源码控制历史code-archaeology.mdgit、ghIssue / 工单追踪器linear.mdLinear可适配 Jira、GitHub Issues、Plane、Shortcut长文档notion.mdNotion可适配 Confluence、Google Docs、Coda实时团队聊天slack.mdSlack可适配 Discord、Microsoft Teams、Mattermost基础设施可观测性datadog.mdDatadog可适配 New Relic、Honeycomb、Grafana、Splunk错误 / 异常追踪sentry.mdSentry可适配 Rollbar、Bugsnag、Airbrake产品分析数仓databricks.mdDatabricks SQL可适配 Snowflake、BigQuery、ClickHouse、dbt据 SKILL.md 的职责定义工单追踪器调查员最擅长挖掘产品或业务层面的驱动力product or business forcing function当『为什么』来自工程之外时证据力最强。这与 Linear 的特点完全吻合它承载的是因为客户 X 提出了需求或这是为了 Q3 合规专项这类业务层动机而不是实现层的技术取舍。需要特别说明的是这份 playbook 是具体 MCP 的示例官方建议在遇到同类别其他工具Jira、GitHub Issues、Plane、Shortcut时按同一套方法论适配——五步检索流程、证据质量标准、陷阱清单与返回格式是跨工具通用的。Linear 里藏着哪些为什么源内容清单根据 linear.md 的源内容定义Linear 一个工单及其关联对象可能携带以下动机信息描述功能 / 缺陷及其动机的 Issue——这是最直接的为什么载体挂在 Issue 上的项目文档——通常是 PRD产品需求文档或规格说明书spec父子工单关系——从更宏观的专项到具体工单的层级父工单往往承载真正的为什么工单评论——澄清、范围变更、我们为什么要这么做的决策性论述标签——如compliance合规、customer-request客户请求、perf性能标签本身就是动机类别的信号状态更新——解释范围变化的动态附件与关联的 GitHub PR——把实现与动机连接起来的桥梁。文档中点明了它的核心价值主张Linear 是产品 / 业务上下文最常存放的地方——即我们做这个是因为客户 X 要求或这是 Q3 合规专项这一层在代码与源码控制历史里是读不到的。这正好呼应了 epistemics.md 的开篇论断代码不携带自身的动机动机存在于提交、PR、工单、文档和对话之中。如何检索Linear MCP 五步取证法linear.md 给出的检索入口是Linear MCP核心流程分五步1. 从被引用的工单开始Start with linked tickets如果 seed 提交或 PR 中出现了工单 ID如ENG-1234、[BUG-567]优先用get_issue抓取这些工单并且要读完整内容、包含全部评论。这一步成本最低、命中率最高——因为提交或 PR 作者在正文里引用工单本身就是动机线索的最强信号。2. 按关键词列出相关工单List related issues by keyword用list_issues对功能名、关键符号symbol或业务术语做文本搜索。官方特别强调尝试多种措辞Try multiple phrasings——同一个功能可能在不同工单里被称作支付超时、payment_timeout、结算慢单一关键词容易漏检。3. 沿工单树向上走Walk the issue tree如果落点是一个子工单sub-issue去抓取它的父工单parent。playbook 给出的判断是子工单是战术性的tactical父工单往往承载为什么——例如子工单是为 PaymentService 增加重试父工单可能是减少支付失败率这一专项。这正是 Linear 父子关系在动机溯源中的核心价值。4. 读取项目文档Read project docs如果工单归属于某个项目用get_project获取项目并检查附件文档。playbook 指出项目级文档是规格与动机最常被记录的地方。PRD、spec 通常不会逐字写进代码注释却会在项目文档里完整展开。5. 检查标签与里程碑Check labels and milestones标签暗示动机类别customer-request客户请求、incident-followup事件跟进、compliance合规里程碑把工作与截止日期绑定——为什么赶工、 为什么在这个时间点做往往从里程碑与 deadline 的关系中显露出来。这套五步流程与 investigator-prompt.md 的调查循环一致先撒大网再收窄go wide before going deep——先用关键词广撒网避免漏掉关联上下文再针对命中项深挖同时强调读全文而非标题摘要因为关键证据常常埋在评论、子任务或后续跟进里。高质量证据长什么样Linear 版直接证据样本playbook 给出了四类典型的高价值证据形态全部是作者明确写下的动机属于 epistemics.md 定义的Direct直接层级工单描述直接陈述业务问题客户 Acme 需要 X因为要过 SOC2 审计——一句话同时给了谁客户、要什么X、为什么合规约束三层信息评论记录了决策及其理由我们决定采用方案 B因为方案 A 需要改动 billing 服务——这是典型的 tradeoff 决策记录且给出了否决理由父工单标题本身就是专项Q3 Enterprise ReadinessQ3 企业就绪或 Reduce Payment Failures降低支付失败率——标题即动机摘要附带的 PRD 或 spec——长格式的动机文档语义明确的标签如customer:acme、incident-followup、compliance、perf-regression——标签把工单归入某类动机。判断标准与 epistemics.md 的 Direct 层级定义完全一致不是代码做了 X 所以作者一定想要 X而是作者实际写下的说明为什么的文字。搜索 Linear 时应优先寻找这种白纸黑字的动机陈述而不是从代码形态反推意图。常见陷阱Linear 取证的五类失真的坑playbook 明确列出了五类高频陷阱每一类都对应具体的处置策略Scope drift范围漂移PR 引用的工单可能曾被关闭又重开且范围已经变化。必须读完整历史不能只看工单当前状态就下结论。机械模板Mechanical templates有些团队强制要求填Why栏但填的是套话。诸如improve user experience改善用户体验这类泛泛文本大概率不是真实答案——真实动机往往藏在评论或附件里。过期工单Stale tickets老工单反映的是当时的计划可能早已变更。核对日期并与代码的实际发布时间交叉比对警惕拿旧计划解释新代码。已关闭-重复链条Closed-as-duplicate chains工单之间的 duplicate-of重复指向关系要一路回溯到权威工单canonical ticket重复工单上可能只有碎片信息。私有工作区内容Private workspace content如果某个工单因权限无法访问如实记录为证据缺口gap而不是猜测——这与 epistemics 框架中搜不到就如实说 Unknown的纪律一脉相承。此外playbook 并未点名但与取证纪律强相关的还有 investigator-prompt.md 的两条禁令不要把机制当成动机一次把limit 50改成limit 100的提交只展示了变更不代表动机动机要在提交信息、PR 描述或关联工单里找不要从代码风格推断意图作者用了函数式写法只是对代码的观察不是意图证据。输出规范每个相关工单要返回什么为了让合成器能够精确引用调查员对每一个相关工单都要返回结构化字段见 linear.md 的What to return工单 ID 与标题来自描述或评论的问题 / 动机原文引用——playbook 特别强调不是转述合成器需要精确原文来引用not paraphrased. The synthesizer needs the exact text to cite标签、父工单、所属项目——动机类别与层级上下文作者、创建日期、关闭日期——时间线证据工单链接如可用——可跳转核实。这与 investigator-prompt.md 的输出格式要求一致调查员产出应包含What I Searched搜了什么含逐字查询词、Direct Evidence Found直接证据逐字引用 出处 作者日期 相关性、Indirect / Circumstantial Evidence间接证据及推断链、Contradictions矛盾双方、Gaps搜了没找到什么、Additional Leads跨源线索转交对应类别的调查员。在 synthesizer-prompt.md 的最终报告中Linear 证据会以[Direct]或[Supported]标注出现在What We Found一节例如[Direct]{结论}。来源工单ENG-1234。{原文引用}。[Supported]{结论}。证据{多来源列表及各自贡献}。从证据到结论Linear 证据的置信度分级epistemics.md 要求最终输出中的每一条论断都落在五级置信度之一Linear 证据也不例外置信度层级判定标准在 Linear 语境下的示例措辞要求Direct直接作者明确写下的动机文字工单描述客户 Acme 需要 X 以通过 SOC2 审计自信、现在时This exists because X. 并给出引用Supported有支撑多份间接证据收敛工单标了perf、父工单叫Reduce Payment Failures、相关提交全部命中同一热点路径证据强烈指向 X[具体证据]Inferred推断有合理解读但无明确陈述工单没写原因但按发布时间与生产事故时间吻合appears to、likely、suggestsSpeculative推测证据单薄且存在其他解释这个阈值可能是为了对齐 SLA但没有任何 SLA 文档引用它明确标注是猜测通常归入 Competing HypothesesUnknown未知搜了但没找到在工单追踪器里用关键词 A、B 搜过没有工单讨论该阈值具体说明搜了什么同时要警惕两处偏置一是谄媚陷阱Sycophancy Trap——用户提问时常自带假设为什么这样写我猜是为了性能吧Linear 证据应该独立检验这个假设而不是顺着用户去确认二是矛盾优先——如果 PR 描述说清理技术债而工单说客户合规要求两份证据都要呈现不要只挑叙事更顺的那份。这正是 Linear 工单经常出现的现实情况工单是动机源头PR 描述是作者对工作的包装口径两者可能同时为真。交叉取证当目标代码呈防御性时必查的 Linear 标签incident-postmortem.md 不是一个独立证据源而是一个跨类别的切入角度事故往往催生防御性代码X 事故之后我们加了这道检查。当目标代码出现 null 检查、重试逻辑、超时处理、限流、特性开关feature flag、出口防护、OOM 处理器等特征时Linear 调查员应专门搜寻以下标签incident事故sev-*严重级别如sev-1、sev-2postmortem-action-item事后复盘行动项reliability可靠性若命中事故线索应取回完整的事后复盘postmortem其Action Items章节通常直接对应到代码变更。当多源交叉印证时证据力最强例如 Datadog 的事故 ID 出现在 Linear 工单中、该工单又出现在 Notion 复盘里、复盘在 Slack 线程中被讨论并链接到目标 PR、且修复上线后 Databricks 中的错误事件计数下降——这一链条中 Linear 承担的是事故与行动项的登记册角色。全流程视角Linear 调查员如何融入why技能将本手册放回 SKILL.md 的完整流程中看Linear 取证是并行调查的一个环节Step 1 明确目标与问题解析用户问的 target代码块、模式、特性或具名设计决策与 question设计理由、tradeoff、边界用例、外部约束、死代码或历史全景Step 2 建立代码锚点通过git blame -L、git log --follow -p、git log --oneline -20、gh pr view提取文件路径、符号、提交哈希、PR 号与工单 ID——这些工单 ID 正是本手册第 3.1 节的检索起点Step 3 并行派出调查员每个可用证据类别一个调查员子代理类型generalPurpose默认模型grok-4.6-fast-xhigh且必须使用 agent 模式而非 readonly/Ask 模式readonly 会剥夺 MCP 访问权导致 Linear 调查员完全失效工单追踪器调查员拿到 linear.md 作为专属 playbook若代码呈防御性则追加 incident-postmortem.mdStep 4 合成合成子代理默认claude-fable-5-1-thinking-max按 epistemics.md 分级并抽查引用Step 5 呈现输出格式固定为 The Question问题→ The Code in Question目标代码→ What We Found发现→ What We Can Reasonably Infer合理推断→ Competing Hypotheses竞争假设→ What We Dont Know未知项→ Sources Consulted来源清单每个类别一行含空结果与跳过理由→ Confidence Summary置信度总结。值得注意的两点细节Sources Consulted 中工单追踪器一行即使无命中也要列出Not searched. No matching MCP available in this environment.这是 SKILL.md document the null, dont skip the search记录空结果不要跳过搜索纪律的直接体现如果用户的why问题是后续改动代码的前置调研还需把取证结论转化为Preserve / Change / Avoid / Risk四类约束集供变更规划使用。最后SKILL.md 点名的首要失败模式是近因偏差recency bias——不要默认最近一次提交最具权威性代码的现状往往是多年决策的累积Linear 工单历史正是对抗这一偏差、沿时间线回溯动机的关键证据源。小结Linear 作为why技能的工单追踪器证据源其价值在于承载产品与业务层的动机客户请求、合规专项、事故跟进。掌握本文的五步检索法被引用工单 → 关键词广搜 → 父子树上行 → 项目文档 → 标签里程碑、四类高质量证据形态、五类典型陷阱与结构化返回格式再配合置信度分级与交叉取证纪律你就能从 Linear 中提取出可精确引用的为什么让每一次动机溯源都有据可查、有源可依。相关完整实现与配套模板可继续查阅 pstack/skills/why/SKILL.md、pstack/skills/why/references/source-playbook.md、pstack/skills/why/references/epistemics.md、pstack/skills/why/references/investigator-prompt.md 与 pstack/skills/why/references/synthesizer-prompt.md。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 pstack `why` 技能实战：以 Linear 工单为证据源，还原代码设计动机的完整取证手册
pstackwhy技能实战以 Linear 工单为证据源还原代码设计动机的完整取证手册【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins本文是 pstack 插件why技能中「Issue / 工单追踪器」证据源的专项取证指南。why技能用于回答这段代码为什么会这样写、当时为什么选了方案 B、这个阈值是哪来的一类动机溯源问题而 Linear 正是产品与业务上下文为什么做最集中的存放地。读完本文你将掌握从 seed 提交/PR 出发、沿工单 ID、关键词、父子工单树、项目文档与标签里程碑五条路径定位真实动机的完整流程并理解如何把 Linear 证据按置信度分级、规避 scope drift 等典型陷阱最终产出可被合成器直接引用的结构化取证结果。Linear 在why技能证据架构中的定位why技能的工作方式是在确认代码锚点目标文件与行号、关键符号、最近提交、PR 号、工单 ID之后并行派出多个调查子代理每个子代理只负责一个证据类别、只持有对应的一类 MCP 工具最后统一交给合成子代理产出带置信度分级与引用证据的结论。在 source-playbook.md 的类别索引表中Linear 对应的是Issue / ticket tracker问题 / 工单追踪器类别证据类别对应 Playbook文档所演示的 MCP源码控制历史code-archaeology.mdgit、ghIssue / 工单追踪器linear.mdLinear可适配 Jira、GitHub Issues、Plane、Shortcut长文档notion.mdNotion可适配 Confluence、Google Docs、Coda实时团队聊天slack.mdSlack可适配 Discord、Microsoft Teams、Mattermost基础设施可观测性datadog.mdDatadog可适配 New Relic、Honeycomb、Grafana、Splunk错误 / 异常追踪sentry.mdSentry可适配 Rollbar、Bugsnag、Airbrake产品分析数仓databricks.mdDatabricks SQL可适配 Snowflake、BigQuery、ClickHouse、dbt据 SKILL.md 的职责定义工单追踪器调查员最擅长挖掘产品或业务层面的驱动力product or business forcing function当『为什么』来自工程之外时证据力最强。这与 Linear 的特点完全吻合它承载的是因为客户 X 提出了需求或这是为了 Q3 合规专项这类业务层动机而不是实现层的技术取舍。需要特别说明的是这份 playbook 是具体 MCP 的示例官方建议在遇到同类别其他工具Jira、GitHub Issues、Plane、Shortcut时按同一套方法论适配——五步检索流程、证据质量标准、陷阱清单与返回格式是跨工具通用的。Linear 里藏着哪些为什么源内容清单根据 linear.md 的源内容定义Linear 一个工单及其关联对象可能携带以下动机信息描述功能 / 缺陷及其动机的 Issue——这是最直接的为什么载体挂在 Issue 上的项目文档——通常是 PRD产品需求文档或规格说明书spec父子工单关系——从更宏观的专项到具体工单的层级父工单往往承载真正的为什么工单评论——澄清、范围变更、我们为什么要这么做的决策性论述标签——如compliance合规、customer-request客户请求、perf性能标签本身就是动机类别的信号状态更新——解释范围变化的动态附件与关联的 GitHub PR——把实现与动机连接起来的桥梁。文档中点明了它的核心价值主张Linear 是产品 / 业务上下文最常存放的地方——即我们做这个是因为客户 X 要求或这是 Q3 合规专项这一层在代码与源码控制历史里是读不到的。这正好呼应了 epistemics.md 的开篇论断代码不携带自身的动机动机存在于提交、PR、工单、文档和对话之中。如何检索Linear MCP 五步取证法linear.md 给出的检索入口是Linear MCP核心流程分五步1. 从被引用的工单开始Start with linked tickets如果 seed 提交或 PR 中出现了工单 ID如ENG-1234、[BUG-567]优先用get_issue抓取这些工单并且要读完整内容、包含全部评论。这一步成本最低、命中率最高——因为提交或 PR 作者在正文里引用工单本身就是动机线索的最强信号。2. 按关键词列出相关工单List related issues by keyword用list_issues对功能名、关键符号symbol或业务术语做文本搜索。官方特别强调尝试多种措辞Try multiple phrasings——同一个功能可能在不同工单里被称作支付超时、payment_timeout、结算慢单一关键词容易漏检。3. 沿工单树向上走Walk the issue tree如果落点是一个子工单sub-issue去抓取它的父工单parent。playbook 给出的判断是子工单是战术性的tactical父工单往往承载为什么——例如子工单是为 PaymentService 增加重试父工单可能是减少支付失败率这一专项。这正是 Linear 父子关系在动机溯源中的核心价值。4. 读取项目文档Read project docs如果工单归属于某个项目用get_project获取项目并检查附件文档。playbook 指出项目级文档是规格与动机最常被记录的地方。PRD、spec 通常不会逐字写进代码注释却会在项目文档里完整展开。5. 检查标签与里程碑Check labels and milestones标签暗示动机类别customer-request客户请求、incident-followup事件跟进、compliance合规里程碑把工作与截止日期绑定——为什么赶工、 为什么在这个时间点做往往从里程碑与 deadline 的关系中显露出来。这套五步流程与 investigator-prompt.md 的调查循环一致先撒大网再收窄go wide before going deep——先用关键词广撒网避免漏掉关联上下文再针对命中项深挖同时强调读全文而非标题摘要因为关键证据常常埋在评论、子任务或后续跟进里。高质量证据长什么样Linear 版直接证据样本playbook 给出了四类典型的高价值证据形态全部是作者明确写下的动机属于 epistemics.md 定义的Direct直接层级工单描述直接陈述业务问题客户 Acme 需要 X因为要过 SOC2 审计——一句话同时给了谁客户、要什么X、为什么合规约束三层信息评论记录了决策及其理由我们决定采用方案 B因为方案 A 需要改动 billing 服务——这是典型的 tradeoff 决策记录且给出了否决理由父工单标题本身就是专项Q3 Enterprise ReadinessQ3 企业就绪或 Reduce Payment Failures降低支付失败率——标题即动机摘要附带的 PRD 或 spec——长格式的动机文档语义明确的标签如customer:acme、incident-followup、compliance、perf-regression——标签把工单归入某类动机。判断标准与 epistemics.md 的 Direct 层级定义完全一致不是代码做了 X 所以作者一定想要 X而是作者实际写下的说明为什么的文字。搜索 Linear 时应优先寻找这种白纸黑字的动机陈述而不是从代码形态反推意图。常见陷阱Linear 取证的五类失真的坑playbook 明确列出了五类高频陷阱每一类都对应具体的处置策略Scope drift范围漂移PR 引用的工单可能曾被关闭又重开且范围已经变化。必须读完整历史不能只看工单当前状态就下结论。机械模板Mechanical templates有些团队强制要求填Why栏但填的是套话。诸如improve user experience改善用户体验这类泛泛文本大概率不是真实答案——真实动机往往藏在评论或附件里。过期工单Stale tickets老工单反映的是当时的计划可能早已变更。核对日期并与代码的实际发布时间交叉比对警惕拿旧计划解释新代码。已关闭-重复链条Closed-as-duplicate chains工单之间的 duplicate-of重复指向关系要一路回溯到权威工单canonical ticket重复工单上可能只有碎片信息。私有工作区内容Private workspace content如果某个工单因权限无法访问如实记录为证据缺口gap而不是猜测——这与 epistemics 框架中搜不到就如实说 Unknown的纪律一脉相承。此外playbook 并未点名但与取证纪律强相关的还有 investigator-prompt.md 的两条禁令不要把机制当成动机一次把limit 50改成limit 100的提交只展示了变更不代表动机动机要在提交信息、PR 描述或关联工单里找不要从代码风格推断意图作者用了函数式写法只是对代码的观察不是意图证据。输出规范每个相关工单要返回什么为了让合成器能够精确引用调查员对每一个相关工单都要返回结构化字段见 linear.md 的What to return工单 ID 与标题来自描述或评论的问题 / 动机原文引用——playbook 特别强调不是转述合成器需要精确原文来引用not paraphrased. The synthesizer needs the exact text to cite标签、父工单、所属项目——动机类别与层级上下文作者、创建日期、关闭日期——时间线证据工单链接如可用——可跳转核实。这与 investigator-prompt.md 的输出格式要求一致调查员产出应包含What I Searched搜了什么含逐字查询词、Direct Evidence Found直接证据逐字引用 出处 作者日期 相关性、Indirect / Circumstantial Evidence间接证据及推断链、Contradictions矛盾双方、Gaps搜了没找到什么、Additional Leads跨源线索转交对应类别的调查员。在 synthesizer-prompt.md 的最终报告中Linear 证据会以[Direct]或[Supported]标注出现在What We Found一节例如[Direct]{结论}。来源工单ENG-1234。{原文引用}。[Supported]{结论}。证据{多来源列表及各自贡献}。从证据到结论Linear 证据的置信度分级epistemics.md 要求最终输出中的每一条论断都落在五级置信度之一Linear 证据也不例外置信度层级判定标准在 Linear 语境下的示例措辞要求Direct直接作者明确写下的动机文字工单描述客户 Acme 需要 X 以通过 SOC2 审计自信、现在时This exists because X. 并给出引用Supported有支撑多份间接证据收敛工单标了perf、父工单叫Reduce Payment Failures、相关提交全部命中同一热点路径证据强烈指向 X[具体证据]Inferred推断有合理解读但无明确陈述工单没写原因但按发布时间与生产事故时间吻合appears to、likely、suggestsSpeculative推测证据单薄且存在其他解释这个阈值可能是为了对齐 SLA但没有任何 SLA 文档引用它明确标注是猜测通常归入 Competing HypothesesUnknown未知搜了但没找到在工单追踪器里用关键词 A、B 搜过没有工单讨论该阈值具体说明搜了什么同时要警惕两处偏置一是谄媚陷阱Sycophancy Trap——用户提问时常自带假设为什么这样写我猜是为了性能吧Linear 证据应该独立检验这个假设而不是顺着用户去确认二是矛盾优先——如果 PR 描述说清理技术债而工单说客户合规要求两份证据都要呈现不要只挑叙事更顺的那份。这正是 Linear 工单经常出现的现实情况工单是动机源头PR 描述是作者对工作的包装口径两者可能同时为真。交叉取证当目标代码呈防御性时必查的 Linear 标签incident-postmortem.md 不是一个独立证据源而是一个跨类别的切入角度事故往往催生防御性代码X 事故之后我们加了这道检查。当目标代码出现 null 检查、重试逻辑、超时处理、限流、特性开关feature flag、出口防护、OOM 处理器等特征时Linear 调查员应专门搜寻以下标签incident事故sev-*严重级别如sev-1、sev-2postmortem-action-item事后复盘行动项reliability可靠性若命中事故线索应取回完整的事后复盘postmortem其Action Items章节通常直接对应到代码变更。当多源交叉印证时证据力最强例如 Datadog 的事故 ID 出现在 Linear 工单中、该工单又出现在 Notion 复盘里、复盘在 Slack 线程中被讨论并链接到目标 PR、且修复上线后 Databricks 中的错误事件计数下降——这一链条中 Linear 承担的是事故与行动项的登记册角色。全流程视角Linear 调查员如何融入why技能将本手册放回 SKILL.md 的完整流程中看Linear 取证是并行调查的一个环节Step 1 明确目标与问题解析用户问的 target代码块、模式、特性或具名设计决策与 question设计理由、tradeoff、边界用例、外部约束、死代码或历史全景Step 2 建立代码锚点通过git blame -L、git log --follow -p、git log --oneline -20、gh pr view提取文件路径、符号、提交哈希、PR 号与工单 ID——这些工单 ID 正是本手册第 3.1 节的检索起点Step 3 并行派出调查员每个可用证据类别一个调查员子代理类型generalPurpose默认模型grok-4.6-fast-xhigh且必须使用 agent 模式而非 readonly/Ask 模式readonly 会剥夺 MCP 访问权导致 Linear 调查员完全失效工单追踪器调查员拿到 linear.md 作为专属 playbook若代码呈防御性则追加 incident-postmortem.mdStep 4 合成合成子代理默认claude-fable-5-1-thinking-max按 epistemics.md 分级并抽查引用Step 5 呈现输出格式固定为 The Question问题→ The Code in Question目标代码→ What We Found发现→ What We Can Reasonably Infer合理推断→ Competing Hypotheses竞争假设→ What We Dont Know未知项→ Sources Consulted来源清单每个类别一行含空结果与跳过理由→ Confidence Summary置信度总结。值得注意的两点细节Sources Consulted 中工单追踪器一行即使无命中也要列出Not searched. No matching MCP available in this environment.这是 SKILL.md document the null, dont skip the search记录空结果不要跳过搜索纪律的直接体现如果用户的why问题是后续改动代码的前置调研还需把取证结论转化为Preserve / Change / Avoid / Risk四类约束集供变更规划使用。最后SKILL.md 点名的首要失败模式是近因偏差recency bias——不要默认最近一次提交最具权威性代码的现状往往是多年决策的累积Linear 工单历史正是对抗这一偏差、沿时间线回溯动机的关键证据源。小结Linear 作为why技能的工单追踪器证据源其价值在于承载产品与业务层的动机客户请求、合规专项、事故跟进。掌握本文的五步检索法被引用工单 → 关键词广搜 → 父子树上行 → 项目文档 → 标签里程碑、四类高质量证据形态、五类典型陷阱与结构化返回格式再配合置信度分级与交叉取证纪律你就能从 Linear 中提取出可精确引用的为什么让每一次动机溯源都有据可查、有源可依。相关完整实现与配套模板可继续查阅 pstack/skills/why/SKILL.md、pstack/skills/why/references/source-playbook.md、pstack/skills/why/references/epistemics.md、pstack/skills/why/references/investigator-prompt.md 与 pstack/skills/why/references/synthesizer-prompt.md。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考