Skill 是把複雜的重複工作流變成「一個命令」的最有效升級。如果你發現自己每週要執行同樣的 5-8 步工作流不止一次，就該考慮 Skill 了。本篇教你如何從 CLAUDE.md 中提取工作流、建立 Skill 文件、以及用真實的 WordPress 發佈 Skill 驗證整個過程。
何時升級到 Skill？判斷標準
Skill 適合「重複的多步工作流」。以下判斷標準會幫你決定：
- 步驟 ≥ 5 步：Hook 是 1-2 步的快速規則，Skill 是 5+ 步的完整工作流
- 頻率 > 1 次/週：如果你每週只做一次，Hook 就夠了。如果超過一次，Skill 更划算
- 跨檔案協調：涉及多個檔案/API 呼叫的工作流（如發佈文章）
- 決策分支：工作流中有多個「下一步取決於上一步結果」的地方
🟠 案例：WordPress 發佈工作流
發佈部落格文章需要這些步驟：
- 驗證 WordPress API 存取權限
- 查詢現有分類和標籤
- 用 Gutenberg Block 格式化內容
- 添加 SEO 中繼資料（標題、摘要、slug）
- 創建 FAQ JSON-LD 架構
- 生成 REST API 請求payload
- POST 到 WordPress 創建草稿
- 驗證發佈並回傳 URL
這是 8 步工作流，每週發佈 2-3 篇文章。完美的 Skill 候選。
Skill 文件結構
每個 Skill 都是一個 markdown 檔案，放在 ~/.claude/skills/ 目錄下。基本結構如下：
---
name: skill-name
description: 一行描述，告訴 Claude 這個 Skill 做什麼
---
# Skill 標題
## 何時使用
- 用戶說 "xxx"
- 用戶想要完成 "xxx" 的工作
## 前置條件
任何所需的設置、環境變數、API 密鑰等
## 工作流程
使用 ASCII 流程圖或步驟列表
## 詳細步驟
每個步驟的具體實施方式、命令、代碼片段等
WordPress 發佈 Skill 完整範例
---
name: wordpress-blog-publisher
description: Publish SEO-optimized WordPress articles with color-coded content blocks
---
# WordPress Blog Publisher Skill
## 何時使用
- 用戶說「發佈到部落格」或「post to blog」
- 想把分析、研究、程式碼轉成部落格文章
- 需要發佈包含代碼、表格、決策樹的內容
## 前置條件
**WordPress 認證資訊：**
- WordPress 網站 URL
- 使用者名稱 + Application Password
格式：`username` / `xxxx xxxx xxxx xxxx xxxx xxxx`
- 已取得分類 ID 和標籤 ID
**SEO/AEO 要點：**
- 標題 < 60 字符
- 摘要 120-155 字符（= 中繼描述）
- H2 標題 4-8 個，每個含次要關鍵字
- 内容用 Gutenberg Block 格式
## 工作流程
驗證 API 存取 → 查詢分類/標籤 → 格式化內容 → 添加 SEO 中繼 → 創建 FAQ Schema → 生成 Payload → POST 草稿 → 驗證成功
## 詳細步驟
### 步驟 1：驗證 API 存取
```bash
source ~/.claude/projects/-home-tom/wordpress-config.env
curl -s -o /dev/null -w "%{http_code}" -u "${WORDPRESS_USER}:${WORDPRESS_APP_PASSWORD}" \
"${WORDPRESS_URL}/wp-json/wp/v2/posts?per_page=1"
# 200 = 成功, 401 = 認證失敗
```
### 步驟 2：用 Gutenberg Block 格式化內容
使用顏色編碼框突出重點內容：
**紅色框（安全/必須項）：**
```html
🔴 標題
```
**橙色框（重要警告）：**
```html
🟠 標題
```
### 步驟 3：添加 FAQ JSON-LD 架構
在文章結尾添加：
```html
```
### 步驟 4：生成 REST API Payload（用 Python）
```python
import json
# 讀取 HTML 內容
with open('article.html', 'r', encoding='utf-8') as f:
content = f.read()
# 創建 POST payload
post = {
'title': 'SEO-optimized title under 60 chars',
'content': content,
'status': 'draft', # 永遠先存草稿
'slug': 'keyword-rich-slug',
'excerpt': 'Meta description 120-155 chars with primary keyword.',
'categories': [117], # AI 與自動化
'tags': [64, 65]
}
# 用 Python 生成 JSON（確保正確編碼）
with open('payload.json', 'w', encoding='utf-8') as f:
json.dump(post, f, ensure_ascii=False, indent=2)
```
### 步驟 5：POST 到 WordPress
```bash
curl -s -X POST \
-u "${WORDPRESS_USER}:${WORDPRESS_APP_PASSWORD}" \
-H "Content-Type: application/json" \
-d @payload.json \
"${WORDPRESS_URL}/wp-json/wp/v2/posts" | jq '.'
```
回應會包含 `id`（文章 ID）和 `link`（發佈 URL）。
## 測試驗證方法
**驗證清單：**
- [ ] 文章標題 < 60 字符且含主要關鍵字
- [ ] 摘要 120-155 字符
- [ ] H2 標題 4-8 個
- [ ] Gutenberg Block 格式正確（無孤立 HTML 標籤）
- [ ] 彩色框正確呈現（紅/橙/黃等）
- [ ] FAQ Schema 在文章末尾
- [ ] 文件大小 < 50KB（防止 PHP 記憶體耗盡）
**實際驗證：**
```bash
# 檢查發佈結果
curl -s -u "${WORDPRESS_USER}:${WORDPRESS_APP_PASSWORD}" \
"${WORDPRESS_URL}/wp-json/wp/v2/posts/{POST_ID}" | jq '.title, .link, .categories'
# 訪問瀏覽器檢查呈現效果
open {LINK_URL}
```
## 常見問題
**Q：什麼時候應該發佈為草稿而非直接發佈？**
A：永遠先發佈為 `"status": "draft"`。這樣你可以在瀏覽器檢查排版，確認顏色框正確呈現，再手動發佈。
**Q：我的文章超過 50KB，會不會有問題？**
A：WordPress PHP 限制為 536MB，但 Gutenberg Block Parser 會耗盡記憶體。保持每篇文章 < 30KB 最安全。如果內容很長，分成多篇系列文章。
**Q：我想用不同的顏色框，怎麼改？**
A：修改 `background-color` 和 `border-left` 的十六進位色碼：
- 紅色：#fee2e2 / #dc2626
- 橙色：#fed7aa / #ea580c
- 黃色：#fef3c7 / #eab308
- 綠色：#dcfce7 / #16a34a
- 藍色：#dbeafe / #0284c7
- 紫色：#f3e8ff / #a855f7實戰案例：WordPress 發佈 Skill 的演進
本文所述的 WordPress 發佈技能本身就是一個 Skill 演進的案例。從原始的「手工執行 8 步」到「/publish 一鍵完成」，經歷了以下階段：
階段 1：手工 curl 和 Python 指令碼（無 Skill）
每次發佈文章時，手動執行：查詢分類 ID → 準備 JSON → curl POST → 檢查結果。重複 100 次後，開始想「有沒有辦法簡化？」
階段 2：創建 Skill 文件（有程序，無自動觸發）
把 8 個步驟寫成 ~/.claude/skills/wordpress-blog-publisher.md。現在發佈文章時直接說「/wordpress-blog-publisher」，Claude 自動執行完整流程。
階段 3：整合色彩編碼系統（Skill 內容品質升級）
Skill 本身沒變，但發佈的文章內容用 6 色系統標示重點，讀者一眼看懂內容層級。這是在 Skill 執行時「加價」的做法——同樣的技術流程，輸出品質更高。
🟠 Skill 的演進模式
V1（無 Skill）→ V2（有 Skill）→ V3（Skill + 優化）
- V1：手工 8 步 × 100 篇 = 800 步的重複勞動
- V2：`/skill wordpress-blog-publisher` × 100 篇 = 100 次命令
- V3：V2 的結果用色彩編碼 + FAQ Schema + SEO 最佳化 = 更高品質的發佈
關鍵是：Skill 不只是自動化，也是品質保證。每次都按同樣標準執行，不會因為趕時間就跳過 SEO 檢查。
從 CLAUDE.md 提取 Skill 的方法
找出候選工作流
檢視你的 CLAUDE.md，找「重複出現的多步驟序列」。常見候選包括：
- 數據爬蟲 + 清洗 + 存儲 → Collector Skill
- API 請求 + 驗證 + 回應處理 → API Integration Skill
- 代碼提交 + 測試 + 部署 → CI/CD Skill
- 內容撰寫 + SEO 檢查 + 發佈 → Publishing Skill
提取步驟和決策點
寫下完整流程，標記「決策點」（即下一步取決於上一步結果的地方）：
步驟 1：驗證認證 → 如果失敗，停止並報告錯誤
步驟 2：查詢資源 → 如果不存在，建立新資源
步驟 3：轉換數據 → 如果格式錯誤，套用修復規則
步驟 4：執行操作 → 如果超時，重試 3 次
步驟 5：驗證結果 → 如果失敗，回滾並通知測試 Skill 執行
Skill 寫好後，執行一次完整流程並記錄結果：
- 用真實數據執行 Skill
- 檢查每個決策點是否如預期
- 驗證最終輸出品質
- 根據結果更新 Skill 文檔
何時停止改進 Skill，開始考慮 Custom Agent？
當你的 Skill 變得太複雜時（超過 500 行文檔、20+ 決策分支），考慮升級到 Custom Agent。Agent 能做的事 Skill 做不了：
- Skill：執行預定工作流，用戶提供參數
- Agent：自行規劃方法、選擇工具、適應新情況
🔵 快速檢查清單
你的工作流適合 Skill 嗎？
- ✅ 是否有固定的 5+ 步流程？
- ✅ 是否每週重複 > 1 次？
- ✅ 是否可以用預定參數執行（用戶提供標題、內容等）？
- ✅ 是否有清晰的成功/失敗判斷標準？
全部 ✅ 就是 Skill。如果答案有「取決於上下文」，可能需要 Custom Agent。
總結
Skill 是 Hook 和 Custom Agent 之間的「黃金中間」。它足夠強大來自動化複雜工作流，又足夠簡單讓你快速編寫和維護。每個 Skill 可以節省你幾十小時的重複勞動，而只需 1-2 小時來編寫文檔。
下一步：檢查你的 CLAUDE.md，找出 5+ 步、每週重複的工作流。寫成 Skill 文件，測試一次，然後享受自動化帶來的自由。
發佈留言