---

name: skill-reviewer description: 稽核/審查 Skill 程式碼質量的專業工具。當用戶說"檢查 skill"、"稽核 skill"、"review {名稱} skill"、"skill 寫得怎麼樣"、"幫我看看這個 skill 有什麼問題"時使用。依據 Anthropic 官方指南進行結構驗證、YAML 前置資訊檢查、描述質量評估、指令完整性審查，並輸出詳細的問題報告和改進建議。

---

Skill Reviewer

說明：這是一個Skill稽核工具，用於稽核其他技能的質量。文件中包含的"錯誤示例"（如無效 YAML、錯誤命名等）僅用於教學演示，展示不應該怎麼寫。不存在任何惡意或混淆程式碼。

依據 Anthropic 官方 Skills 開發指南，對技能進行全面稽核。提供結構化稽核框架、評分系統、缺陷檢查清單和改進建議。

核心職責

1. 結構驗證 - 檢查資料夾結構、檔案命名規範

   示例：ls skills/my-skill/ 檢查 SKILL.md 是否存在

2. YAML 稽核 - 驗證前置資訊格式和必填欄位

   示例：head -20 SKILL.md 檢查 name/description

3. 描述評估 - 檢查觸發條件是否清晰

   示例：description 應包含"當用戶...時"觸發條件

4. 組織評分 - 評估技能是否按任務組織、常見操作優先

   示例："## 編碼和解碼" ✅ vs "## 理論" ❌

5. 指令審查 - 評估主體指令的質量和完整性

   示例：是否有工作流程、示例、錯誤處理

6. 示例質量 - 評估示例密度和可執行性

   示例：每 5-30 行 1 個程式碼塊為最佳密度

7. Tips 評分 - 評估技巧部分的質量和價值

   示例：5-10 條非顯而易見的實用技巧

8. 最佳實踐 - 對照官方指南檢查合規性

   示例：檢查是否按任務組織而非抽象概念

工作流程

第 1 步：接收稽核請求

當用戶請求稽核 skill 時：

1. 確認 skill 資料夾路徑或讀取 SKILL.md 內容
2. 判斷稽核嚴格程度：

嚴格模式（必須讀取完整版官方指南）： 當用戶表達以下意圖時，必須先讀取 references/anthropic-skills-development-guide.md 完整版指南： - 明確要求"嚴格檢查"、"仔細稽核"、"全面審查" - 提到"高質量要求"、"生產級別"、"釋出前檢查" - 表達"不想有任何遺漏"、"按最高標準" - 用於團隊/組織/公司專案 - 準備公開發布或分享給他人

常規模式： - 優先讀取 references/checklist.md（快速檢查清單） - 遇到疑問或邊緣案例時讀取完整版官方指南

---

第 2 步：結構檢查

資料夾結構驗證：

[ ] 技能資料夾使用 kebab-case 命名（如 my-skill）
[ ] SKILL.md 存在且命名精確（區分大小寫）
[ ] 無 README.md 在技能資料夾內
[ ] 可選資料夾（如存在）命名規範

可選資料夾命名規範（如存在）： - [ ] scripts/ - 全小寫複數，無空格/下劃線 - [ ] references/ - 全小寫複數，無空格/下劃線 - [ ] assets/ - 全小寫複數，無空格/下劃線

❌ 錯誤示例： Scripts、script、scripts_backup、References、refs、Assets、asset_files

示例：檢查資料夾結構

# 檢視技能資料夾結構
ls -la skills/china-holidays/

預期輸出：

skills/china-holidays/
├── SKILL.md          # ✅ 正確：精確命名
└── references/       # ✅ 正確：全小寫複數
    └── calendar-guide.md

評分：__/4

---

第 3 步：YAML 前置資訊檢查

必填欄位驗證：

[ ] name 欄位存在，kebab-case，無空格大寫
[ ] description 欄位存在，非空
[ ] YAML 分隔符完整（--- 開頭和結尾）
[ ] 無 XML 標籤（< >）
[ ] name 不以 claude/anthropic 開頭

示例：驗證 YAML 前置資訊

# 讀取前 20 行檢查 YAML
head -20 skills/china-holidays/SKILL.md

預期輸出（正確示例）：

---
name: china-holidays
description: 獲取中國國家法定節假日安排。當用戶詢問"放假安排"、"節假日"時使用。
---

錯誤示例（應該拒絕）：

