Claude Code 自訂指令：將常用流程寫成一個 skill

指令名相同，來源未必相同

你見到別人打 /commit、/test 或 /explain，唔代表你部機一定有。佢可能來自自訂 skill 或外掛。先喺 Claude Code 打 / 或 /help，睇當前清單。

內建指令例如 /model、/permissions、/clear 同 /compact，負責控制工具或對話；自訂指令通常係載入一份指示，叫 Claude 按流程工作。後者唔係保證每次同樣執行嘅程式。

1. 由一個真係重複嘅工作開始

例如每次準備更新摘要，都要確認提交範圍、讀差異、揀用戶睇得到嘅改動。可以整理成 /release-notes。

新格式放喺：

.claude/skills/release-notes/SKILL.md

只供自己跨專案用，就放喺 ~/.claude/skills/release-notes/SKILL.md。舊 .claude/commands/release-notes.md 仍受支援；新 skill 方便同時保存範本及參考文件，詳見官方 skills 文件。

2. 寫一份範圍清楚嘅 SKILL.md

---
name: release-notes
description: 按指定 Git 範圍整理用戶更新摘要草稿
disable-model-invocation: true
---

任務參數：$ARGUMENTS

先確認要比較嘅基準同目標，冇提供就列出需要補充嘅資料。
讀提交記錄同實際差異，唔好只從提交主旨猜功能。
按新功能、修正同改善整理；冇內容嘅類別唔使硬湊。
只寫用戶睇得到嘅變化，未確認影響另外列出。
保留來源提交同驗證限制，只出草稿，唔提交、推送或發佈。

disable-model-invocation: true 表示由你主動叫起，適合唔想 Claude 自行啟動嘅流程。佢唔等於限制檔案或網絡存取。

3. 傳參數時，要知道佢只係文字

/release-notes 比較 v1.2.0 同目前 HEAD

先確定 tag 存在。$ARGUMENTS 會帶入指示內容，但唔會自動驗證 Git ref、函數名或者檔案路徑。如果輸入唔明確，流程應該指出缺少資料，唔好搵個「最似」嘅版本代替。

同樣原則適用於解釋函數：要求提供完整路徑同名稱，先核對定義，再追必要呼叫端。唔好將使用者文字直接拼入 shell 指令執行。

4. 試正常、空參數同錯參數

第一次先用一段熟悉嘅提交範圍，逐項核對摘要。再試冇參數、不存在嘅 tag、冇變更，同只包含內部重構嘅範圍，睇會唔會亂作新功能。

請測試 release-notes skill 嘅指示是否清楚。

檢查正常範圍、空參數、不存在嘅版本同冇用戶可見改動四種情況。列出實際執行步驟及結果，指出任何靠猜測補齊嘅位置。

唔修改 Git 歷史、唔發佈內容。需要修正指示時，先指出問題同最小修改。

如果設定 allowed-tools，要理解佢係哪些工具可免逐次批准，唔係完整工具隔離。需要嚴格唯讀時，使用相應權限模式、工具限制或受控環境，唔好只喺範本寫「唯讀」就當成安全保證。

Skills 同 hooks 點分

Skill 係一段可重用工作指示，可以由使用者叫起，亦可按設定由 Claude 選用。Hook 則係指定事件發生時執行嘅處理程序，例如工具呼叫前後檢查。

普通使用者毋須為同一件事疊幾層。先確定單一 skill 做得準，再考慮有冇重複、可由程式固定執行嘅檢查。

團隊共用要一齊維護

專案 skill 要跟團隊現有規矩，唔寫死個人機器路徑或未確認指令。通用測試流程先讀專案設定，唔好每個 repo 都直接跑 pnpm test。

同名舊 command 同新 skill 唔好兩份並存。搬遷後實際叫一次，核對來源；description 寫清楚用途，刪除過時內容。少量常用、可信嘅指令，比一長串無人記得用途嘅捷徑更實用。