sentry

sentry skill 概觀

sentry skill 是一個唯讀的 Observability 工具，專門用來快速查 Sentry 資料：issues、events、健康訊號，以及可能對正式環境造成的影響。最適合想直接回答「哪裡壞了、壞在哪、嚴重到什麼程度？」而不想手動在 Sentry 裡一頁頁點的人。和一般通用提示相比，sentry skill 針對 CLI 檢查做過調整，因此在你需要即時資料、可重複查詢與結構化輸出時，可靠度更高。

如果你已經知道自己需要的是 Sentry 專屬洞察，而且想要的是可實作的 sentry 指南來做 triage，而不是泛泛的觀測性總覽，這個 skill 就很適合。它特別適合 incident 回應者、檢查 regression 的工程師，以及需要從即時 Sentry 資料取得精簡、可驗證摘要的分析人員。

sentry skill 擅長什麼

它透過 sentry 指令提供唯讀調查，預設值也偏向快速 triage：近期時間窗、以 production 為優先的篩選，以及可供後續處理的 JSON 輸出。當你需要列出未解決的 issues、依短 ID 檢視特定 issue，或抓取結構化資料又不想失去分頁或驗證處理時，這個 skill 特別有用。

什麼情況下適合用這個 skill

如果你的工作依賴即時的 Sentry 狀態、你需要可重現的查詢，或你預期要反覆調整 environment、project、時間範圍或優先級等條件，那就選 sentry skill。當使用者要的是可重用於自動化或 agent 型分析的 sentry Observability 工作流程時，它也很合適。

安裝前先知道的事

這個 skill 是唯讀的。它不會建立 issue、變更告警，也不會修改專案設定。最常卡住的原因通常是缺少驗證、org/project 指向不清楚，或是拿它去查非 Sentry 資料。如果你需要寫入動作或儀表板，這就不是對的 skill。

如何使用 sentry skill

安裝並完成驗證

用 npx skills add openai/skills --skill sentry 安裝 sentry skill。如果 CLI 還沒可用，先安裝 Sentry CLI，接著用 sentry auth login 或 SENTRY_AUTH_TOKEN 在本機完成驗證。開始要求調查工作之前，先用 sentry auth status 確認權限可用。不要把 token 貼到聊天裡。

給 skill 正確的輸入

要讓 sentry 使用體驗最好，請同時提供具體的調查目標和範圍。好的輸入會點出症狀、環境與時間窗，例如：「調查過去 24 小時最新的 production 5xx 爆量，並摘要最主要的未解決 issues。」如果你知道 project，就直接帶上；如果不知道，就先讓自動偵測試試。CLI 通常可以從 DSN、原始碼、設定預設值與目錄名稱推斷 org/project。

先從正確的檔案與指令開始

先讀 SKILL.md，再查看 agents/openai.yaml 以了解預設行為與 prompt framing。當你需要找可用的 endpoint 或欄位時，使用 sentry schema <resource>。如果要機器可讀的結果，請一律加上 --json，並搭配 --fields 來降低雜訊、讓摘要更精準。

取得更好結果的實務流程

一套穩健的 sentry 指南工作流程是：先確認驗證狀態，再確認目標 org/project，接著跑一個範圍較窄的 list 查詢，最後在總結前先檢查一到兩個 issue 詳情。比如，先從過去 24 小時內未解決的 production issues 開始，如果第一輪太廣，再用 release、environment 或 priority 逐步收斂。這樣能讓分析根據即時資料，而不是被單一吵雜事件帶偏。

sentry skill 常見問答

sentry skill 需要 Sentry CLI 嗎？

需要。sentry skill 是圍繞 sentry CLI 設計的，不是瀏覽器操作流程。如果 CLI 還沒有安裝，請先安裝並在本機完成驗證。這樣的設定，才會讓 sentry 安裝真正值得用在可重複、唯讀的調查上。

這跟一般 prompt 有什麼不同？

一般 prompt 可以描述一個 Sentry 查詢，但 sentry skill 會補上一條明確的操作路徑：驗證期待、預設查詢慣例、JSON 輸出，以及欄位選擇。這能減少猜測，也讓結果更容易驗證或自動化。

sentry skill 適合新手嗎？

適合，只要使用者能把問題說清楚。新手通常只要提供「哪裡壞了、什麼時候壞、在哪裡壞」，就能得到不錯的結果，而不需要自己拼出精確的 CLI 查詢。這個 skill 會處理查詢細節；使用者只要定義調查目標。

什麼時候不該用？

不要拿 sentry skill 來編輯 Sentry 設定、變更告警政策，或處理任何需要寫入權限的流程。若你無法存取相關 org/project，或者問題其實是在 Sentry 之外的應用程式 log，這個 skill 也不適合。

如何改進 sentry skill

提供更精準的調查背景

當你把 environment、時間範圍，以及真正關心的症狀說清楚時，sentry skill 的表現最好。比起「整理最近的錯誤」，「找出 2.4.1 版本發布後過去 6 小時內最主要的未解決 production errors」明確得多。更好的背景資訊可以改善 issue 排序、降低誤判，也能幫助 agent 選到正確的 filters。

要求結構化輸出

如果你想要的是有用的 sentry Observability 結果，請要求表格或條列摘要，並包含 short ID、title、severity 與可能影響。這會把流程往可採取行動的輸出推，而不是變成模糊敘述。如果你要拿去機器處理，請指定 --json 友善的欄位，讓回應保持精簡且可解析。

透過收斂來迭代，不要一開始就放大範圍

如果第一輪結果雜訊太多，優先用 release、environment 或特定 issue short ID 收斂，而不是要求「全部」。如果第一輪結果太少，先放寬時間窗，再考慮移除 filters。最佳的 sentry 使用方式通常是一個聚焦查詢，接著再做一次精修，而不是一次丟出超大的搜尋。