investigate
作者 garrytaninvestigate 技能可引導系統化除錯與根因分析，適用於壞掉、偶發不穩定或出現非預期行為的情況。當你需要先有證據再動手改 code 時，可用在 code review、incident triage、bug fixes，以及「昨天還能用」這類案例。它遵循四階段流程：investigate、analyze、hypothesize、implement。
這個技能評分 82/100，代表它很適合收入目錄給使用者瀏覽：它清楚涵蓋常見的除錯／根因分析流程，也提供足夠明確的觸發情境，能減少猜測；但支援性 repository 材料仍略少，會影響導入便利性。
- 除錯與根因分析情境的觸發條件寫得很清楚，包括發生錯誤、出現 stack traces，或「昨天還能正常運作」等情況，都有明確的主動呼叫指引。
- 作業流程有明確命名與界線，分成四個階段：investigate、analyze、hypothesize、implement，並且強調在找到 root cause 前不能先修。
- 使用 hooks 與 allowed-tools，顯示它有真實的執行行為，而不只是描述性的提示詞。
- repository 沒有 install command、支援文件、references 或 readme，因此使用者主要得依賴 SKILL.md 來理解設定方式與適用範圍。
- frontmatter 內有 placeholder markers，表示雖然主要工作流程內容已經相當完整，但部分區塊可能仍在調整中。
investigate skill 概觀
investigate skill 是做什麼的
investigate skill 用於系統化除錯與根因分析，適合處理故障、偶發不穩定，或行為與預期不一致的情況。它是為了那些不只需要快速補丁的使用者設計的：如果你想知道錯誤為什麼發生、到底改了什麼，以及什麼修法才算安全，investigate 可以幫你把這件事整理成有步驟的工作流程。
誰適合使用它
在 Code Review、事件分流、Bug 修復，以及「昨天明明還可以」這類情境下，都很適合用 investigate skill。當你需要 agent 停止猜測、先蒐集證據，並且從症狀一路推回可確認的原因，再動手改程式時，這個 skill 特別合用。
它為什麼特別
它最大的差異化在於「沒有根因，就不要先修」這條規則。這讓 investigate skill 比一般的 debug prompt 更有紀律：它會把流程推向調查、分析、假設與實作，而不是一開始就直接改碼。它也支援主動觸發，對 agent 工作流程特別實用，因為只要出現錯誤或 stack trace，就可以立刻啟動這個 skill。
如何使用 investigate skill
安裝並呼叫 investigate skill
使用以下指令安裝 investigate skill：
npx skills add garrytan/gstack --skill investigate
當你的提示詞明確描述的是失敗狀態時就該用它，例如 stack trace、500 error、迴歸問題，或預期外輸出。要得到更好的結果，請清楚寫出症狀、出現位置，以及你認為「正常運作」應該長什麼樣子。
提供正確的起始輸入
一個夠強的 investigate 使用提示，通常會包含：
- 精確的錯誤訊息或 log 節錄
- 觸發它的指令、endpoint，或使用者操作
- 最近有哪些變更
- 你已經檢查過什麼
- 影響範圍與緊急程度
範例：Investigate why npm test now fails in CI after the last merge. Compare main vs. HEAD, inspect recent changes in auth middleware, and do not propose code changes until the root cause is confirmed.
先讀對檔案
先從 SKILL.md 開始，再查看 SKILL.md.tmpl，了解是否有樣板化行為或路由邏輯。因為這個 repository 沒有獨立的 rules/、resources/ 或 scripts/ 資料夾，所以主要價值就在 skill 檔本身，以及它引用的任何內嵌內容。若是在 Code Review 情境下使用 investigate，請特別留意觸發語句，以及在編輯前可安全執行的操作邊界。
能提升輸出的工作流程建議
把 investigate 當成決策工作流程，而不是自由發散的聊天。你可以要求 agent 依序：
- 先辨識失敗模式，
- 蒐集支持證據，
- 建立一到兩個可驗證的假設，
- 驗證最可能的原因，
- 實作最小且安全的修正。
如果你跳過第 1 步，這個 skill 仍然可能產生分析內容，但對 Code Review 或事件應變來說，實用性會明顯下降。
investigate skill 常見問答
investigate 只適合 bug 嗎？
不是。investigate skill 也適用於迴歸、部署失敗、整合中斷，以及不清楚的行為變更。只要任務是「搞清楚為什麼會這樣」，investigate 通常就是合適的起點。
它和一般提示詞有什麼不同？
一般提示詞可能會直接要求先修好。investigate skill 則更有結構：它會先強迫做根因思考，這能減少脆弱的修改，也讓最後的變更更容易在 Code Review 中被辯護。
investigate 適合初學者嗎？
適合，只要使用者能提供症狀和一些上下文。初學者通常會因為這個 skill 而少猜很多，但他們仍然需要提供具體證據，例如 logs、重現步驟，或失敗的指令。
什麼情況不該用？
當你已經很清楚自己要改什麼，或只是做沒有故障需要診斷的單純內容編輯時，就不要用 investigate。那種情況下，使用更簡單的任務提示會更快。
如何改進 investigate skill
提供證據，不要只丟一句抱怨
品質提升最大的一步，就是把輸入寫得更精準。不要只說「app 壞了」，而是提供失敗的 request、錯誤文字、檔案路徑、環境，以及最後一次正常運作的狀態。investigate skill 最擅長的是把每個假設都錨定在可觀察的證據上。
縮小搜尋範圍
如果問題出在 Code Review，請先指出最可能的子系統與變更區間。例如：「聚焦在 auth，只看最近兩個 commit 的變動，並確認這個 bug 能不能在 staging 重現。」這樣可以避免 investigate 的範圍發散，也更容易快速找到根因。
第一次結果不夠明確時，繼續迭代
如果第一次回答還不夠確定，不要要求它更大範圍重寫，而是要求更精準的調查。好的追問包括：「列出前三個假設，並附上信心程度」、「說明能推翻每個假設的證據是什麼」，或「沿著從輸入到輸出的路徑追查失敗，先不要寫程式。」