safety-guard

safety-guard 技能概覽

safety-guard 的用途

safty-guard 技能會為具破壞性或高風險的 agent 動作增加一道保護層。當你想阻止危險指令、把寫入限制在某個目錄內，或讓自主 agent 在較不容易傷害 production、部署目標或正式資料的前提下執行時，它特別實用。

最適合的使用情境

如果你在管理正式環境、以全自動模式執行 coding agent，或經常處理 migration、基礎架構變更與 release 任務，就很適合安裝 safety-guard。當真正的需求不是單純「小心一點」，而是「讓不安全的動作更難被執行」時，safety-guard skill 就很有用。

為什麼重要

它的核心價值在於工作流程控制：這個技能會攔截像強制推送、硬重置、破壞性刪除，以及大範圍系統清理這類高風險指令，同時也能把編輯範圍鎖定在單一路徑。這讓 safety-guard for Access Control 在 model 擁有很寬的 repo 存取權，但實際上只該修改狹窄區域時，特別實用。

如何使用 safety-guard 技能

安裝並找到來源

使用 repo 中顯示的 safety-guard install 指令：
npx skills add affaan-m/everything-claude-code --skill safety-guard

先從 skills/safety-guard/SKILL.md 開始。如果你想最快掌握重點，先看 mode 定義，再掃過同一檔案中任何連結的實作說明。

把模糊目標轉成可用提示詞

safety-guard usage 的模式在你同時說清楚任務、風險等級與寫入邊界時最有效。好的輸入會直接點出目標區域，以及你要的防護規則：

• “Update the billing API, but only write inside src/api/ and block destructive commands.”
• “Run in guarded mode while I review changes before any publish or deploy.”
• “Protect production migration work and ask before any command that can delete or reset state.”

先讀會改變行為的部分

如果你要找實用的 safety-guard guide，請先看 mode 說明與解鎖流程。repo 裡真正有價值的細節，是三種保護模式、它會監看哪些指令，以及精確的 freeze 語法。這些內容會直接影響這個技能在你的環境裡是否真的能落地執行。

能帶來更好結果的工作流程

當你主要想針對危險指令取得確認時，用 careful mode。當你需要限制寫入範圍時，用 freeze mode。若兩種風險都存在，就使用 combined guard mode。如果任務範圍很窄，就明確寫出允許的目錄；如果是偏營運性質，就把必須觸發確認的特定指令或動作寫清楚。

safety-guard 技能 FAQ

safety-guard 只適合 production 嗎？

不是。它在 production 最有價值，但在 staging、共享 repo，以及本地自主執行時也很有幫助，因為誤刪、重置或發布在這些情境下仍然可能代價很高。

這和一般提示詞有什麼不同？

一般提示詞依賴 model 記得要小心。safety-guard skill 則把小心變成可重複的控制模式：它會監看高風險指令、阻擋在允許樹狀結構之外的寫入，並把邊界明確化。

safety-guard 適合新手嗎？

適合，如果你的目標很單純：在 agent 編輯 repo 時保護整個專案。新手最需要理解的是「基於確認的保護」和「以目錄為單位的寫入限制」之間的差異。

什麼情況下不該使用？

不要把 safety-guard 當成 code review、備份或環境權限的替代品。它是防護欄，不是復原方案。如果你的任務需要大範圍、無限制的重構，freeze mode 可能會太受限。

如何改進 safety-guard 技能

讓技能的邊界更明確

最有價值的改進，是把範圍說明寫得更清楚。不要只說「請注意安全」，而是要明確說出哪些內容必須保護、哪些可以編輯、哪些只能讀取。越精準的輸入，通常代表更少誤擋，也更少來回溝通。

把你預期的高風險操作說出來

如果你的流程包含 deploy、publish、資料庫變更或清理指令，請一開始就講明。當 safety-guard skill 知道該優先確認、凍結寫入，或同時處理兩者時，就更容易調整到符合你的需求。

留意常見失敗模式

最常見的失敗模式，是 freeze 範圍設得太大，結果把正常編輯也擋住。第二種則是任務描述太模糊，讓 agent 不確定某個指令到底可不可以執行。如果第一次結果太嚴格，就縮小受保護的路徑；如果太寬鬆，就加入更明確的指令與路徑限制。

第一次執行後要持續調整

第一次跑完後，請根據 agent「嘗試做了什麼」來調整，而不只是看它「最後改了什麼」。如果它試圖執行高風險指令，就把你的使用說明中要封鎖的模式擴充進去。如果它偏離了預定區域，就把允許的目錄收得更緊。