Skill Validator

Skill Validator

審查 Claude Skill 品質的雙框架工具。根據用戶需求，執行以下兩套審查之一（或全部）：

Step 1：讀取 Skill

請用戶提供以下任一：

• SKILL.md 的完整路徑（自動讀取）
• 直接貼上 SKILL.md 內容
• Skill 資料夾路徑（列出所有檔案後讀取 SKILL.md）

若是資料夾，先列出結構：

your-skill/
  SKILL.md
  scripts/   （若有）
  references/（若有）
  assets/    （若有）

Step 2：判斷審查模式

根據用戶說法判斷：

• 說「上傳前」、「格式對不對」、「technical check」、「技術問題」→ 技術合規模式（Anthropic 指南）
• 說「品質」、「improve」、「架構」、「更好」、「content」→ 內容深度模式（Weber 9 原則）
• 說「全部」、「comprehensive」、「都查」→ 完整審查模式（兩套都跑）
• 無法判斷時 → 預設執行完整審查

Step 3A：技術合規審查（Anthropic 官方指南）

參考 references/anthropic-guide.md，逐項掃描：

技術格式（Pass/Fail）

Description 品質（評分）

公式：[做什麼] + [何時觸發／用戶實際會說的話]

• ✅ 具體說明功能 + 包含觸發關鍵詞
• ⚠️ 只有功能描述、缺觸發詞（或反之）
• ❌ 太模糊（「Helps with projects」）或純技術術語

Instructions 品質（評分）

• 具體可執行：有精確步驟，非模糊指示
• 錯誤處理：常見失敗場景有說明
• 漸進揭露：細節是否適當移到 references/
• 範例：是否附使用情境示範

輸出格式

## 技術合規報告：{skill name}

### 格式檢查
| 項目 | 結果 | 說明 |
|------|------|------|
| 資料夾命名 | ✅/❌ | ... |
| SKILL.md 命名 | ✅/❌ | ... |
| YAML 框架 | ✅/❌ | ... |
| name 欄位 | ✅/❌ | ... |
| description 完整性 | ✅/⚠️/❌ | ... |
| description 長度 | ✅/❌ | X 字元 |
| 無 XML 標籤 | ✅/❌ | ... |
| 無 README.md | ✅/❌ | ... |

### Description 品質
評分：✅ 合格 / ⚠️ 需補強 / ❌ 需重寫
說明：...

### Instructions 品質
評分：✅ / ⚠️ / ❌
說明：...

### 建議測試用例
應觸發（至少 3 個）：
- "..."
- "..."
- "..."

不應觸發（至少 2 個）：
- "..."
- "..."

### 結論
狀態：✅ 可上傳 / ⚠️ 修正後上傳 / ❌ 需重寫
必修項目：（列出 1-3 個最重要的）

Step 3B：內容深度審查（Weber 9 原則）

參考 references/weber-9.md，逐項評分：

對每個原則給出：

• ✅ 通過 / ⚠️ 部分符合 / ❌ 未達標
• 具體說明原因
• 改善建議（如需要）

同時確認此 skill 屬於哪個分類：

• Library & API Reference
• Product Verification
• Data & Analysis
• Business Automation
• Scaffolding & Templates
• Code Quality & Review
• CI/CD & Deployment
• Incident Runbooks
• Infrastructure Ops

輸出格式

## 內容深度報告：{skill name}

### 9 原則評分
| 原則 | 結果 | 說明 |
|------|------|------|
| 1. Token 節省 | ✅/⚠️/❌ | ... |
| 2. 漸進揭露架構 | ✅/⚠️/❌ | ... |
| 3. 觸發最佳化 | ✅/⚠️/❌ | ... |
| 4. 確定性邏輯黑盒化 | ✅/⚠️/❌ | ... |
| 5. 自由度匹配 | ✅/⚠️/❌ | ... |
| 6. 參考資料模組化 | ✅/⚠️/❌ | ... |
| 7. Pre-flight 需求確認 | ✅/⚠️/❌ | ... |
| 8. 無人類文件 | ✅/⚠️/❌ | ... |
| 9. 驗證清單 | ✅/⚠️/❌ | ... |

### 分類
此 skill 屬於：{分類名稱}

### 總評
通過：X/9 項
狀態：✅ 合格 / ⚠️ 需改善 / ❌ 需重寫

### 必修建議
（最重要的 1-3 項）

### 選修建議
（額外優化空間）

Step 4：完整審查（兩套合併）

先跑 Step 3A（技術合規），再跑 Step 3B（內容深度），輸出兩份報告後，加一段整合摘要：

## 整合摘要

### 優先修復順序
1. [技術層面最重要的問題]
2. [內容層面最重要的問題]
3. ...

### 可上傳狀態
技術合規：✅/⚠️/❌
內容深度：✅/⚠️/❌
整體建議：[一句話結論]

常見快速判斷

Description 是否有效？ → 把 description 給不認識這個 skill 的人看，他能知道什麼時候該用嗎？

是否過度指定步驟？ → 計算 skill 裡「Step X：」出現幾次。超過 5 個步驟通常是 railroading。

是否需要 Progressive Disclosure？ → SKILL.md 超過 150 行 → 考慮把細節移到 references/。

是否有 Gotchas？ → 沒有 Gotchas = Day 1 狀態，尚未經過實戰磨練。