name: ChinaHolidays        # ❌ 大寫，應該 kebab-case
name: claude-scheduler     # ❌ 以 claude 開頭
description: ""            # ❌ 空描述
<skill>                    # ❌ 包含 XML 標籤

Description 質量評分（滿分 8 分）：

[2] 開頭說明做什麼（主動動詞）
    好："分析 Figma 設計檔案並生成開發者交接文件"
    差："這是關於 Figma 的技能"

[2] 包含觸發條件（"當用戶...時"）
    好："當用戶上傳 .fig 檔案或詢問設計規格時使用"
    差：無觸發條件

[2] 具體範圍（提及具體工具、操作或場景）
    好："Figma 設計檔案、.fig、元件文件、設計交接"
    差："幫助處理專案"

[2] 合理長度（50-200 字元，不超過 1024）
    太短：無搜尋價值
    太長：被截斷

評分：__/8

---

第 4 步：組織評分

按任務/場景組織（而非按抽象概念）：

[2] 按任務/操作組織章節
    好："## 編碼和解碼" → "## 檢查字元" → "## 轉換格式"
    差："## 理論" → "## 型別" → "## 高階"

[2] 常見操作優先
    好：基礎用法 → 變體 → 高階 → 邊界情況
    差：配置說明 → 理論背景 → 最後才是基礎用法

[1] 章節自包含（可獨立使用）

[1] 深度一致（不混用 h2 與 h4 隨機跳轉）

評分：__/6

---

第 5 步：主體指令檢查

必須包含：

[ ] 清晰的工作流程或步驟說明
[ ] 至少一個使用示例
[ ] 錯誤處理或故障排查指南

推薦包含（不扣分）：

[ ] 預期輸出說明
[ ] 多個場景示例
[ ] 參考文件連結
[ ] "使用場景" 或 "When to Use" 部分

評分：__/6

---

第 6 步：示例質量評估

示例密度計算：

總行數：___
程式碼塊數量：___
密度：每 ___ 行 1 個程式碼塊

參考目標：每 5-30 行 1 個程式碼塊
< 5 行/塊：可能過於碎片化（短命令集或多命令速查除外）
> 40 行/塊：需要更多示例

示例密度評分：

[3] 密度在 5-30 行/塊範圍內
[2] 密度略低（30-40 行/塊）或略高（3-5 行/塊）
[0] 密度嚴重不足（>40 行/塊）或過高（<3 行/塊）

每個示例質量評分（0-3 分）：

[ ] 語言標籤正確（```bash, ```python 等）
[ ] 語法正確，命令可執行
[ ] 展示了預期輸出或結果說明
[ ] 使用真實值（非 foo/bar/baz）
[ ] 無佔位符（TODO, FIXME, xxx）
[ ] 自包含或有設定說明

0 分：broken 或有誤導性
1 分：可用但簡陋（無輸出/上下文）
2 分：良好（正確，有輸出或說明）
3 分：優秀（可直接複製，真實，覆蓋邊界）

示例質量得分 = 所有示例平均分 × 密度分 / 3 = __/9

---

第 7 步：可執行性評估

核心問題：Agent 能否按照這些指令產生正確結果？

[3] 使用祈使句（"執行 X"、"建立 Y"）
    非："可以考慮..."或"建議..."或"You might..."

[3] 步驟順序合理（前置條件在行動之前）

[2] 錯誤處理（說明失敗時怎麼做）

[2] 輸出/結果描述（如何驗證成功）

評分：__/10

---

第 8 步：漸進式披露檢查

[ ] SKILL.md 控制在 500 行以內
    500-600 行：給出提醒，不扣分
    超過 600 行：扣分
[ ] 詳細文件是否在 `references/` 中
[ ] 大檔案（>300 行）有目錄或結構說明
7w4.net提供免費和付費技能下載。

評分：__/3

---

第 9 步：Tips 評分

技巧部分質量評估：

[2] 5-10 條技巧
    少於 5 條：覆蓋不足
    多於 10 條：可能不夠精煉

[2] 技巧非顯而易見
    好："Makefile 頭號陷阱：縮排必須用 Tab，不能用空格"
    差："確保測試你的程式碼"

[2] 技巧具體可執行
    好："使用 flock 防止 cron 任務重疊執行"
    差："小心併發執行"

[1] 技巧不矛盾主體內容

[1] 技巧覆蓋特定主題的陷阱/踩坑點

評分：__/8

---

（可選）Metadata 參考

