自訂 Slash Commands 與 Skills

Custom Slash Commands 與 Skills 這個主題位於 CCA-F Domain 3（Claude Code 設定與工作流程，佔考試 20% 比重）之下，對應任務說明 3.2——「建立並設定 custom slash commands 與 skills」。與 CLAUDE.md 階層（3.1）和路徑特定規則（3.3）並列，Custom Slash Commands 與 Skills 是決定一套 Claude Code 安裝能否作為有紀律的團隊工具、還是淪為各行其是的實驗場的三大支柱之一。社群通過考試的報告（來自 Kishor Kukreja、Rick Hightower，以及 Tutorials Dojo CCA-F 學習指南）一致指出，Domain 3 是讓考生意外的領域——大多數人過度準備 Domain 1 的 agentic 架構，卻對讓 Code Generation with Claude Code 情境得以作答的 Claude Code 設定機制準備不足。

這份學習筆記完整涵蓋 CCA-F 考生必須認識的 Custom Slash Commands 與 Skills 面向：.claude/commands/ 的專案範疇指令 vs ~/.claude/commands/ 的使用者範疇指令的目錄配置；.claude/skills/ 中以 SKILL.md frontmatter 欄位 context: fork、allowed-tools、argument-hint 定義的 skill 格式；context: fork 的隔離語義，防止 skill 輸出污染主要對話；allowed-tools 限制 skill 執行期間可使用工具的安全姿態；argument-hint 提示開發者補充必要參數的使用者體驗；透過 ~/.claude/skills/ 進行個人 skill 客製化而不影響隊友的模式；以及在按需 skills 和常駐 CLAUDE.md 通用規範之間做出選擇的決策準則。所有內容都錨定在 Code Generation with Claude Code 情境上——這是考試從中抽取每場四個情境的六大情境之一。

為什麼 Custom Slash Commands 與 Skills 對 CCA-F Domain 3.2 至關重要

沒有 Custom Slash Commands 與 Skills 的 Claude Code，不過是一個聊天框加上一個工具腰帶。有了 Custom Slash Commands 與 Skills 的 Claude Code，才成為共享的團隊工作框架：開發者只需輸入 /review、/release-notes、/migration-plan，就能觸發一個精心設計的提示，自動引入正確的脈絡、呼叫正確的工具、執行正確的防護措施。由於定義存在版本控制的儲存庫裡而非各自記在腦中，每位團隊成員都能獲得一致的行為。

從認證的角度來看，任務 3.2 是 Domain 3 中最穩定出題的項目之一，因為考試會描述一個團隊想要把某個工作流程（安全審查、lint-and-fix、changelog 生成、程式碼鷹架）打包起來，然後請考生選出正確的目錄、正確的範疇，以及正確的 frontmatter 欄位。一個把 .claude/commands/ 和 ~/.claude/commands/ 搞混的考生，在每場 Code Generation with Claude Code 考試中至少會在一道計分題上失分。不認識 context: fork 的考生，會誤判 skill 的中間步驟是否污染主要對話紀錄。不了解 allowed-tools 的考生，會設計出可以執行從未授權之破壞性操作的 skills。

Custom Slash Commands 與 Skills 這個主題範圍窄到可以背熟，又深到值得真正理解——這在 CCA-F 中是難得的組合。準備充分，是送分領域；準備草率，是陷阱重重的領域。

內建 Slash Commands vs Custom Slash Commands

在深入研究自訂定義之前，CCA-F 考生應先清楚：Claude Code 本身帶有一組內建 slash commands——/clear、/compact、/cost、/help、/model、/review、/init、/exit 等等。這些指令無須任何設定即可使用，在每套 Claude Code 安裝中行為完全相同。

Custom slash commands 是由使用者或團隊撰寫、以 Markdown 檔案形式存放在磁碟上的指令。當你在 Claude Code 工作階段中輸入 /my-command 時，Claude Code 會在已知目錄集合中解析這個名稱，若找到對應檔案，就將其內容展開為一個提示。展開內容可以包含帶參數的模板、檔案參照，以及結構化的指令。一個寫得好的 custom command，能成為整個團隊都能一致呼叫的可重複、可參數化的提示。

這個區別很重要，因為考試情境常常描述「一個團隊想要把每個人各行其是的工作流程正式化」。正確答案永遠是撰寫一個 custom slash command 或 skill，而不是依賴口頭或書面的規範。

Custom Slash Commands 與 Skills 勝過複製貼上提示的原因

在 custom commands 出現之前，團隊在 Slack、Notion 和 README 檔案裡共享提示。開發者將其貼入 Claude Code，往往帶著過時的脈絡或缺少的參數。Custom commands 讓提示變得可執行、可版本控制、可發現。同樣的邏輯也適用於整個 Custom Slash Commands 與 Skills 功能：這個功能存在的目的，就是讓機構知識能夠在人員入離職和提示演化中存活下來。

