Claude Code｜Skill 何時啟動：手動呼叫與自動選用

Skill 會不會被使用，與使用後做得對不對，是兩個不同問題。本篇用相同的差異審查流程比較手動呼叫、自動選用及背景參考，建立包含正向、反向與資訊不足情境的啟動矩陣，避免一個描述太寬的 Skill 干擾所有工作。

先讀建立 Skill與SOP 工作坊。下載第 70 篇材料，開啟 starter。需要可登入的 Claude CLI；Node.js 22 用於檢查材料。閱讀約 20 分鐘，練習約 45 分鐘。

先選擇誰能啟動這個流程

閱讀完整文字說明

Skill 何時啟動：手動呼叫與自動選用，以流程和文件圖形呈現教學重點。

手動任務適合有明確起點、成本或副作用的流程；自動選用適合與使用者要求直接相關的可重用步驟；背景參考適合只有知識規範、沒有獨立任務的內容。本篇三種實驗都只使用本機假資料，不部署、不提交、不建立外部 PR。

材料提供 skills/review-change 的手動版本，以及 skills/variants/automatic.md 和 background.md。variants 是教材素材目錄，不是 Claude 自動載入的位置。每次只安裝一種受測版本，避免三個相似名稱同時存在，讓結果難以解釋。

依官方欄位，disable-model-invocation: true 用於只由使用者啟動；user-invocable: false 用於不直接提供使用者呼叫的背景 Skill。預設可由兩者使用，但是否自動選中仍取決於任務及描述。這些欄位控制呼叫方式，不是完整的資料存取政策。

先建立手動版本的對照組

把 skills/review-change 複製到 .claude/skills/review-change，保留 disable-model-invocation: true。另開 Claude，先輸入斜線查看可用指令來源，再手動呼叫 fixtures/toggle.diff。記錄技能名稱、來源位置與最後使用的材料，確認不是同名的個人 Skill 被呼叫。

/review-change fixtures/toggle.diff

另開新工作階段，只用自然語言請它審查相同 diff。手動限定版本不應由模型自行以 Skill 呼叫；但模型仍可能依一般能力完成審查。最後答案正確不代表 Skill 被使用，也不能只因回答提到「審查」就判定呼叫失敗或成功。

請審查 fixtures/toggle.diff 的正確性，列出有證據的問題。
只做唯讀分析，不修改檔案。

判定依據應是可見的 Skill 使用紀錄與來源，而不是模型說「我依照流程處理」。如果介面沒有顯示足夠資訊，記錄為無法確認。不要把「沒有觀察到」一律寫成「一定沒有發生」，尤其當不同版本提供的紀錄細節不一樣時。

改成可自動選用的版本

備份手動入口到教材目錄，再把 automatic.md 的內容套用到安裝位置。它移除手動限定欄位，並以具體情境描述：使用者要求審查指定 diff 的正確性時，回報有證據的問題。新工作階段重跑同一句自然語言請求，其他設定保持相同。

---
name: review-change
description: 當讀者要求審查指定 diff 的正確性時，檢查變更並回報有證據的問題。
allowed-tools: Read, Grep, Glob
---

先確認讀者指定的 diff；缺少資訊先詢問。
只读審查，不修改、不提交、不建立 PR。
使用 templates/report.md，區分實際證據與待驗證推論。

測完正向案例，立刻做反向案例：「解釋 JavaScript map 的用途」與「把這句文字翻成英文」。這些任務不需要差異審查。如果 Skill 頻繁被選中，檢查 description 是否仍寫著「所有開發工作都適用」，或入口是否企圖接管整段對話。

再測一個缺少檔名的模糊請求：「幫我審查一下」。合理流程是先確認範圍，不自行把整個專案當成輸入。自動選用的便利不應犧牲參數契約，否則你只是把原本需要手動指定的資訊改成模型猜測。

背景知識使用另一個名稱

在 .claude/skills/data-conventions 建立 SKILL.md，使用 background.md 的內容。這份材料只有待辦 id 與純函式契約，不包含「開始審查」「產生 PR」等獨立任務。因此它適合在處理相關資料邏輯時作為背景參考，而不是讓讀者輸入一個動作指令。

---
name: data-conventions
description: 在閱讀或修改待辦資料函式時參考 id 與純函式契約。
user-invocable: false
---

待辦可以有相同標題，必須依 id 辨識。
資料函式不得原地修改來源陣列或物件。
本文件提供參考，不會自行執行命令、修改檔案或啟動審查。

另開階段，先查看指令可用性，再要求解釋 toggleTodo 的資料契約。記錄背景內容是否被選用，以及實際回答是否符合程式。不要用「沒有出現在選單」推論它無法被模型使用；這正是需要區分使用者可呼叫與模型可選用的原因。

如果專案 CLAUDE.md 已有相同規則，模型可能不需額外 Skill 也能回答。可以用來源標記協助辨認，但不要把測試問題直接寫成「請使用 data-conventions」，因為那已變成明確指定。需要測自動選擇時，輸入應保持一般使用者自然說法。

用矩陣記錄，不靠單次印象

至少保存兩個正向與兩個反向案例，每種設定在新工作階段重跑。若只有某一次失敗，先看可見工具紀錄、描述和來源，避免把隨機差異說成穩定規則。想比較改善幅度時，保留固定的案例集合與模型版本，記錄所有結果，而不是只留下最好的一次。

同名 Skill 是另一個干擾來源。個人、專案與 Plugin 可能提供相似名稱，Plugin 還有命名空間。排錯時確認真正來源，不要看到 /review-change 就直接假定來自剛編輯的文件。可以暫時使用課程專用名稱避免碰撞，再在驗證完成後決定正式名稱。

故障練習與還原

把 automatic.md 的 description 暫時改成「處理所有工作」，其他內容不變，重跑反向案例。這不是保證每次都會誤觸發，而是用來觀察過寬描述增加的混淆。恢復具體描述，再使用相同案例比較，將沒有改善的結果也保存。

再將兩個控制欄位設成讓雙方都無法呼叫的組合，觀察當前版本的實際提示。練習後恢復你選定的模式，只留下必要的受測文件。不要在正式專案留下三份互相矛盾的入口，否則下次排錯會重演本篇刻意製造的問題。

allowed-tools 的授權效果也應分開記錄。某個技能選用成功，不代表它所有後續工具都可以無限制使用；也不能因為只列了幾個工具，就承諾其他操作永久無法發生。若工作需要嚴格工具限制，應配合專案權限實驗設計驗證。

完成判準與小練習

交付三種模式的設定、啟動矩陣、來源紀錄與選定模式的理由。你應能指出「未選用」「選用了但答錯」「資訊不足所以停止」三種不同結果，不能全部寫成 Skill 失敗。最後以回歸測試保存這些情境。

小練習是替資料參考加一個排除情境，例如只修改文件文案時不需要完整資料契約。用一個相關任務和一個無關任務檢查描述是否清楚。完成後保留你實際要使用的模式，並在 README 說明讀者應從自然語言、斜線指令或背景參考中的哪一個入口開始。

回 Claude Code 教學總目錄

• AI 工具
• 教學
• Claude Code