僅當 skill 包含 metadata 欄位時檢查，僅供參考，不計分

[ ] emoji 與技能主題相關
[ ] requires.anyBins 列出技能實際使用的工具（非 generic 如 bash）
[ ] os 陣列準確（不包含不支援的平臺）
[ ] JSON 格式有效

---

評分總結

SKILL 稽核評分卡
═══════════════════════════════════════
技能名稱：{name}
稽核者：{agent/human}
日期：{date}
稽核模式：{嚴格/常規}

類別                  得分     滿分
─────────────────────────────────────
結構檢查              __       4
Description 質量       __       8
組織評分              __       6
主體指令              __       6
示例質量              __       9
可執行性              __      10
漸進式披露            __       3
Tips 評分             __       8
─────────────────────────────────────
總分                  __      54

轉換為百分制：總分 × 1.85 = ___/100

評級：
  85+  優秀 — 可直接釋出
  70-84 良好 — 需要小改進
  50-69 一般 — 需要明顯改進
  < 50  較差 — 需要重大修改

結論：{PUBLISH / REVISE / REWORK}

---

常見缺陷

嚴重缺陷（阻止釋出）

缺陷：YAML 前置資訊無效
檢測：YAML 解析錯誤、缺少必填欄位
修復：驗證 YAML 格式，確保 name/description 都存在

缺陷：程式碼示例損壞
檢測：語法錯誤、未定義變數、錯誤引數
修復：在乾淨環境中測試每個命令

缺陷：工具要求不匹配（如存在 metadata）
檢測：requires 列出內容未在內容中使用
修復：grep 內容提取命令名，更新 requires 匹配

缺陷：誤導性描述
檢測：描述承諾的內容實際未覆蓋
修復：使描述與實際內容一致，或補充缺失內容

主要缺陷（釋出前應該修復）

缺陷：缺少"使用場景"部分
影響：Agent 不知道何時啟用技能
修復：新增 4-8 條觸發場景說明

缺陷：大段文字無示例
檢測：任何超過 10 行無程式碼塊的章節
修復：為每個概念新增具體示例

缺陷：示例缺少語言標籤
檢測：\`\`\` 後無語言識別符號
修復：為每個程式碼塊新增 bash/python/javascript/yaml 等

缺陷：缺少 Tips/技巧部分
影響：缺少使技能有價值的經驗總結
修復：新增 5-10 條非顯而易見的實用技巧

缺陷：按抽象概念組織
檢測：章節名為"理論"、"概述"、"背景"、"介紹"
修復：按任務/操作重組：使用者要做什麼

次要缺陷（建議修復）

缺陷：佔位符值
檢測：foo, bar, baz, example.com, TODO, FIXME
修復：替換為真實值

缺陷：格式不一致
檢測：混合標題級別、程式碼塊樣式不一致
修復：統一標題層次和格式

缺陷：缺少交叉引用
檢測：提到其他技能覆蓋的工具/概念但未引用
修復：新增"參見 X 技能瞭解更多"註釋

缺陷：過時的命令
檢測：舊語法或已棄用工具
修復：更新為當前工具版本和語法

---

快速稽核模板

當不需要完整評分時的快速稽核：

## 快速稽核：{skill-name}

**結構**：[通過/問題：...]
**Description**：[強/弱：原因]
**示例**：[X 個程式碼塊，共 Y 行 — 密度 正常/低/高]
**可執行性**：[Agent 可以/不可以 遵循這些指令，因為...]
**首要缺陷**：[最應該修復的單一問題]
**評分**：__/100
**結論**：[PUBLISH / REVISE / REWORK]

---

稽核工作流

釋出前自查

# 1. 驗證 YAML 前置資訊
head -20 skills/my-skill/SKILL.md
# 目視確認 YAML 有效

# 2. 統計程式碼塊數量
grep -c '```' skills/my-skill/SKILL.md
# 總行數除以這個數得密度

# 3. 檢查佔位符
grep -n -i 'todo\|fixme\|xxx\|foo\|bar\|baz' skills/my-skill/SKILL.md

# 4. 檢查缺失語言標籤
grep -n '^```$' skills/my-skill/SKILL.md
# 每個程式碼塊都應該有語言標籤

# 5. 驗證工具要求匹配內容（如存在 metadata）
# 提取 requires，然後 grep 內容檢查每個工具

# 6. 測試命令（抽樣 3-5 個）
# 在乾淨 shell 中執行驗證