專案範疇 vs 使用者範疇：兩個目錄

Custom Slash Commands 與 Skills 中與考試最直接相關的區別，是定義檔放在哪裡。Claude Code 搜尋兩個目錄，各自面向不同的受眾，有著不同的版本控制故事。

專案範疇：.claude/commands/

專案範疇的指令存放在儲存庫根目錄的 .claude/commands/ 目錄中。它們與所操作的程式碼一起加入版本控制。每位 clone 儲存庫的開發者都會取得同一套指令。當主任工程師在 .claude/commands/ 中新增一個 /security-review.md 檔案，每位隊友在下一次 git pull 後就能取得。

在以下情況選擇專案範疇：

• 指令體現了一個團隊慣例（release notes 格式、PR review 檢查清單、migration 規劃）。
• 指令依賴儲存庫特定的路徑、工具或 CI 設定。
• 團隊希望每位開發者——現在和未來——都執行相同的工作流程。

使用者範疇：~/.claude/commands/

使用者範疇的指令存放在開發者家目錄的 ~/.claude/commands/ 中。它們是個人的，永遠不會離開開發者的機器。Git 看不到它們，隊友也看不到它們。

在以下情況選擇使用者範疇：

• 指令是個人的（例如 /my-todo，注入開發者自己的工單模板）。
• 指令反映了一種個人風格，而團隊尚未將其標準化。
• 開發者想在提案給團隊作為慣例之前，先試驗某個工作流程。

解析順序

當開發者輸入 /review 時，Claude Code 先檢查專案目錄，再退而使用使用者目錄。如果同名指令同時存在於兩處，在該儲存庫中專案範疇的定義優先。這讓團隊能以一個官方的專案版本覆蓋開發者的個人偏好，同時讓開發者在其他每個儲存庫中保有個人版本的有效性。

當開發者回報「我加入新專案後，個人的 /review 指令不再按預期執行」時，考試題目就是在測試這個解析順序。正確的診斷是：.claude/commands/ 中的專案範疇 /review 遮蔽了使用者範疇的版本——而不是 Claude Code 出了故障。

/review 指令應該放在哪裡

CCA-F 考試指南的典型考題（情境叢集的第 4 題）問道：一個團隊希望每位開發者在程式碼審查時都執行同一個 /review 指令，定義應該放在哪裡？答案是 .claude/commands/——與儲存庫一起版本控制的專案範疇目錄——而不是 ~/.claude/commands/（僅個人使用），也不是 CLAUDE.md（不是 slash command 機制）。這個模式用不同的指令名稱（/release-notes、/security-audit、/migration）反覆出現，始終指向專案目錄。

Custom Slash Command 檔案的結構

一個 custom slash command 是以指令名稱命名的 Markdown 檔案。/review 存放在 review.md，/release-notes 存放在 release-notes.md。檔案的內容就是 Claude Code 在執行指令時注入的提示。

一個位於 .claude/commands/review.md 的最基本專案範疇 /review 指令可能如下：

---
description: 對已暫存的 diff 執行結構化程式碼審查。
argument-hint: <可選的焦點領域，例如「security」或「performance」>
---

你正在對當前已暫存的變更執行程式碼審查。

焦點領域：$ARGUMENTS

步驟：
1. 使用 `git diff --cached` Bash 工具讀取 diff。
2. 對每個變更的檔案，找出正確性、安全性和效能問題。
3. 產出一份按嚴重程度分組的 Markdown 檢查清單。

頂部的 frontmatter 區塊是可選的，但建議加上。常見的 frontmatter 欄位包括：

• description — 顯示在 /help 輸出中的單行摘要。
• argument-hint — 告訴開發者該指令預期哪些參數的占位文字。
• allowed-tools — 指令執行期間允許使用的工具子集。

內容是一個包含一個特殊模板變數的普通提示：$ARGUMENTS，會展開為開發者在指令名稱後輸入的任何文字。

參數處理與 argument-hint

當開發者輸入 /review security 時，字串 security 被捕捉為 $ARGUMENTS 並替換到提示內容中。如果開發者輸入 /review 而不帶任何參數，$ARGUMENTS 就是空的。這正是 argument-hint 發揮作用的地方——它告訴 Claude Code 以提示文字作為引導，提醒開發者補充缺少的參數，而不是靜默地以空參數執行。

Skills：可重用的提示加工具套件

Slash commands 是按需執行的提示。Skills 是結構化、可重用的工作流程，走得更遠——它們將提示與工具限制、情境隔離語義，以及可選的 subagent 執行綑綁在一起。Skills 存放在 .claude/skills/（專案）或 ~/.claude/skills/（使用者），每個 skill 各有自己的目錄，以 SKILL.md 檔案作為定義。

目錄配置

一個典型的專案範疇 skill 目錄可能如下：

