investigate
作者 garrytaninvestigate 技能用于指导对故障、偶发性问题或异常行为进行系统化排查和根因分析。适用于代码评审、事故分诊、缺陷修复，以及“昨天还好好的”这类场景——当你需要先拿到证据再改代码时，它尤其有用。它遵循四阶段工作流：investigate、analyze、hypothesize、implement。
该技能得分 82/100，属于目录中值得收录的稳定候选：它明确覆盖了常见的调试与根因分析流程，并提供了足够清晰的触发指引，能减少用户猜测；不过，仓库中仍缺少一些辅助材料，影响上手和采用效率。
- 对调试和根因分析场景的触发条件写得很明确，尤其适合在出现错误、堆栈跟踪，或“昨天还能用”这类情况时主动调用。
- 工作流被清晰地定义为四个阶段——investigate、analyze、hypothesize、implement——并且明确禁止在定位根因前直接修复。
- 使用 hooks 和 allowed-tools，说明它更像是真实可执行的技能，而不是纯描述性的提示词。
- 仓库没有安装命令、支持文件、参考资料或 readme，因此用户主要只能依赖 SKILL.md 来理解安装方式和适用范围。
- frontmatter 中包含占位标记，说明虽然主体工作流内容已经比较完整，但部分内容可能仍在持续打磨。
investigate 技能概览
investigate 技能是做什么的
investigate 技能用于系统性排查和根因分析，适合处理故障、偶发不稳定，或行为与预期不一致的情况。它面向的不是只想快速补个丁的用户，而是那些需要先弄清楚“为什么会报错、哪里变了、什么修复才算安全”的场景；investigate 会帮助你把这类工作组织起来。
谁适合使用它
investigate 技能适用于代码审查、事故分诊、Bug 修复，以及“昨天还能用”的问题场景。当你需要 agent 停止猜测、先收集证据，并沿着症状一路追到确认的原因之后再改代码时，它尤其合适。
它的优势在哪里
它最核心的区别是“没有根因，不给修复”。这一点让 investigate 比通用 debug prompt 更严格：它会把工作流往调查、分析、假设验证和实现推进，而不是一上来就直接改代码。它还支持主动触发，这对 agent 工作流很有用——一旦出现错误或 stack trace，技能就能立刻启动。
如何使用 investigate 技能
安装并调用 investigate
使用以下命令安装 investigate 技能：
npx skills add garrytan/gstack --skill investigate
当你的 prompt 明确描述的是失败状态时就该用它，比如 stack trace、500 error、回归问题或意外输出。为了获得更好的结果，请直接说明症状、出现位置，以及“正常工作”应该是什么样。
提供正确的起始输入
高质量的 investigate 使用 prompt 应该包含：
- 准确的错误信息或日志片段
- 触发它的命令、endpoint 或用户操作
- 最近改动了什么
- 你已经检查过哪些内容
- 影响范围和紧急程度
示例：“调查为什么 npm test 在最近一次 merge 后开始在 CI 里失败。比较 main 和 HEAD，检查 auth middleware 的最近改动，并且在根因确认之前不要提出代码修改建议。”
先读对文件
先看 SKILL.md，再检查 SKILL.md.tmpl，了解是否存在模板化行为或路由逻辑。由于这个仓库没有单独的 rules/、resources/ 或 scripts/ 目录，所以主要价值就在 skill 文件本身，以及它引用的任何内联内容。对于用于 Code Review 的 investigate，要特别注意触发语句，以及编辑前允许执行哪些安全操作。
能显著提升结果的工作流建议
把 investigate 当作一个决策流程，而不是随意聊天。让 agent 按下面的顺序做事：
- 识别故障模式，
- 收集支持性证据，
- 形成一到两个可验证的假设，
- 验证最可能的原因，
- 实施最小且安全的修复。
如果你跳过第 1 步，skill 仍然可能生成分析内容，但对 code review 或事故响应来说就没那么有用。
investigate 技能 FAQ
investigate 只适合 Bug 吗？
不是。investigate 技能也适用于回归、部署失败、集成故障，以及不清楚的行为变更。只要任务是“弄明白为什么会这样”，investigate 通常就是合适的起点。
它和普通 prompt 有什么不同？
普通 prompt 可能会直接要求修复。investigate 技能的结构更强：它会先强制进行根因思考，从而减少脆弱的修改，也让最终变更在 code review 中更容易被证明是合理的。
investigate 适合新手吗？
适合，只要用户能提供症状和一点上下文。新手通常会从这个技能中受益，因为它减少了猜测；但他们仍然需要给出具体证据，比如日志、复现步骤或失败的命令。
什么时候不该用它？
当你已经明确知道自己要改什么，或者只是做一个不涉及故障诊断的简单内容编辑时，不要用 investigate。在这些情况下，更简单的任务 prompt 会更快。
如何改进 investigate 技能
提供证据，不要只描述抱怨
质量提升最大的地方在于输入更精确。不要只说“应用坏了”，而要提供失败请求、错误文本、文件路径、环境信息，以及最后一次正常工作的状态。investigate 技能在每个假设都能锚定到可观察证据时，表现最好。
缩小搜索范围
如果问题出现在 Code Review 中，先指出最可能的子系统和变更窗口。例如：“重点看 auth，只检查最近两个 commit 的改动，并确认这个 bug 能否在 staging 里复现。”这样可以避免 investigate 发散得太宽，也更容易更快找到根因。
第一次分析后继续迭代
如果第一次回答不够明确，不要要求更大范围的重写，而是要求更聚焦的调查。好的追问包括：“列出前三个假设，并给出置信度”“说明什么证据能推翻每个假设”“沿着从输入到输出的路径追踪故障，并在编码前停止”。