為什麼需要下一步？ Code Review AI 的現實困境
我們在「【🤖 Claude Code x Code Review】PR 免等待！打造 AI 自動審查員」分享如何用Claude Code打造Code Review機器人， 實際使用後，確實帶來很多好處：
• PR 不再卡在「沒人 review」• 能快速指出潛在 bug
• 能協助流程自動化
但實際深入使用後，我也遇到了三個很現實的問題：
• ❌ 同樣規範，AI 並不總是遵守
• ❌ CLAUDE.md / AGENTS.md 寫得很漂亮，但不一定被尊重
• ❌ 有時候很專業，有時候卻像「心情好才審認真」
Skills 登場：讓 AI 從「助手」變成「流程的一部分」
🔍 Skills 解決什麼問題？
• 把「規範」轉成「功能」
• 把「建議」轉成「能力」
• 把「理論」轉成「機制」
簡單說：
Skills = 給 AI 一個「固定行為模組」
而不是「希望它照著我的 prompt 做事」
為什麼寫Skills？
決定是否撰寫Skills之前先詢問自己以下事項：
• 我重複做了什麼事？ → 這就是 Skill 的候選
• 這件事有固定流程嗎？ → 流程越明確，Skill 越有效
• 我常忘記哪些步驟？ → 這正是 Skill 的價值
而我們在「【🤖 Claude Code x Code Review】PR 免等待！打造 AI 自動審查員」遇到的狀況正好滿足上述事項， 因此決定寫一個skill來避免， 也順便學習如何使用， 並分享給大家。
如何建立一個commit skills？
第一步：建立 commit skill 存放目錄
mkdir -p .claude/skills/commit
第二步： 撰寫SKILL.md技巧
2-1 結構三要素
2-2 Frontmatter：決定「何時觸發」
• name: 簡短、小寫、用連字號。
• description: 兩句話：做什麼 + 何時使用。
• allowed-tools： 只給必要權限（最小權限原則）。
---
name: commit
description: 執行提交前檢查（linting、測試、code review）並建立 git commit。當使用者說「commit」、「提交」、「幫我提交」時使用。
allowed-tools: Bash, Read, Grep, Glob, Edit
---
2-3 目標說明：一句話講清楚
# Git Commit Skill
建立 Git commit 前執行完整的檢查流程。
2-4 執行步驟：像寫 SOP
• 用階段分組（方便理解）
• 用編號排序（確保順序）
• 用具體指令（減少歧義）
• 加上條件判斷（若...則...）
## 執行流程
### 階段 1：程式碼品質檢查
1. **Ruff Linting**
- 執行 `uv run ruff check src/`
- 若有錯誤，先修復再繼續
### 階段 2：Code Review
3. **檢視變更內容**
- 執行 `git diff --stat`
2-5 檢查清單：確保不遺漏
4. **Code Review 檢查清單**
針對每個變更的檔案，檢查：
- [ ] 程式碼邏輯是否正確
2-6 輸出格式：標準化回報
## 完成後回報
### ✅ 檢查結果
- [ ] Ruff linting 通過
- [ ] 測試通過
- [ ] Code Review 完成（無問題 / 已修復）
2-7 注意事項：防止意外
## 注意事項
- 不要執行 `git push`，除非使用者明確要求
- 若有未追蹤的重要檔案，詢問是否要加入
- 若使用者提供額外說明，可作為 commit message 的參考
第三步：實際撰寫 SKILL.md
這邊我們一併附上實際專案的SKILL.md給您參考：
---
name: commit
description: 執行提交前檢查（linting、測試、code review）並建立 git commit。當使用者說「commit」、「提交」、「幫我提交」時使用。
allowed-tools: Bash, Read, Grep, Glob, Edit
---
# Git Commit Skill
建立 Git commit 前執行完整的檢查流程。
## 執行流程
### 階段 1：程式碼品質檢查
1. **Ruff Linting**
- 執行 `uv run ruff check src/`
- 若有錯誤，先修復再繼續
2. **執行測試**
- 執行 `uv run pytest tests/ -v --tb=short`
- 若測試失敗，停止流程並報告
### 階段 2：Code Review
3. **檢視變更內容**
- 執行 `git diff --stat` 了解變更範圍
- 執行 `git diff` 詳細檢視變更
4. **Code Review 檢查清單**
針對每個變更的檔案，檢查：
- [ ] 程式碼邏輯是否正確
- [ ] 是否有潛在的 bug 或邊界情況未處理
- [ ] 是否有安全性問題（如 SQL injection、XSS、硬編碼密碼等）
- [ ] 命名是否清晰、符合專案慣例
- [ ] 是否有不必要的重複程式碼
- [ ] 錯誤處理是否完整
- [ ] 是否有遺漏的 logging 或過多的 logging
5. **若發現問題**
- 列出問題清單
- 詢問使用者是否要修復後再提交
### 階段 3：準備 Commit
6. **查看 Git 狀態**
- 執行 `git status` 確認要提交的檔案
- 執行 `git log --oneline -5` 了解 commit message 風格
7. **建立 Commit**
- 將相關檔案加入暫存區
- 根據變更內容撰寫 commit message
- 遵循專案的 commit message 風格
- 使用 HEREDOC 格式確保訊息格式正確
## Commit Message 格式
```
<type>: <簡短描述>
<詳細說明（若需要）>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
**Type 類型**：
- `feat`: 新功能
- `fix`: Bug 修復
- `refactor`: 重構（不改變功能）
- `docs`: 文件更新
- `test`: 測試相關
- `chore`: 雜項（設定、建置等）
- `perf`: 效能優化
## 完成後回報
### ✅ 檢查結果
- [ ] Ruff linting 通過
- [ ] 測試通過
- [ ] Code Review 完成（無問題 / 已修復）
### 📝 Commit 資訊
- Commit hash: （提交後顯示）
- 變更檔案數:
- 變更摘要:
## 注意事項
- 不要執行 `git push`，除非使用者明確要求
- 若有未追蹤的重要檔案，詢問是否要加入
- 若使用者提供額外說明，可作為 commit message 的參考
實際驗證成果
當我們輸入「提交」這類型的關鍵字， Claude Code就會自動幫我們選取對應的skill來進行SOP流程， 內部實作概念其實跟我們的 https://github.com/weihanchen/ai-voice-assistant-fastrtc 很像， 也歡迎參考唷！
結語：AI 不只是工具，而是團隊成員
上一篇，我讓 Claude 成為：
👉 「可以幫忙審 PR 的 AI 工程師」
但這一篇，我希望走得更遠：
👉「讓 AI 成為『可靠、可控、可預期』的工程流程一部分」
這正是：Claude Code × Skills 的真正價值。