.claude/
  skills/
    migration-planner/
      SKILL.md
      templates/
        migration-template.md
    release-notes/
      SKILL.md
    security-audit/
      SKILL.md
      checklists/
        owasp-top-10.md

每個 skill 是一個自包含的資料夾。SKILL.md 檔案是進入點；支援檔案（模板、檢查清單、參考文件）可以放在它旁邊並在提示中被引用。

SKILL.md 的結構

SKILL.md 檔案分為兩個部分：YAML frontmatter 和提示內容。

---
name: migration-planner
description: 規劃一個帶有回滾檢查點的多步驟資料庫 migration。
context: fork
allowed-tools:
  - Read
  - Write
  - Grep
  - Glob
argument-hint: <來源版本和目標版本，例如「v3 -> v4」>
---

你正在規劃一個從 $ARGUMENTS 的資料庫 migration。

步驟：
1. 使用 Read 和 Grep 清點受影響的資料表。
2. 產出一份包含有序步驟和回滾檢查點的 migration 計劃。
3. 使用 Write 工具將計劃寫入 `docs/migrations/plan.md`。

對 CCA-F 最重要的 frontmatter 欄位是 context: fork、allowed-tools 和 argument-hint。這三個欄位在考試題目中以答案選項、干擾項或情境線索的形式出現。

context: fork — 在隔離的 Sub-Agent 情境中執行 Skills

context: fork frontmatter 欄位是將 skill 與簡單 slash command 區分開來的核心機制。設定後，Claude Code 會產生一個擁有隔離對話情境的 subagent 來執行 skill，然後只將 skill 的最終輸出回傳到主要對話。

隔離的實際含義

沒有 context: fork，skill 的提示和中間步驟會被附加到主要對話中。每次讀取的檔案、每次 Grep 的輸出、每次工具呼叫，以及每次 Claude 的回應，都成為主要對話紀錄的一部分。在長工作流程中，這會污染情境視窗、消耗 token，並引入開發者從未預期的雜訊。

有了 context: fork，skill 在一個情境獨立的 subagent 中執行。subagent 讀取輸入、執行步驟、產出最終摘要。只有那份最終摘要被附加到主要對話。中間的工作被丟棄，保持了主要對話的專注度和情境預算。

何時選擇 Fork

在以下情況選擇 fork：

• skill 執行了大量主要對話不需要的中間檔案讀取。
• skill 執行長時間的探索或分析，最終輸出是一份簡潔的報告。
• skill 可能產生冗長或嘈雜的中間輸出，會干擾後續提示的理解。

在以下情況不要 fork：

• skill 是一個短小的一次性提示，其完整輸出應該在主要對話紀錄中可見。
• 開發者需要繼續在主要對話中互動式地精煉工作成果。

與 Domain 1 Subagents 的關聯

準備 CCA-F Domain 1（Agentic 架構與 Orchestration，佔比 27%）的考生會認出：context: fork 與 agent-teams 文件中 subagent 情境隔離的語義相同。Subagents 不繼承協調者的對話歷史，而 forked skill 也不會將其內部過程洩漏回主要對話。這兩種機制是表親關係：一個在 agent 編排層面，一個在 Claude Code skill 執行層面。

allowed-tools — 限制 Skill 執行期間的工具存取

allowed-tools frontmatter 欄位指定 skill 執行期間允許使用的工具子集。它是一個安全與防護邊界，不是效能最佳化。

為何限制工具

Claude Code 的預設工具集包含 Read、Write、Edit、Bash、Grep、Glob，以及任何 MCP 提供的工具。一個只需要讀取檔案並產出報告的 skill，不應該被允許執行任意 Bash 指令——一個錯誤或提示注入攻擊可能造成損害。一個應該生成 Markdown 檔案的 skill，不應該被允許呼叫 Edit 工具修改原始碼。

allowed-tools 將 skill 的能力範圍縮小到最低必要限度。如果 skill 只需要 Read 和 Write，就只列出 Read 和 Write。如果後來有提示注入嘗試欺騙 skill 執行 rm -rf，由於 Bash 工具不在允許清單中，嘗試就會失敗收場。

範例：安全的報告生成器

---
name: release-notes
description: 從最近 N 個 commit 生成 release notes。
context: fork
allowed-tools:
  - Read
  - Write
argument-hint: <commit 數量，例如 20>
---

這個 skill 可以讀取檔案，並將 release notes 寫入磁碟。它不能執行 Bash、不能編輯原始碼，也不能呼叫網路搜尋。如果開發者後來修改提示並加入 Bash 指令，該工具不在允許清單中，skill 會拒絕執行。

與 Subagent 工具允許清單的關係

同樣地，Domain 1 的讀者會認出 allowed-tools 是 SKILL.md 版本的 subagent 工具允許清單——在「建立 custom subagents」文件中描述的相同原則：將工具範圍縮小到最低必要限度，對清單外的任何嘗試失敗收場。

