這個功能跟一般手動上傳的 Skill 相比，安全性上的差異具體在哪裡？
手動上傳的 Skill（透過 Skills API 或設定介面加入 agent 的 skills 陣列）通常經過使用者自己主動選擇與確認，即使來自第三方，至少是使用者有意識地決定要安裝這一份內容。從 GitHub repo 讀取的 Skill 則不同：只要 repo 被掛載，root 目錄下 .claude/skills 裡的任何內容都會被自動掃描並提供給 agent，這個載入過程本身不要求使用者對每一個被發現的 Skill 再次確認。
這代表風險的決定點從「安裝 Skill 的當下」往前移到了「决定要不要掛載這個 repo、以及誰有權限提交到這個 repo」。如果 repo 的貢獻權限管理鬆散，等於間接放寬了 Skill 的安裝門檻。
為什麼 Anthropic 要選擇「自動掃描、無需審核」這種設計，而不是要求使用者逐一確認每個發現的 Skill？
這個設計選擇背後的邏輯，跟 Skill 從 GitHub repo 讀取這個功能本身的定位有關：它的價值就在於「跟著程式碼庫自動同步」，如果每次 session 啟動都要使用者手動確認新發現的 Skill，會直接削弱這個功能省下人工同步成本的初衷，變得跟手動上傳沒有本質差異。
换個角度看，這個設計選擇把責任分配得很清楚：Anthropic 提供的是「自動載入」這個機制本身，而「這個 repo 值不值得信任」的判斷，則交給選擇要不要掛載這個 repo 的使用者或組織。官方文件用「信任邊界」這個詞，其實就是在明確劃出這條責任線——掛載動作本身就是一次信任決定，不是掛載之後才需要另外把關。
掃描規則裡「只掃根目錄下固定深度的 .claude/skills」這個限制，實際上是在防範什麼？
官方文件明確列出幾種不會被掃描到的路徑：repo 根目錄以外的子目錄裡的 .claude/skills（例如某個套件子目錄內）、巢狀超過一層的路徑、以及 .claude 之外命名的 skills 資料夾。這個限制的作用是讓「這個 repo 到底啟用了哪些 Skill」變成一件可以被預期、可以被稽核的事——如果掃描邏輯是遞迴搜尋整個 repo 任何深度的任何資料夾，審查者要確認「這個 repo 目前掛載後會載入哪些 Skill」的難度會高很多，惡意內容也更容易被藏在不起眼的深層路徑裡不被注意到。
值得注意的是，官方文件也提到一個例外：repo 其他地方（例如某個套件子目錄內）如果也有一個 .claude/skills 目錄，雖然不會在 session 啟動時被主動宣告，但如果 agent 之後讀取到那個子目錄底下的檔案，裡面的 Skill 內容仍然可能被間接接觸到——這代表「固定路徑深度掃描」限制的是自動宣告的範圍，不是完全阻絕其他路徑的 Skill 內容被讀到的可能性。
如果我的團隊正在考慮把 Skill 存進共用 repo，實際上該怎麼設計權限與流程？
最直接的做法是把 .claude/skills 目錄的變更納入既有的 code review 流程——如果團隊已經要求 PR 必須經過至少一人審核才能合併，這個機制自然就涵蓋了 Skill 的異動，不需要另外設計一套審核流程。真正的風險點在於那些「不強制 code review 就能合併」的路徑，例如倉庫擁有者自己直接推送到主分支、或是自動合併規則涵蓋範圍過寬。
對於會接受外部貢獻（例如開源專案）的 repo，官方建議「掛載前先檢視 .claude/skills」實際上代表：不要把外部貢獻者的 PR 自動視為安全，尤其如果 PR 內容觸及這個目錄，即使程式碼本身看起來無害，也值得多花一點時間確認裡面的指令內容，因為它會在下次有人掛載這個 repo 時，直接具備存取 bash、web_fetch 等工具的執行能力，風險層級跟一般程式碼變更不完全相同。
Anthropic 官方文件近期更新，Claude Managed Agents 現在支援直接從掛載的 GitHub Repository 讀取 Skill：只要 session 掛載了某個 repo，系統會在 session 啟動時自動掃描該 repo 根目錄下的 .claude/skills 資料夾，找到的每個 Skill 都會自動可供 agent 使用，不需要另外上傳或在設定裡逐一列出。
這個設計的用意很直接：讓 Skill 可以直接跟著程式碼庫走。一個團隊的程式碼審查規範、發版流程、內部工具用法，可以用 Skill 的形式存放在 repo 裡，跟著版本控制系統一起管理，任何人 clone 或掛載這個 repo，Claude 就自動具備這些領域知識，不必額外同步一份 Skill 清單。
值得注意的是，官方文件在說明這項功能的同時，用相當明確的措辭指出了對應的風險：掛載的 repository 本身就成為 agent「信任邊界」的一部分。任何有權限提交到這個 repo 的人——包括一個被合併的外部 pull request、一個被入侵的相依套件、或是一名協作者——都能新增或修改 Skill，而平台在 session 啟動時載入這些 Skill 並不會經過任何審核步驟。一旦被載入，session 裡可用的工具（例如 bash、web_fetch）會讓這些指令具備真正的執行力，不只是被動的參考文字。
官方文件的建議很直接：只掛載你信任的 repository，如果要掛載一個接受外部貢獻的 repo，在掛載前先檢視一遍裡面的 .claude/skills 目錄。掃描規則也有明確定義：只會在 repo 根目錄下 .claude/skills/<skill-name>/SKILL.md 這個固定路徑深度找 Skill，掃描只在 session 啟動當下執行一次，session 進行中若有新的 commit 推送進來，不會被自動載入，需要開新 session 才會重新掃描。
如果你目前只是把 Claude Skills 用在個人工作流程，這項功能不會直接影響你，但它點出一個所有 Skill 使用者都該有的意識：Skill 一旦被載入，就具備跟一般指令一樣的執行力，來源的可信度直接決定風險大小。對於正在評估要不要讓團隊把 Skill 存放進共用 repo 的人，這代表 repo 的存取控制（誰能合併 PR、是否要求 code review）某種程度上也變成了 Skill 治理的一部分，而不只是程式碼品質的把關機制；尤其是接受外部貢獻或有多人協作權限的 repo，合併別人的 PR 之前，多看一眼有沒有異動到 .claude/skills 目錄，會是一個成本很低但值得養成的習慣。