AI coding agent 不是不夠聰明。它太會找理由了。

跟它說寫完記得補測試，它會說「這個功能比較簡單，測試等之後再補」。跟它說上線前做 code review，它說「改動很小，應該沒問題」。跟它做安全審查，它說「這只是內部工具，威脅模型不複雜」。每一個理由聽起來都很合理，每一個結果都讓你在兩週後踩坑。

問題不是 AI 不知道該怎麼做。問題是它沒有理由在沒人要求的情況下把每件事都做完整。

Agent Skills 的設計思路就從這裡開始：不靠信任，靠結構。

19 份文件，覆蓋整個開發生命週期

整個專案沒有任何程式碼依賴。就是 19 份 Markdown 文件，每份對應開發流程的一個階段，告訴 AI agent 這個階段該做什麼、怎麼驗證自己做完了。

作者是 Addy Osmani，Google Chrome 前工程總監，Software Engineering at Google 的貢獻者之一。這本書裡很多工程紀律的理念——測試文化、增量實作、強制 code review——在 Agent Skills 裡都有對應的實作。

按開發階段分成六大類：

Define：idea-refine、spec-driven-development — 從模糊想法到完整規格書，強制 AI 先搞清楚問題再動手。

Plan：planning-and-task-breakdown — 用垂直切片和依賴圖把需求拆成可執行的任務，附上驗收條件。

Build：incremental-implementation、test-driven-development、context-engineering、frontend-ui-engineering、api-and-interface-design — 五個 skill 涵蓋從 TDD 到 context 管理的完整實作流程。

Verify：browser-testing-with-devtools、debugging-and-error-recovery — 五步 triage 除錯流程：重現 → 定位 → 縮小 → 修復 → 防護。

Review：code-review-and-quality、code-simplification、security-and-hardening、performance-optimization — 安全審查涵蓋 OWASP Top 10，review 用五軸架構拆解。

Ship：git-workflow-and-versioning、ci-cd-and-automation、deprecation-and-migration、documentation-and-adrs、shipping-and-launch — 從 Git flow 到部署後文件，都有對應 checklist。

安裝完就多了七個 slash commands

1
2
3
4
5
6
7
8
9
# Claude Code（推薦）
/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

# Cursor
# 把 SKILL.md 複製到 .cursor/rules/

# Copilot
# 用 agents/ 下的 persona 定義搭配 .github/copilot-instructions.md

安裝後可以用的指令：

1
2
3
4
5
6
7
/spec    → 寫規格書
/plan    → 拆解任務
/build   → 增量實作 + TDD
/test    → 測試驅動
/review  → 五軸程式碼審查
/code-simplify → 簡化程式碼
/ship    → 上線前檢查清單

這七個命令的設計邏輯很一致：每個都有退出條件，要求提供具體證據——不是「我覺得完成了」，是「這是測試通過的截圖」。

三個值得停下來看的設計

Anti-Rationalization Table

每個 skill 都附了一張「常見藉口對照表」。AI 很擅長合理化，這張表直接堵死它的後路：

藉口 現實
「我等下再寫測試」 你不會的。現在就寫。
「這只是小改動，不需要 review」 小改動的 bug 比大改動更難抓。
「看起來沒問題」 「看起來」不是證據。給我測試結果。

把資深工程師在 code review 會說的話，直接編碼進指令。AI agent 再有創意，也很難繞過明確寫死的規則。

Verification Checklist

每個 skill 結尾都有退出檢查清單。具體到「要求提供 build 成功的輸出」、「要提供 runtime 數據」——不接受主觀判斷，只接受可驗證的結果。

simplify-ignore Hook

技術含量最高的部分。一個約 300 行的 bash 腳本，讓你在程式碼中標記 simplify-ignore-start/end 區塊。跑 /code-simplify 時，AI 看不到這些區塊，也改不到它們。適合保護效能關鍵的程式碼不被「簡化」掉。

1
2
# 要求 Bash 3.2+ 和 jq
# Windows 需要 WSL

把它當成新人入職指南

類比一下會更清楚：如果 AI agent 是剛進公司的工程師，Agent Skills 就是你給它的「入職工程指南」。

差別在於，一般的入職指南是文件，要靠人自己去遵守。Agent Skills 是指令集，AI 在你要求它執行某個階段的工作時，這些規則就直接注入它的 context，強制執行。

這個設計解決了一個很實際的問題：你不可能在每次叫 AI 做事的時候，都手動提醒它「記得寫測試」「記得做 code review」。你需要一個機制，讓這些提醒自動發生，而且讓 AI 沒辦法用一句「這次例外」繞過去。

跨工具統一流程

純 Markdown 格式讓它可以裝進任何 AI coding 工具。團隊裡有人用 Cursor、有人用 Claude Code、有人用 Copilot，只要每個人都載入同一套 SKILL.md，就能確保一致的工程紀律，不管底層用什麼工具。

多模型交叉審查也是一個實用場景：agents/code-reviewer.md（Staff Engineer 視角）、agents/test-engineer.md（QA 專家）、agents/security-auditor.md（資安工程師）——三個角色的 persona 讓不同視角的 AI 交叉審查同一份程式碼。

專案現況

指標 數據
Stars 9,059
License MIT
建立時間 2026-02-15
活躍度 每天平均 1.7 commits
版本 1.0.0

建立不到兩個月就超過 9K stars。這個速度在 developer tools 領域不常見，通常代表踩到了一個很多人同時在找解法的真實問題。

值得借鏡的模式

就算你不用這套 plugin，Anti-Rationalization Table 和 Verification Checklist 的設計思路本身就值得拿來用。可以把這個模式放進你自己的 CLAUDE.md：

1
2
3
4
## 工程紀律
- 寫新功能必須先寫失敗測試，通過才算完成
- 每次修改超過 20 行的 PR 必須執行 /review
- 不接受「看起來應該沒問題」的判斷，需要具體證據

背後有兩條線。第一條：AI 的問題不是能力，是它會找理由。第二條：解法不是靠信任，是靠結構讓理由站不住腳。

把這兩條線搞清楚，然後選要用 Agent Skills 還是自己寫，都行。

原文來源：GitHub - addyosmani/agent-skills