argument-hint — 必要參數的使用者體驗

argument-hint frontmatter 欄位不強制執行任何規則——它純粹是一個使用者體驗機制。當開發者未帶預期參數就呼叫 skill（或 slash command）時，Claude Code 會顯示提示文字引導輸入。這對於作者不在場解釋用法的共享專案範疇 skills 尤其重要。

常見的格式：

argument-hint: <工單 ID，例如 PROJ-123>
argument-hint: <來源版本和目標版本，例如「v3 -> v4」>
argument-hint: <要審核的檔案 glob 清單，以逗號分隔>

提示會出現在 /help 清單中 skill 名稱旁邊，也會在開發者未帶參數輸入指令時內嵌顯示。沒有提示的話，開發者要麼必須閱讀 SKILL.md 檔案，要麼憑直覺猜測——這兩種都是共享工具應該消除的摩擦。

三個 Frontmatter 欄位的統一心智模型

記憶 CCA-F 測試的三個 frontmatter 欄位的簡明方式：

• context: fork — 隔離：在 subagent 中執行，保持主要情境整潔。
• allowed-tools — 安全：縮小能力範圍，對未列出的工具失敗收場。
• argument-hint — 易用性：告訴開發者應提供什麼參數。

三個維度：隔離、安全、易用性。每個 skill 定義都在這三者之間取得平衡。考試題目通常每題只針對其中一個維度。

透過 ~/.claude/skills/ 進行個人 Skill 客製化

適用於 slash commands 的專案對使用者雙重性，同樣適用於 skills。專案 skills 存放在 .claude/skills/，透過 git 共享。個人 skills 存放在 ~/.claude/skills/，留在開發者的機器上。

不影響隊友地客製化團隊 Skill

一個常見的情境：開發者想要一個帶有自己偏好語氣與結構的 release-notes skill 版本。錯誤的做法是直接編輯專案範疇的 release-notes SKILL.md——那會破壞每位隊友的工作流程。正確的做法是將 skill 複製到 ~/.claude/skills/ 中，並以不同的名稱命名（例如 release-notes-personal），再在那裡進行客製化。

由於兩個目錄是獨立搜尋並以 skill 名稱索引的，個人版本可以與專案版本共存。開發者仍然可以呼叫 /release-notes 取得團隊版本，並呼叫 /release-notes-personal 使用客製化版本。

為什麼不同的名稱很重要

如果個人 skill 使用與專案 skill 相同的名稱，解析順序就會介入——對於所屬的儲存庫，專案版本通常優先，個人版本實際上變成了無法觸及的程式碼。使用不同的名稱可以完全避免遮蔽問題，讓兩個 skills 都可被發現。

三層心智模型

綜合以上，Claude Code 的 Custom Slash Commands 與 Skills 系統運作在三個層次上：

1. 內建指令（/clear、/compact、/help、/review 等）——與 Claude Code 一同出貨，無須設定。
2. 專案範疇指令與 skills（.claude/commands/、.claude/skills/）——透過版本控制與隊友共享。
3. 使用者範疇指令與 skills（~/.claude/commands/、~/.claude/skills/）——個人使用，永遠不離開開發者的機器。

解析遵循一個由緊到寬的梯度：最緊密適用的定義在開發者所在的儲存庫中優先。

Skills vs CLAUDE.md：按需 vs 常駐的區別

任務 3.2（Custom Slash Commands 與 Skills）與任務 3.1（CLAUDE.md 設定）相鄰，考試會測試考生能否區分兩者。能消除歧義的心智模型是：按需呼叫 vs 常駐通用規範。

CLAUDE.md：常駐通用規範

CLAUDE.md 檔案在相關目錄的每次 Claude Code 工作階段開始時自動載入。它們體現的規則應該適用於 Claude 在該儲存庫中所做的一切——程式碼風格、命名慣例、測試要求、架構原則、安全指引。開發者不需要主動選擇；規則始終存在。

CLAUDE.md 適合以下情況：

• 通用程式碼慣例（「使用 4 格縮排」、「每次編輯後執行 npm test」）。
• 架構約束（「永遠不要從 legacy/ 匯入到 core/」）。
• 安全規則（「永遠不要提交 secrets，使用環境變數」）。
• 專案範圍的風格（「PR 標題使用 Conventional Commits」）。

Skills：按需工作流程

Skills 由開發者輸入 /skill-name 明確呼叫。它們體現適用於特定情境的工作流程——程式碼審查、migration、release、稽核。它們不是常駐的；它們是選擇性的。

Skills 適合以下情況：

