既有的 .claude/commands/ 檔案，需要手動全部改寫成 Skill 目錄結構嗎？
不需要。官方文件明確說明既有的 .claude/commands/ 檔案會繼續正常運作，不會因為系統合併就失效——這不是一個強迫遷移的變更，只是官方把 Skill 目錄列為「新自動化」的建議做法。如果你手上一份簡單的單一指令運作良好、也不需要額外的腳本或參考資料，完全沒有必要為了跟上新做法而特地重寫。
比較合理的做法是漸進式的：新增工作流時優先考慮用 Skill 目錄（尤其如果你預期未來可能需要擴充腳本或參考資料），既有的簡單 Command 檔案則等到真的需要擴充功能、或剛好要重構那部分邏輯時，再一併遷移過去，不需要為了遷移而遷移。
如果我想讓一個 Skill 只能由我手動觸發，不想讓 Claude 自己判斷情境去載入它，具體該怎麼設定？
在該 Skill 的 SKILL.md frontmatter 裡加上 disable-model-invocation: true 這個欄位。設定後，這個 Skill 的描述不會被放進 Claude 判斷是否要載入的上下文裡，Claude 完全不會自己觸發它，只有你手動輸入 /名稱 才會執行。官方文件特別點名這適合用在有副作用、或你想自己控制時機的工作流上，例如部署、發送訊息這類「不希望 Claude 覺得時機成熟就自己動手」的操作。
這個欄位獨立於你選擇單一檔案 Command 還是 Skill 目錄結構，換句話說，即使你把工作流寫成完整的 Skill 目錄（帶有腳本、參考資料），一樣可以加上這個欄位讓它維持手動觸發——觸發方式的選擇，跟你用哪種檔案結構完全是兩件事。
內建的 /simplify、/batch 這類指令，也是這次併入 Skill 系統的一部分嗎？
是相關但不完全相同的機制。官方文件把 /doctor、/code-review、/batch、/debug、/loop 這類指令歸類為「Bundled Skills（內建 Skill）」，特性是「prompt-based」——也就是給 Claude 一份詳細的操作腳本，讓它運用手上的工具自己去執行，這跟你自己在 .claude/skills/ 底下寫的自訂 Skill，運作原理是相通的。這跟 /help、/compact 這類直接執行固定邏輯、不涉及 Claude 推理判斷的內建指令，是兩種不同的東西。
對使用者來說，觸發方式沒有差別，一樣都是打 / 加上名稱；差別在於背後的運作邏輯——內建 Skill 是 Claude 依照給定的腳本去思考、去用工具完成任務，純邏輯型內建指令則是直接執行寫死的程式行為，不涉及模型推理。想關掉所有內建 Skill，可以用 disableBundledSkills 這個設定，但 /doctor 即使關閉這個設定依然保持可輸入。
這個系統合併是什麼時候發生的？我需要確認自己的 Claude Code 版本是否已經支援嗎？
社群整理的文章裡有提到，這個統一是在版本 2.1.3 引入的——在那之前，Command 跟 Skill 是兩套完全獨立的系統，個別開發、個別維護，也是舊教學文章裡「兩者行為天生不同」這個說法的由來。如果你使用的是這之後的版本，兩套系統已經統一運作，不需要額外設定或啟用。
比較保險的確認方式，是直接查你目前使用的版本號（在 Claude Code 裡通常可以用查看版本的指令確認），如果版本明顯早於這個時間點、或者你不確定，先執行更新指令再測試會比較保險——考慮到 Claude Code 的更新頻率相當高，多數目前在使用的人應該早已跑在合併後的版本上，但如果你的環境很長一段時間沒更新過，還是值得花十秒鐘確認一下版本，而不是假設自己一定是最新的。
如果你最近搜尋「Claude Code 的 Command 跟 Skill 有什麼差別」，很可能會看到一批文章不約而同給出同一個答案：Command 是你手動打 /command 才會執行，Skill 是 Claude 自己判斷情境後主動載入，兩者的核心差異在於「誰按下觸發鍵」。這個說法在幾個月前是對的，但官方文件現在的措辭已經不一樣了。
Claude Code 現行文件在說明 Skill 系統時，用了一句非常直白的話：「自訂指令已經併入 Skill 系統（Custom commands have been merged into skills）」。具體來說，一份放在 .claude/commands/deploy.md 的檔案，跟一份放在 .claude/skills/deploy/SKILL.md 的 Skill，兩者都會建立同一個 /deploy 指令，運作方式完全相同——舊有的 .claude/commands/ 檔案依然可以正常運作，不會因為系統合併就失效，但官方現在把 Skill 目錄列為新自動化的建議做法。
過去被拿來當作核心分野的「手動觸發 vs 自動觸發」，現在其實兩種寫法都能做到——差別不再是「Command 只能手動、Skill 只能自動」，而是 Skill 的 frontmatter 提供了明確的開關可以控制這件事。設定 disable-model-invocation: true，這個 Skill 就只能由你手動輸入 /名稱 觸發，Claude 不會自己判斷情境去載入它——這正好對應舊教學裡「Command 的特性」；反過來，不設定這個欄位（預設值），Claude 就能依照 description 欄位自動判斷是否要載入，也可以由你手動觸發，兩種觸發方式同時存在，不是互斥的兩個系統各自綁死一種行為。
既然觸發機制已經不再是分野，現在兩者的差異落在檔案結構本身：.claude/commands/ 底下是單一 Markdown 檔案，適合邏輯單純、不需要額外資源的短工作流；.claude/skills/<name>/ 則是一個目錄，除了核心的 SKILL.md，還能放 scripts/（可執行腳本）、references/（延伸參考資料，只在真正需要時才載入）等支援檔案。當一個工作流複雜到需要額外的腳本或大量參考資料時，Skill 目錄結構能把這些內容拆開管理，不必全部塞進同一份檔案裡；如果只是一句常用的固定指令，單一檔案的 Command 寫法依然完全夠用，官方也沒有要求你把既有的簡單指令都遷移過去。
另一個實務上值得知道的細節：如果 .claude/commands/deploy.md 跟 .claude/skills/deploy/SKILL.md 同時存在，官方文件明確說明由 Skill 版本勝出——/deploy 執行的會是 Skill 目錄裡定義的內容。這代表如果你正在逐步把舊的 Command 遷移成 Skill，遷移過程中兩份檔案短暫並存也不會出錯，新版本會自然接手，不需要先手動刪掉舊檔案才能讓新版生效。
這不是一個無傷大雅的措辭差異。如果你根據舊版區分法去設計團隊的自動化工作流——例如認定「這個工作流需要自動觸發，所以一定要寫成 Skill；那個工作流只想手動控制，所以一定要寫成 Command」——你可能會因此把簡單、其實適合單一檔案的邏輯，硬是拆成複雜的目錄結構，或是誤以為 Command 寫法完全無法讓 Claude 自動判斷情境，因而放棄了原本就能達成的自動化。判斷該用哪種寫法的正確依據，現在是「這個工作流的複雜度，需不需要額外的支援檔案」，而不是「我想要它自動觸發還是手動觸發」。
下次要新增一個工作流之前，先問結構性的問題：這個工作流除了一段指令文字，還需不需要搭配腳本、範本或大量參考資料？需要的話用 Skill 目錄，把核心邏輯放進 SKILL.md，延伸內容拆到 scripts/ 或 references/；不需要的話單一檔案的 Command 寫法完全夠用，不必為了「聽說 Skill 比較新、比較推薦」就把簡單邏輯過度工程化。至於要不要讓 Claude 自動觸發，那是 disable-model-invocation 這個獨立開關該處理的事，跟你選哪種檔案結構無關。