$ARGUMENTS 這個變數，跟具名參數（例如 $issue、$branch）該怎麼選？
差別在於指令需不需要接收多個、且各自有明確用途的輸入。如果指令只需要接收一整段文字整體帶入（例如「部署到哪個環境」），$ARGUMENTS 直接把你輸入指令名稱後面的全部內容原封不動塞進去，寫法最簡單。
如果指令需要同時接收好幾個各自不同用途的參數（例如「把某個元件從某個語言遷移到另一個語言」，同時需要元件名稱、原語言、目標語言三個資訊），用具名參數更清楚——在 frontmatter 的 arguments 欄位列出參數名稱，內容裡用 $名稱 分別取用，例如 arguments: [component, from, to] 搭配內文的 $component、$from、$to，執行 /migrate SearchBar JavaScript TypeScript 時，三個名稱會依序對應到三個輸入值，比全部塞進一個 $ARGUMENTS 再要求 Claude 自己去拆解，可靠得多。
如果我的指令需要用到多行指令（不只是單一一行 shell 指令），該怎麼寫？
單行的動態情境注入用行首的 ! 語法（注意反引號的位置，且 指令! 必須出現在行首或緊接在空白字元後面，否則會被當成純文字，指令不會被執行）。如果需要一次跑好幾行指令，改用三個反引號加驚嘆號開頭的區塊語法：
## Environment
node --version
git status --short
```</code></pre><p>這種區塊寫法能一次把多行指令的輸出都注入進去，適合需要同時查詢好幾項環境資訊的情境，不需要把每一行都拆成獨立的 <code>!` `</code> 語句。
指令寫好、測試也成功了，但過一陣子改了 Skill.md 內容，需要重新啟動 Claude Code 才會生效嗎？
不需要，如果是編輯個人層級或專案層級 .claude/skills/ 底下既有的指令內容，Claude Code 會在目前這個 session 裡即時偵測到變更並套用，不用重開。這個即時偵測涵蓋新增、修改、刪除指令目錄底下的內容。
有一種情況例外：如果你是在 session 已經開始之後，才第一次新建一個原本不存在的頂層技能目錄（例如你的專案原本沒有 .claude/skills/ 這個資料夾，session 開始後才手動建立），這種情況下 Claude Code 需要重新啟動才能開始監看這個新出現的目錄——因為即時偵測機制本身，是針對 session 啟動時就已存在的目錄去監看的。
團隊裡其他人也想用我寫的這個指令，該怎麼分享給他們？
取決於這個指令要分享的範圍。如果是想讓同一個專案的所有協作者都能用，最直接的做法是把 .claude/skills/summarize-changes/ 這個資料夾提交進版本控制（例如加進 Git repo），這樣任何人 clone 這個專案後，指令就會自動生效，不需要額外安裝步驟——這也是這類指令官方建議的專案層級分享方式之一。
如果想要更大範圍的分享，例如讓不只一個專案、而是整個團隊或組織的人都能用同一組指令，可以考慮包裝成 Plugin，或是透過組織層級的管理設定統一部署。單一指令的分享用提交進版本控制就已經足夠，只有在指令數量變多、需要跨多個專案重複使用時，才值得花額外力氣做成更正式的發布形式。
如果你搜尋「Claude Code 自訂 slash command 怎麼寫」，會找到不少教學，但其中一部分寫的是 /project:command_name 這種帶命名空間前綴的舊語法——這在目前的官方文件裡已經不是建議做法。這篇直接用官方目前最新的標準走一遍完整流程：從建立目錄、寫檔案，到實際測試，並在容易踩雷的地方特別標註出來。
與其寫一個抽象的「Hello World」範例，這裡直接做一個實用的：一個能總結目前 Git 專案裡尚未提交的變更、並標出潛在風險的指令。這個情境刻意選得比純文字指令再複雜一點，好讓你同時看到「動態帶入即時資料」這個進階技巧怎麼運作。
官方目前的標準做法，是把指令寫成 Skill 目錄結構，而不是單一 .claude/commands/ 檔案（後者仍然可以運作，但不是目前建議的新寫法）。如果你想讓這個指令只在目前這個專案裡可以用，建立專案層級的目錄：
mkdir -p .claude/skills/summarize-changes如果想讓它在你所有專案裡都能用，改成放在個人層級：
mkdir -p ~/.claude/skills/summarize-changes目錄名稱本身就會變成你之後輸入的指令名稱，所以資料夾叫 summarize-changes，之後就是打 /summarize-changes 來觸發。在這個目錄裡建立 SKILL.md，內容分成兩部分：最上方用 --- 包起來的 YAML Frontmatter，告訴 Claude 什麼時候該用這個指令；下方是實際的操作指示。
---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---
Current changes
!git diff HEAD
Instructions
Summarize the changes above in two or three bullet points, then list any risks you notice such as missing error handling, hardcoded values, or tests that need updating. If the diff is empty, say there are no uncommitted changes.
這裡值得特別解釋的是 ! 這一行——這是動態情境注入語法，Claude Code 會先在背景執行這段指令，把實際輸出結果替換掉這一行，Claude 讀到的是「已經包含當下真實 diff 內容」的完整提示詞，而不是一句需要自己想辦法查證的空話。這也是自訂指令跟純文字提示詞的關鍵差異：指令可以先幫你把即時資料查好，再把資料連同任務一起交給 Claude。git diff HEAD
在一個有 Git 的專案裡，隨便改動一個檔案，啟動 Claude Code，然後可以用兩種方式測試：直接輸入符合 description 描述情境的問題，例如「我改了什麼？」，讓 Claude 自動判斷要不要載入這個指令；或是直接手動觸發：
/summarize-changes兩種方式都應該讓 Claude 給出一段簡短的變更摘要，加上幾點風險提示。
如果你參考的是比較舊的教學文章，很可能會看到範例寫成 /project:command_name 或 /user:command_name 這種帶命名空間前綴的觸發方式。這是舊版系統的寫法，目前官方文件裡的範例已經統一成直接 /command-name，不需要額外加前綴——如果你照抄舊教學打了帶前綴的指令卻沒有反應，這通常就是原因。判斷一篇教學是否夠新的其中一個簡單線索：看它示範觸發指令的寫法裡有沒有出現這種前綴。
如果你接下來想寫的指令涉及有實際後果的操作（例如部署、發送訊息），在 frontmatter 裡加上 disable-model-invocation: true，能確保這個指令只有你自己手動輸入才會執行，Claude 不會因為判斷「時機看起來成熟」就自己觸發它：
---
name: deploy
description: Deploy the application to production
disable-model-invocation: true
Deploy $ARGUMENTS to production:
- Run the test suite
- Build the application
- Push to the deployment target
- Verify the deployment succeeded
這裡的 $ARGUMENTS 會被你輸入指令時附帶的參數取代——例如打 /deploy staging，Claude 收到的就是「Deploy staging to production」。
第一個指令寫完之後，下次遇到「同一段提示詞我已經貼過三次」的情況，就是該把它寫成指令的訊號。開始動手前，先問自己兩個問題：這個工作流需不需要動態帶入即時資料（決定要不要用 ! 語法）、這個工作流有沒有實際副作用（決定要不要加上 disable-model-invocation: true）。想清楚這兩點，再對照官方目前的語法動手寫，比照抄一篇不確定新舊的教學更可靠。