• 開發者在特定時刻觸發的多步驟工作流程（「起草這週的 release notes」）。
• 開發者在每次呼叫時提供參數的工作流程（「從 v3 migrate 到 v4」）。
• 需要在隔離 subagent 情境中執行的工作流程（context: fork），以保護主要對話。
• 需要工具限制（allowed-tools）而主要對話不應繼承的工作流程。

決定性問題

當情境題問「這應該是 skill 還是 CLAUDE.md 條目？」時，決定性問題是：這個規則應該適用於此儲存庫中 Claude 的每次回應，還是只在開發者明確呼叫時才適用？

• 永遠適用 → CLAUDE.md。
• 只在呼叫時適用 → skill（或 slash command）。

如果你把一個一次性工作流程放進 CLAUDE.md，儲存庫裡的每次 Claude 回應都會繼承這個提示，造成情境膨脹並混淆不相關的互動。如果你把一個通用規範放進 skill，開發者會忘記呼叫它，規範就會被靜默地違反。

白話文解釋 Custom Slash Commands 與 Skills

抽象的設定分類學，一旦錨定在具體的日常情境中，就會變得直觀。以下三個類比涵蓋了 Custom Slash Commands 與 Skills 的完整面貌。

類比一：辦桌廚房——內建餐具、團隊食譜本、師傅的私房本

想像一間共享的辦桌廚房。Claude Code 的內建 slash commands 就是每間廚房都有的標準餐具——菜刀、湯匙、漏勺。它們與廚房一起到位；你不需要另外準備。放在廚房架上、每個上班的廚師都會拿同一本的食譜本，就是 .claude/commands/ 和 .claude/skills/ 中的專案範疇指令與 skills——任何來接班的師傅都能翻同一本食譜，做出相同的菜色，新人第一天就能上手。每位師傅縫在圍裙口袋裡的私房本，就是 ~/.claude/commands/ 和 ~/.claude/skills/——個人技法和小撇步，其他人看不到。如果一個師傅修改了團隊的食譜本，每位隊友都受影響；如果他更新了私房本，只有他自己注意到。

context: fork 這個旗標，就像廚房裡被派去獨立備料台切菜的二廚——負責一道複雜菜色的前置處理，完成後只把整齊的備料端回主站。切菜的殘渣、廚餘、眼淚都留在備料台，不會碰到主站。只有乾淨的備料抵達。allowed-tools 就是「這位學徒可以用削皮刀和切片機，但不能用噴火槍」的規定。argument-hint 就是貼在食譜卡上的提醒：「這道菜需要一種蛋白質——開始之前先選雞肉或豬肉」。

這個類比涵蓋了 Custom Slash Commands 與 Skills 的每個核心概念：內建 vs 團隊 vs 個人、共享 vs 私有、隔離子情境、縮小能力範圍、參數提示。

類比二：圖書館——收藏的程序手冊 vs 閱覽室規則

一間大學圖書館有兩種指示。貼在每面牆上、每間閱覽室裡的是始終存在的規則：保持安靜、不得飲食、書歸原位。這些規則適用於每位訪客的每個時刻，不需要任何人呼叫。那就是 CLAUDE.md。

參考台的索引卡盒裡放的是程序手冊：如何申請館際借閱、如何預約討論室、如何申請文件掃描。這些程序只在訪客走到服務台、明確提出請求時才適用。館員取出正確的卡片，閱讀步驟，執行服務。不同的訪客呼叫不同的程序；大多數訪客根本不呼叫任何程序。那就是 Custom Slash Commands 與 Skills 系統。

如果圖書館試圖把每個程序手冊貼在每間閱覽室的牆上，牆面會密密麻麻到無法閱讀，訪客會不知所措。如果圖書館試圖把「不得飲食」的規則放進索引卡盒——只在被呼叫時適用——訪客就會在善本書閱覽室裡吃便當。規則和程序屬於不同的容器，因為它們有不同的呼叫模式。

這個類比釐清了為什麼考試會懲罰把工作流程塞進 CLAUDE.md（「這樣就一直適用了！」）以及把通用規範放進 skills（「開發者會記得去呼叫的！」）的考生。這兩個容器不可互換。

類比三：工廠的工具箱——共用抽屜、個人抽屜與安全操作間

想像一間共享的電子工廠。每個工作台都有一個共用抽屜固定在上面：所有在這個台上工作的師傅都用同一把烙鐵、同一瓶助焊劑、同一份參考圖紙。那就是 .claude/commands/ 和 .claude/skills/。每位技師也帶著一個個人抽屜從台到台——他自己慣用的鑷子、放大鏡和技巧筆記。那就是 ~/.claude/commands/ 和 ~/.claude/skills/。

某些程序——處理高壓電路——必須在安全操作間進行：一個有獨立電源、獨立通風和獨立工具架的隔離空間。技師進入操作間，完成工作，走出來，在主工作台的白板上寫下摘要。操作間把煙霧和火花隔離在外，不會影響台面的其餘工作。那就是 context: fork——隔離保護主要情境不受 skill 內部過程的干擾。

