Skill 模式跟最佳實踐

常見模式、反模式、跟厲害的 skill 建造者的習慣

⏱ 預估 ~8 分鐘

01 · 讀一讀

現在你知道 skill 怎麼運作，我們來看開發者每天實際在用的模式。

最受歡迎的 skill 落在幾個類別：- 程式風格 — 執行命名慣例、格式規則、結構模式 - 程式碼審查 — 審 PR 跟程式變動的一致清單 - Commit 訊息 — 執行像 Conventional Commits 的格式 - 測試 — 符合你專案的測試框架跟模式 - 文件 — 標準化文件、註解、README 怎麼寫

每個模式遵守同樣結構：清楚規則、具體範例、明確輸出格式。我們看兩個最有用的。

重點整理

程式風格 skill 執行命名、格式、結構慣例
審查 skill 提供一致的程式碼審查清單
Commit 訊息 skill 執行像 Conventional Commits 的格式
測試 skill 符合你專案現有的測試模式
文件 skill 標準化文件怎麼寫

02 · 看程式碼

下面是執行所有 commit 訊息用 Conventional Commits 格式的 skill。

commit-style/SKILL.md

---
name: Commit Message Style
description: Enforces Conventional Commits format
instructions: Use when creating git commits
---

## Format

All commits must follow Conventional Commits:

```
<type>(<scope>): <description>

[optional body]
```

## Types

- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `refactor`: Code change that neither fixes nor adds
- `test`: Adding or updating tests
- `chore`: Maintenance (dependencies, CI, build)

## Rules

- Description must be lowercase, no period at the end
- Scope is optional but encouraged
- Body should explain WHY, not WHAT (the diff shows what)
- Max 72 characters for the first line

## Examples

Good: `feat(auth): add password reset flow`
Good: `fix(api): handle null response from payment gateway`
Bad: `Fixed stuff`
Bad: `Update code`

看這多明確 — 確切格式、列舉的類型、字元上限、好跟壞的範例。你規則越明確、Claude 的 commit 越一致。「寫好 commit 訊息」這種含糊指令沒用。

03 · 看程式碼

下面是叫 Claude 符合你專案現有測試慣例的 skill。

test-writer/SKILL.md

---
name: Test Writer
description: Writes tests matching project conventions
instructions: Use when writing or updating tests
---

## Conventions

- Use `describe` / `it` blocks (not `test`)
- Test file goes next to source: `Foo.ts` → `Foo.test.ts`
- Use `vi.fn()` for mocks (Vitest, not Jest)
- Arrange-Act-Assert pattern in every test

## What To Test

- Happy path first
- Error cases and edge cases
- Boundary values (0, 1, -1, empty string, null)
- Never test implementation details — test behavior

## Naming

`it('should return 404 when user not found')`
Not: `it('test user')`

這 skill 引用專案的特定測試框架（Vitest）跟模式（describe/it、vi.fn）。通用的「寫好測試」指令沒用 — Claude 本來就在試寫好測試。這個 skill 告訴它你的特定慣例。

04 · 選擇題

記住：skill 應該加 Claude 自己不會知道的規則。下面哪個指令夠明確、真的能改變 Claude 的行為？

當寫好程式碼的有用助理
寫 API endpoint 時，回 camelCase key 的 JSON、用 kebab-case URL、用我們 error-codes.ts 檔的錯誤碼
寫程式時永遠用最佳實踐
像資深工程師那樣寫程式

05 · 分類拖拉

想什麼對 skill 品質差別最大。沒範例的含糊 skill 比具體的差 — 把這些實踐從影響最大到最小排序。

(本節為互動練習，請啟用 JavaScript 體驗)

06 · 讀一讀

有些 skill 反而讓 Claude 變差。下面是要避免的：太含糊：「寫好、乾淨的程式碼。」Claude 本來就在試。你的 skill 應該加 Claude 自己不會知道的具體規則。

太長：一個 500 行、為每個可能情境寫規則的 skill，壓垮 Claude 的上下文。讓 skill 專注於一個流程。多個專注的 skill 打敗一個超大的。

重複內建行為： Claude 已經會格式化程式碼、寫 markdown、用 git。不要把 skill 空間浪費在 Claude 預設做得好的事。

矛盾規則：「永遠加註解」+「保持程式碼最少」造成混亂。測試前檢查你的規則內部有沒有衝突。

重點整理

不要寫含糊 skill — 明確或不要寫
不要寫超大 skill — 一個 skill 一個專注流程
不要重複 Claude 預設做得好的事
檢查 skill 裡有沒有矛盾規則

07 · 讀一讀

你現在有大部分 Claude Code 使用者不知道的超能力：教 Claude 你確切怎麼工作的能力。

每個團隊有慣例。每個開發者有偏好。Skill 把那些未明說的規則變成永久、可分享、有版控的指令。

從小開始。挑你最常跟 Claude 講的一件事，變成 skill。測試、精修、commit。再加一個。久了，你 skill 的收藏變成力量倍增器 — 你每寫一個 skill,Claude 對你特定工作就更厲害。

通用 AI 助理跟個人化 AI 流程的差別？Skill。

重點整理

從你最常重複的一個指令的 skill 開始
迭代：測試、精修、commit
透過 git 分享專案 skill，整個團隊受益
久了累積收藏 — 每個 skill 讓 Claude 對你的工作更聰明
Skill 是通用 AI 助理跟個人化 AI 流程的差別

08 · 選擇題

你寫了一個 skill 說「寫好、乾淨的程式碼」。測試後，Claude 輸出好像沒不同。為什麼？

SKILL.md 檔有語法錯誤
Skill 只跟 Opus 模型運作
指令太含糊 — Claude 本來就在試寫好程式
加完 skill 後要重啟 Claude Code

09 · 填空

500 行涵蓋每個可能情境的 skill 是反模式。你應該寫多個 _____ skill，每個涵蓋一個流程。

同章節其他課

⚠ 完整互動體驗需要 JavaScript。請啟用 JavaScript 後重新整理。

※ 本站為獨立繁中教學專案，非 Anthropic 官方產品。Claude™ 為 Anthropic, PBC 商標。