canary

canary 技能概覽

canary 技能用於部署後監控，當你需要確認上線後的正式環境仍然正常運作時，它特別有用。它會監看 production 中的 console errors、頁面失敗與效能退化，再把目前行為和部署前的 baseline 做比較。如果你想要的是一個能檢查真實使用者風險、而不是只靠靜態提示詞的 canary 技能，這套設計就是為了發佈後監測而生。

canary 的用途

當工作目標是監控一次部署、抓出壞掉的頁面，或確認某次發佈沒有引入肉眼可見的 regression 時，就該用 canary。它特別適合想把 canary 用在 Monitoring 的團隊，涵蓋 console、截圖與頁面層級失敗的檢查。

它和一般提示詞有什麼不同

一般的「檢查網站」提示詞，通常只停留在表面檢視。canary 則是圍繞監測工作流程設計：在部署後執行、隨時間觀察正式環境行為、與 baseline 比較，並標記異常。這讓它在問題是「目前 production 健康嗎？」而不是「這個頁面看起來一次性是否正常？」時，更有實際價值。

最適合的情境與限制

這個技能適合接近 CI 或偏操作型的工作流，特別是當部署後的信心很重要時。若你只需要一次性的內容檢查、設計評論，或不需要持續監控的手動 QA 清單，它就沒那麼有用。最大的導入阻力通常是情境資訊：canary 最好用的前提，是你能把它指向正確的 live target，並明確定義「正常」長什麼樣子。

如何使用 canary 技能

canary 的安裝與設定

依照 repo 裡示範的 gstack skills 流程安裝 canary，然後先閱讀 SKILL.md 和 SKILL.md.tmpl。這個技能沒有額外的支援資料夾，所以核心安裝脈絡都放在這兩個檔案裡。如果你要把 canary 指南改寫成自己的 repo 版本，請在提示詞裡明確寫出 production URL、deploy event 與 baseline 來源。

初次提示詞要提供什麼

給 canary 的資訊越少越好，但要足以讓監控有意義：

• 要監看的 app 或 route
• 這次部署改了什麼
• 上線前「正常」是什麼樣子
• 什麼情況算失敗
• 要觀察多久
  弱的提示詞只會說「監控這個 app」。更強的提示詞會說「在今天的部署後監看 /checkout，把截圖和上線前的 baseline 比較，並在 10 分鐘內標記任何新的 console errors、壞掉的按鈕或版面位移。」

canary 的建議工作流程

先從部署時點開始，再依序從 baseline 走到觀察，最後下判斷。先確認目標 branch 或環境，再定義 baseline 行為，接著要求即時檢查與異常回報。如果你是以互動方式使用這個技能，最重要的早期決策是：你要的是主動式監測，還是單次驗證；因為這會影響技能應該如何包裝它的檢查方式。

先讀哪些檔案

先讀 SKILL.md，再讀 SKILL.md.tmpl，了解這個技能是如何生成，以及哪些部分屬於工作流程邏輯。特別注意 preamble、plan mode safety、plan mode 期間的 skill invocation，以及 routing 這些段落。這些最可能影響 canary 是否能正確觸發，以及是否能在對的時間執行。

canary 技能 FAQ

canary 只適用於 production 監控嗎？

不是。它是為部署後的 canary 檢查而設計，所以 production 當然是最明顯的使用情境，但同樣的模式也適用於 staging，或任何你想在變更後做 baseline 比對的 live 環境。

canary 和一般 QA 提示詞有什麼差別？

一般提示詞常常只要求做一次檢視。canary 則更偏向營運操作：它要監看 regression、蒐集證據，並把目前狀態和先前狀態比較。當你需要的是用在 Monitoring 的 canary，而不是泛用檢查時，它就更合適。

canary 適合新手嗎？

可以，只要你能描述部署內容、頁面與失敗條件。真正的難點不是會不會用這個技能，而是你給的 context 是否足夠，讓它能拿有意義的 baseline 去判斷變化。如果你無法定義改了什麼，或哪些地方應該保持穩定，輸出品質就會比較弱。

什麼情況下不該用 canary？

不要拿它來做大範圍的產品分析、內容編修，或那些不依賴 live app 健康狀態的工作。當你沒有 baseline、無法存取目標環境，或無法為這次部署定義明確的 pass/fail 門檻時，它也不是好選擇。

如何改進 canary 技能

給 canary 更清楚的 baseline

最有價值的升級，是把「正常狀態」定義得更精準。請加入部署前截圖、已知良好的 URLs、預期中的 console 行為，以及任何不能壞掉的關鍵 UI 元素。baseline 越精確，技能就越不容易把無害差異誤報成問題。

明確寫出你在意的失敗模式

當你事先點名可能的 regression，canary 的價值會高很多，例如空白畫面、API 資料缺失、導覽壞掉、CSS 位移、console errors、頁面載入過慢，或互動失敗。知道要找什麼的 canary 技能，會比只被要求「找問題」更能產出可直接拿來決策的結果。

第一次執行後持續調整

先用第一輪輸出了解這個技能會抓到什麼，再把提示詞收斂得更精準。如果它回報太多雜訊，就縮小 routes 範圍或提高異常門檻；如果它漏掉重要問題，就補上關鍵使用流程、預期文字，或比較點。好的 canary 指南用法本來就是反覆迭代：先建立 baseline、再檢查、再修正、再重跑。