安全操作間也是 allowed-tools 執行的地方。操作間的工具架只放這個程序安全使用的工具。進入操作間的技師不會帶來整個工廠的工具腰帶——他用操作間提供的工具，或者做不了這個工作。那就是 allowed-tools 縮小能力範圍的安全姿態。argument-hint 就是操作間門口的告示：「進入前，請說明電壓和零件型號」——提示程序所需參數的引導。

考試當天選用哪個類比

• 關於專案 vs 使用者範疇的題目 → 廚房類比（團隊食譜本 vs 私房本）。
• 關於 skills vs CLAUDE.md 的題目 → 圖書館類比（索引卡盒 vs 牆上的告示）。
• 關於 **context: fork 和 allowed-tools**的題目 → 工廠類比（安全操作間與其工具架）。

範疇優先順序與 CLAUDE.md 的互動

Claude Code 的設定系統是階層式的。在一個 Claude Code 工作階段中，可能同時看到內建指令、專案範疇的指令與 skills、使用者範疇的指令與 skills，以及相關的 CLAUDE.md 檔案。理解優先順序對於除錯以及通過考試中詢問「為何觀察到特定行為」的題目都很重要。

Slash Commands 與 Skills 的優先順序

輸入的指令名稱的解析順序為：

1. 當前儲存庫的專案範疇（.claude/commands/、.claude/skills/）。
2. 使用者範疇（~/.claude/commands/、~/.claude/skills/）。
3. 內建（與 Claude Code 一同出貨的指令）。

當一個指令名稱存在於多個位置時，在該儲存庫中專案範疇的版本優先。這讓團隊能在自己的程式碼庫中覆蓋開發者的個人偏好，同時讓個人版本在其他所有儲存庫中仍然有效。

與 CLAUDE.md 的互動

CLAUDE.md 自動載入；skills 和 slash commands 在呼叫時載入。當 skill 執行時，CLAUDE.md 規則仍然有效——除非 skill 使用了 context: fork，在這種情況下，subagent 可能會根據 CLAUDE.md 階層重新載入 CLAUDE.md，並在這些規則下執行 skill，但不繼承主要對話已累積的情境。

CCA-F 相關的細微之處：在 subagent 中執行的 forked skill 不繼承主要對話中途做出的決定、澄清或修正。如果主要對話確立了「永遠使用 YAML，不用 JSON」，而 forked skill 只讀取 CLAUDE.md 和 skill 提示，就不會看到那個對話中途的指令。這與 Domain 1 subagent 題目利用的情境隔離陷阱屬於同一類型。

常見考試陷阱：範疇混淆與 Frontmatter 錯誤

CCA-F 積極利用五種與 Custom Slash Commands 與 Skills 相關的反覆出現陷阱模式。

陷阱一：.claude/commands/ vs ~/.claude/commands/ 對調

答案選項會把目錄路徑對調。考試指南的典型 Q4——「團隊應該把共享的 /review 指令放在哪裡」——正確答案是 .claude/commands/，而 ~/.claude/commands/ 是最高品質的干擾項。粗心看選項的考生會錯過波浪號，選到錯的目錄。仔細閱讀路徑字元：開頭的 . vs ~/. 決定了專案 vs 使用者範疇。

陷阱二：把 CLAUDE.md 當作 Slash Command 的宿主

干擾選項建議「把 /review 的指令放進 CLAUDE.md」。CLAUDE.md 不是 slash command 機制——它是常駐載入的規則檔案。如果工作流程需要按需呼叫（/review），它就必須以 slash command 或 skill 的形式存在，而不是作為 CLAUDE.md 的一個章節。

陷阱三：把 context: fork 誤解為並行執行

有些考生看到「fork」就以為是並行執行。context: fork 是關於情境隔離，不是並行執行。skill 在一個擁有獨立對話的 subagent 中執行，但不一定與主要對話並行。重點是保持主要情境，不是執行得更快。

陷阱四：把 allowed-tools 視為效能設定

干擾選項把 allowed-tools 框架為效能最佳化（「限制工具數量以降低延遲」）。這是錯的。allowed-tools 是能力和安全邊界。它的存在是為了防止 skill——可能受到提示注入或不嚴謹模板的影響——呼叫破壞性工具。對延遲的可觀察影響微乎其微，遠不如安全效果重要。

陷阱五：透過編輯專案 Skill 進行個人客製化

情境：開發者想要一個調整過的團隊 skill 版本。錯誤答案是「編輯專案範疇的 SKILL.md」。那會在版本控制中提交一個影響每位隊友的變更——很可能違反團隊慣例。正確答案是將 skill 複製到 ~/.claude/skills/，使用不同的名稱，並在那裡客製化。

練習錨點：Code Generation with Claude Code 情境

