Skill 觸發判準
簡單到刻在牆上的判準：「每次你發現自己在跟 AI 說一樣的話，那就是應該建一個 Skill 的時候。」 —— Hans
鐵則
「每次你發現自己在跟 AI 說一樣的話，那就是應該建一個 Skill 的時候。」
繁中：「每次你發現自己在跟 AI 說一樣的話，那就是應該建一個 Skill 的時候。」（原文即繁中）
→ 對應姊妹判準（Memory 的）：「每次你發現 AI 又犯了同樣的錯，那就是應該寫一條 Memory 的時候。」
為什麼這條判準成立
| 沒 Skill 的痛 | 有 Skill 後 |
|---|---|
| 每次重新描述完整流程，幾百字 prompt | /skill-name 一鍵觸發 |
| 容易漏步驟 | Skill 把步驟封裝、不會漏 |
| 同事看不到、知識不可重用 | Skill 是 artifact，可共享 / 版本化 |
| AI 每次重新「猜」你要什麼 | AI 照 Skill 走，行為穩定 |
Hans 的 10 個 Skill 範例
| Skill 名稱 | 用途 | 觸發時機 |
|---|---|---|
/techhanlin-write | 寫文章：讀 SOP → 寫 → 上傳 WP → 設 SEO | 寫新文章時 |
/techhanlin-wp | WordPress 純操作 | 改設定時 |
/wp-seo-batch | 批次 SEO 優化 | 大量 SEO 時 |
/css-fix | 先診斷再動手改 CSS | 改樣式時 |
/check | Session 開始驗證環境 | 每次 session 開頭 |
/verify | 修改後強制驗證 | 修完後 |
/deploy | 部署到 production | 上線時 |
→ 共通點：每個都是反覆踩坑後整理出來的，不是一開始就設計好的。
一鍵建立流程
不需要知道 Skill 檔案放哪、格式長什麼樣，直接告訴 Claude Code 你想自動化什麼。
幫我建一個 /deploy 的 Skill，步驟是：
1. 跑 tsc 型別檢查
2. 跑建置
3. 確認變更內容
4. commit
5. push 到 GitHub
6. 提醒我用 Cmd+Shift+R 刷新瀏覽器
→ Claude Code 在正確目錄建好 Skill 檔，下次打 /deploy 一鍵觸發。
反向判準（什麼時候不該建 Skill）
- 只做一次的事 → 別建
- 每次步驟都不同 → 別建（會綁死）
- 已經有重疊 Skill → 整合到現有的，別新建（防 Token 浪費）
→ Skill 的成本是「每次對話都載入 description」，輕度需求不值得。
與其他概念的關係
強連結
- SKILL.md 規範 — Skill 怎麼寫
- Slash Commands — Skill 觸發方式
- Skills 九種類型 — 確認新 Skill 屬於哪一類
- Compounding Engineering — 此判準是 Compounding 的入口閘
- Context Window Token 衛生 — 不亂建 Skill 是源頭預防
推斷連結
- 構建高效 Skill 九大最佳實踐 ?? — 確定要建後，照這 9 條心法做
- Skills 持續學習 ?? — Skill 觸發後也會迭代，不是建完就死
配套規律
Hans 的兩條黃金判準：
- 重複說一樣的話 → 建 Skill
- AI 又犯一樣的錯 → 寫 Memory
兩條合起來 = Compounding Engineering 的入門 SOP。