前言

Spec Kit 跑完一輪之後，我開始想一件事：如果有些流程我想自己定義，而不是直接照它的預設做，該怎麼把這些做法交給 Claude？

這時候就會碰到 Command 和 Skill。

看起來只是兩種不同的「指令」，但實際開始用之後，才發現它們跟 Claude Code 怎麼載入 Context、什麼時候執行，以及誰可以決定執行，都有關係。

所以今天先不急著寫自己的 SOP，先把 Command、Skill 到底是什麼，以及它們在 Claude Code 裡怎麼運作搞清楚。

昨天說到

昨天跑完 Spec Kit 之後，最後得到一個很實際的結論：真正的問題不是「要不要用 Spec Kit」，而是哪些流程適合直接沿用，哪些流程我想換成自己的做法。

例如 taskstoissues、clarify、checklist，都是我想自己定義的部分。

但在開始改之前，得先了解三件事，才有辦法把自己的 SOP 真正放進 Claude Code。：

• Command 和 Skill 到底差在哪裡？
• 這些檔案應該放在哪裡？
• Claude Code 又是在什麼時候把它們載入進來？

Command 與 Skill 是什麼？

Command
把原本每次都要重新告訴 Claude 的 Prompt，存成一個可以重複使用的指令。

例如，平常可能會重複跟 Claude 說：幫我檢查這份 Spec 有沒有缺少驗收條件、資料欄位和 API 契約是否一致，最後列出需要補強的地方。如果每次都要重新打一遍滿麻煩，而且容易忘記某個步驟，這時候就可以把這個指令存成 Command：

.claude/commands/spec-check.md

之後就可以透過：

/spec-check

請 Claude 執行一段預先寫好的指令。

Skill
一個可以被 Claude 使用的「工作方法」；它不一定只是「叫 Claude 做一件事」，也可以是一套讓 Claude 在特定情境下遵循的知識與流程。它的基本結構是：

.claude/skills/<名字>/SKILL.md

SKILL.md 裡面除了可以放 Prompt，也可以描述：

• 這個 Skill 是做什麼的
• 什麼情況下應該使用
• 使用者可以傳入什麼參數
• 可以使用哪些工具
• 執行時要遵守哪些步驟

那 Command 和 Skill 到底是什麼關係？

以前可以把它們想成兩種東西：

Command
└── .claude/commands/foo.md
    → 使用者輸入 /foo

Skill
└── .claude/skills/foo/SKILL.md
    → 一個可以被 Claude 使用的能力

現在的 Claude Code 裡，這兩者已經整合到 Skill 的機制裡。

Skill 可以怎麼被觸發？

有兩種設定，決定 skill 的觸發方式：

如果我希望它是一個人工觸發的檢查關卡，這時就可以設定：

name: spec-check
description: 檢查一份規格是否可以交付開發
disable-model-invocation: true

如果我希望 Claude 在需要時自己載入(像是「命名規則」或「錯誤碼對照表」)，這時就可以設定：

user-invocable: false

實作：/spec-check

我選的第一支 Skil: /spec-check。

---
name: spec-check
description: 檢查一份規格是否可以交付開發，輸出缺口報告
argument-hint: "[規格目錄，例如 specs/001-email-password-login]"
disable-model-invocation: true
allowed-tools: Read, Glob, Grep
---

內文分五段檢查：

產出的報告怎麼分級？

我讓報告分成兩級：

• 必補（擋交付）
• 建議補強（不擋）

判定原則也盡量簡單：

規格未明寫，而且會影響業務行為 → 必補。

跑起來：9 項必補

SKILL.md 的內容完成後，就可以透過 / 呼叫這個指令。

/spec-check specs/001-email-password-login

跑完之後找出 9 項必補、13 項建議補強，我挑了兩個例子來看。

第一種：兩份文件各自都對，但放在一起就矛盾了

例如：規格裡寫了一條：使用者輸入 Email 時，可以忽略前後空白，但另一份 API 契約裡，Email 欄位設定成 format: email。這兩件事情單獨看都很合理，問題是真的把它們接起來之後，才會發現兩者互相衝突。

第二種：我明明改掉了，結果另一個設定又把它改回來

D07 的時候，我發現「帳號連錯三次就鎖定」有安全上的問題，所以改成：帳號 + 來源一起計算，但這次 spec-check 檢查又抓到一個問題：如果反向代理的可信來源沒有設定好，系統最後拿來計算的來源，可能會變成代理 IP。也就是說，我原本想避免的「帳號層級鎖定」，在某些設定下又繞了一圈回來了。

這也是 Spec-Driven 很容易被忽略的一件事：不是只有把需求寫清楚，而是要確認前後每一層真的接得起來。

小結

• Command 和 Skill 現在已經整合到同一套 Skill 機制裡。
• Skill 是一套可以重複使用的工作方法：可以是使用者主動叫的指令，也可以是 Claude 在需要時自行載入的知識與流程。
• 第一支自己做的 Skill 是 /spec-check。它實際抓出了 9 項必補、13 項建議補強。

明天： 今天的 /spec-check 已經可以幫我檢查規格，但它還是只能「告訴我哪裡有問題」。如果我想讓某些規則變成真正的執行關卡，而不是期待 Claude 自己記得遵守，就需要再往下一層：Hook。