Code Generation with Claude Code 情境是 CCA-F 六大情境叢集之一，每場考試從中抽取四個情境。在這個情境中，Custom Slash Commands 與 Skills 的題目會以五種形態出現。

模板 A：目錄選擇

一個團隊希望每位開發者在推送前都執行標準化的 PR 審查。/review 指令的定義應該放在哪裡？正確答案：儲存庫根目錄的 .claude/commands/review.md，提交到版本控制。干擾項聲稱是 ~/.claude/commands/（僅個人）或 CLAUDE.md（常駐載入，不是按需呼叫）。

模板 B：Frontmatter 用途

一個 skill 定義在其 frontmatter 中包含 context: fork。效果是什麼？正確答案：skill 在隔離的 subagent 情境中執行，只有最終輸出回傳到主要對話。干擾項聲稱是並行執行或工具優先順序——兩者都是錯的。

模板 C：工具限制的原因

一個以安全為重點的 skill 在其 frontmatter 中包含 allowed-tools: [Read, Grep]。為什麼？正確答案：skill 被允許讀取檔案和搜尋模式，但不能修改檔案或執行任意 Bash——這是一個安全邊界，對任何嘗試使用未列出工具的請求失敗收場。干擾項聲稱是效能調整或情境視窗縮減。

模板 D：參數使用者體驗

一個共享的 /migration-planner skill 在其 frontmatter 中有 argument-hint: <來源版本和目標版本，例如「v3 -> v4」>。這達成了什麼效果？正確答案：當開發者不帶參數呼叫指令時，Claude Code 會以提示文字提醒開發者預期的參數格式。干擾項聲稱是參數驗證或預設值指定——這兩者都不是 argument-hint 的功能。

模板 E：Skill vs CLAUDE.md 的放置選擇

一個團隊希望 Claude 對儲存庫中的每次互動使用特定的 commit message 格式。這應該放在 skill 中還是 CLAUDE.md 中？正確答案：CLAUDE.md——規則應該永遠適用，而不是只在被呼叫時適用。干擾項聲稱 skill 更好，因為「skills 可以使用 context: fork」——這無關緊要，因為規則需要常駐載入。

關鍵術語與數字備忘

Custom Slash Commands 與 Skills 引入了一個小而易記的詞彙表。熟記這些術語，在考試當天能直接回收報酬。

區別說明：CCA-F 的識別深度 vs 生產建構深度

CCA-F 定位為具備 6 個月以上 Claude 使用經驗的解決方案架構師的基礎認證。它測試對 Custom Slash Commands 與 Skills 的識別與判斷——你能識別正確的目錄嗎？能說出 frontmatter 欄位嗎？能解釋其用途嗎？能將情境與正確的容器配對嗎？更高層次的認證，或實際的生產部署，會進一步要求你從頭撰寫 SKILL.md 檔案、調整 allowed-tools 中的 MCP 工具整合、除錯 skill 執行追蹤，以及設計全團隊的 skill 函式庫。

CCA-F 對你的期望

• 識別 .claude/commands/（專案）vs ~/.claude/commands/（使用者），以及 skills 的同等二元性。
• 說出三個 SKILL.md frontmatter 欄位（context: fork、allowed-tools、argument-hint）並描述每個欄位的功能。
• 使用常駐 vs 按需的判斷準則，將情境配對到 skill 或 CLAUDE.md 容器。
• 識別考試指南樣本中的 /review 目錄陷阱。
• 解釋透過 ~/.claude/skills/ 以不同名稱進行個人 skill 客製化的方式。

CCA-F 不期望你做到的事

• 從頭撰寫包含完整提示內容和工具編排的生產 SKILL.md 檔案。
• 將 skill 與即時 MCP 伺服器整合。
• 在協議層面除錯 skill 執行追蹤或 fork 情境隔離失敗。
• 設計帶有 skills 之間依賴關係圖的團隊 skill 函式庫。

如果你發現自己在生產環境中實作 skills，你已經從識別深度進入了建構深度——這很有價值，但超出了 CCA-F 題目所衡量的範圍。

Custom Slash Commands 與 Skills 常見問題（FAQ）

CCA-F 中 .claude/commands/ 和 ~/.claude/commands/ 有什麼區別？

.claude/commands/ 是儲存庫根目錄的專案範疇目錄，與程式碼一起版本控制。每位 clone 此儲存庫的開發者都會取得同一套 slash commands——它是團隊共享的容器。~/.claude/commands/ 是開發者家目錄的使用者範疇目錄，永遠不會提交到 git。它是個人的——只有那位開發者能看到那些指令。CCA-F 考試指南的典型 Q4 就是在測試這個精確的區別：全團隊的 /review 指令應屬於 .claude/commands/（專案），而不是 ~/.claude/commands/（個人）。同樣的專案對使用者二元性也適用於 skills（.claude/skills/ vs ~/.claude/skills/）。