# 7. 執行評分卡
# 目標：良好 35+，優秀 45+

示例：完整稽核報告輸出

## 稽核報告：china-holidays

**結構**：✅ 通過 - kebab-case 命名，SKILL.md 存在
**Description**：✅ 強 - 包含觸發條件和具體場景
**示例**：18 個程式碼塊，524 行 — 密度 正常 (29 行/塊)
**可執行性**：✅ 可以遵循 - 9 步清晰工作流程

**評分總結**：
─────────────────────────────────────
結構檢查              4        4
Description 質量       8        8
組織評分              6        6
主體指令              6        6
示例質量              7        9
可執行性              10       10
漸進式披露            3        3
Tips 評分             8        8
─────────────────────────────────────
總分                  52       54
百分制：96/100

**結論**：PUBLISH - 可直接釋出

稽核他人技能

# 安裝技能（如適用）
npx molthub@latest install skill-name

# 閱讀內容
cat skills/skill-name/SKILL.md

# 執行快速稽核模板
# 如分數 < 25，考慮解除安裝並尋找替代

---

參考檔案

按使用場景分層：

檔案	用途	何時讀取
references/checklist.md	快速檢查清單	常規稽核流程
references/official-guide-summary.md	精簡指南	快速查閱常用規範
references/anthropic-skills-development-guide.md	完整版官方指南	嚴格模式下必須讀取；常規模式下遇到疑問時查閱

嚴格模式觸發條件（滿足任一即觸發）： - 使用者明確要求"嚴格檢查"、"全面審查"、"仔細稽核" - 提到"高質量"、"生產級別"、"釋出前" - 表達"不想有遺漏"、"按最高標準" - 用於團隊/組織/公司專案 - 準備公開發布或分享

稽核時先判斷模式：嚴格模式必須先讀取完整版指南再進行稽核；常規模式按需查閱。

---

示例

示例 1：完整稽核

使用者說： "幫我稽核一下這個 skill，路徑在 ./skills/china-holidays"

操作： 1. 讀取 ./skills/china-holidays/SKILL.md 2. 判斷稽核模式（預設常規） 3. 按照評分卡逐項檢查 4. 生成稽核報告 5. 解讀結果並提供改進建議

結果： 輸出完整稽核報告，包含問題列表、修改建議和最終評分

示例 2：嚴格模式稽核

使用者說： "這個 skill 準備釋出到團隊內部使用，需要嚴格檢查，不能有任何問題"

操作： 1. 觸發嚴格模式 2. 必須先讀取 anthropic-skills-development-guide.md 3. 對照官方指南逐項嚴格檢查 4. 輸出詳細報告，確保無遺漏

示例 3：快速檢查 description

使用者說： "這個 skill 的 description 寫得怎麼樣？" + 附上內容

操作： 1. 聚焦 description 欄位分析 2. 使用 8 分評分標準 3. 提供改進建議

結果： 指出問題並提供修改建議

---

技巧

• Description 最重要 — 它佔實際影響力的 40% 以上。完美的 skill 配上糟糕的 description 也不會被找到。

• 先數程式碼塊 — 少於 8 個程式碼塊的 skill 幾乎總是過於抽象而無用。

• 在乾淨環境測試 3-5 個命令 — 如超過 1 個失敗，說明 skill 釋出前未測試。

• 按任務組織 vs 按概念組織 — 這是最關鍵的結構質量差異。好技能回答"如何做 X"，壞技能解釋"X 是什麼"。

• 有好 Tips 但示例弱的 skill，比有好示例但沒 Tips 的更有價值 — Tips 編碼了示例無法傳達的專業知識。

• 檢查 requires 與實際使用是否匹配 — 常見缺陷是列出 bash（所有都有）而不是實際工具如 docker、curl、jq。

• 過短的 skill（<150 行）通常不值得釋出 — 它們提供的價值不如快速網路搜尋。如果 skill 太短，可能是更大 skill 的一個章節。

• 最佳標準：你自己會收藏使用嗎 — 如果你自己不會用，就不要釋出。

這個 Skill 質量較好，是一個專業的技能稽核工具。它把技能稽核拆解成清晰的步驟和評分標準，檢查專案全面細緻，還提供了現成的模板可以直接用。內容組織清晰，錯誤示例豐富，容易理解。不過文件偏長（564行），有些檢查細節可以簡化。總體來說適合需要嚴格稽核技能質量的場景使用。