SKILL.md frontmatter 中的 context: fork 有什麼作用？

context: fork 指示 Claude Code 在隔離的 subagent 情境中執行 skill。subagent 在自己的對話中執行 skill 的步驟——檔案讀取、工具呼叫、中間推理——而只有最終輸出回傳到主要對話。這防止了 skill 的內部過程污染主要情境視窗，並保持了開發者的 token 預算。一個常見的使用場景：一個需要讀取數十個檔案的長時間分析 skill 應該 fork，這樣中間的 Read 輸出就不會在主要對話紀錄中累積。當開發者期望在主要對話中內嵌看到中間工作以進行互動式精煉時，則不要 fork。

為什麼我應該在 skill 定義中使用 allowed-tools？

allowed-tools 縮小了 skill 在執行期間被允許使用的工具範圍。它是一個安全和能力邊界，不是效能設定。一個報告生成 skill 可能宣告 allowed-tools: [Read, Write]，這樣它就能讀取原始碼檔案並寫入報告，但無法執行 Bash 或編輯原始碼。如果提示注入或不嚴謹的模板試圖欺騙 skill 執行破壞性指令，由於該工具不在允許清單中，嘗試就會失敗收場。同樣的邏輯適用於整個 CCA-F 課綱——subagents 同樣出於相同的安全原因使用工具允許清單。

何時應該使用 skill 而不是 CLAUDE.md 條目？

將 CLAUDE.md 用於常駐通用規範，它們適用於儲存庫中每次 Claude Code 互動——程式碼風格、命名慣例、測試要求、安全規則、架構約束。將 skill（或 slash command）用於開發者在特定時刻觸發的按需工作流程——程式碼審查、migration、release notes、稽核。決定性問題是：這個規則應該適用於此儲存庫中 Claude 的每次回應，還是只在被明確呼叫時才適用？「永遠適用」→ CLAUDE.md。「只在被呼叫時適用」→ skill。把按需工作流程放進 CLAUDE.md，會在每次工作階段膨脹情境；把通用規範放進 skills，意味著開發者會忘記呼叫它們。

如何在不影響隊友的情況下客製化團隊 skill？

將 skill 複製到使用者範疇目錄 ~/.claude/skills/，使用不同的名稱（例如附加 -personal 或你的縮寫）。在那個個人副本上進行客製化。原始團隊 skill 留在 .claude/skills/，繼續為每位隊友正常工作；你的個人版本則在你呼叫個人名稱時執行。永遠不要直接在專案範疇的 SKILL.md 上進行編輯——那個 commit 會影響每位隊友，很可能違反團隊慣例。也不要在使用者目錄中使用與專案 skill 相同的名稱——在該儲存庫中，專案版本會遮蔽它，個人版本會悄悄地失去作用。

argument-hint 確切做了什麼？

argument-hint 是一個使用者體驗機制。當開發者未帶預期參數就呼叫指令或 skill 時，Claude Code 會顯示提示文字，說明預期的參數是什麼。例如，argument-hint: <工單 ID，例如 PROJ-123> 告訴開發者該指令需要一個那種格式的工單識別碼。提示也會出現在 /help 清單中指令名稱旁邊。argument-hint 不驗證參數、不強制執行格式，也不提供預設值——它純粹是在提示開發者輸入。對於共享的專案範疇指令，一個好的 argument-hint 能防止「呼叫了，什麼也沒發生」這種在沒有說明的指令中常見的困惑。

Skills 和 slash commands 是否繼承 CLAUDE.md 規則？

非 forked 的 skills 和 slash commands 在主要對話的情境中執行，因此自然繼承所有 CLAUDE.md 規則——CLAUDE.md 在工作階段開始時就已載入。Forked skills（context: fork）在 subagent 中執行；那個 subagent 根據 CLAUDE.md 階層重新載入 CLAUDE.md，但不繼承主要對話中的對話中途指令。如果主要對話在一番來回中確立了「只使用 YAML」，一個 forked skill 可能看不到這個指令——它只看到 CLAUDE.md 和 skill 提示。這與 Domain 1 subagents 暴露的隔離語義相同，在考試中以情境流程陷阱的形式出現。

為了應對這個問題，請將耐久的團隊規範放進 CLAUDE.md（在那裡，forked subagents 能夠看到它們），而不是依賴 subagents 無法繼承的對話中途澄清。

延伸閱讀

• Claude Certified Architect Foundations Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Custom slash commands and skills — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/slash-commands
• CLAUDE.md configuration — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Claude Code features overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Claude Code settings reference: https://docs.anthropic.com/en/docs/claude-code/settings
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents

Related ExamHub topics: CLAUDE.md Hierarchy and Scoping, Path-Specific Rules and Conditional Loading, Plan Mode vs Direct Execution, Claude Code CI/CD Integration, Subagents and Agent Teams.