10｜工程 SDLC 全流程 Skill 包（addyosmani/agent-skills）
🎯 一句話：把資深工程師遵循的整套 SDLC 流程與品質關卡——從訪談需求到上線監控——寫成 24 個 Skill，跨 9 種 Agent 工具通用。
- Repo：https://github.com/addyosmani/agent-skills
- 授權：MIT
- 安裝：
npx skills add addyosmani/agent-skills - 相容：Claude Code、Cursor、Gemini CLI、Antigravity、Windsurf、OpenCode、GitHub Copilot、Kiro IDE、Codex
作者背景
Addy Osmani 長期在 Web 效能與前端工程領域活躍，是《Learning JavaScript Design Patterns》等書的作者，也長年關注 Chrome、Web Vitals 一類的效能與工程實踐議題。這個背景清楚反映在收藏內容上：24 個 Skill 裡有專門的 frontend-ui-engineering（WCAG 2.1 AA 無障礙）、performance-optimization（Core Web Vitals）、browser-testing-with-devtools，以及一個獨立的 web-performance-auditor agent persona——效能與前端工程不是附帶功能，而是整套流程裡明確獨立出來的一塊。
這份作者背景是根據其公開身分與著作整理，並非直接取自 repo README——README 本身沒有寫「關於作者」的段落，特此註明來源區別。
這個收藏在解決什麼問題
多數 Skill 收藏是「一個 Skill 對一種任務」的散裝集合；這個 repo 反過來，是用 8 個 slash command 對齊軟體開發生命週期的 8 個階段，24 個 Skill 全部掛在這張流程圖上：
/spec /plan /build /test /review /webperf /code-simplify /ship
/build auto 尤其值得注意：它讓任務不需人工逐步確認就串起來執行，但仍然逐一測試驅動、逐一 commit——串起來的是流程的推進，不是省略掉品質關卡。
24 個 Skill，依 SDLC 階段分組
Meta（1）
| Skill | 作用 |
|---|---|
using-agent-skills | 把手上的任務對應到正確的 Skill 流程——是這套收藏自己的路由器 |
Define 定義（3）
| Skill | 作用 |
|---|---|
interview-me | 一次問一個問題，把需求問清楚 |
idea-refine | 把模糊的構想收斂成具體提案 |
spec-driven-development | 動手寫程式前先寫完整 PRD |
Plan 規劃（1）
| Skill | 作用 |
|---|---|
planning-and-task-breakdown | 把 spec 拆成可驗證、有順序的任務清單 |
Build 建構（7）
| Skill | 作用 |
|---|---|
incremental-implementation | 薄的垂直切片，逐一測試、逐一 commit |
test-driven-development | Red-Green-Refactor，強調測試金字塔紀律 |
context-engineering | 在對的時機餵給 Agent 對的資訊 |
source-driven-development | 決策要以官方文件為依據，不臆測 |
doubt-driven-development | 高風險工作用對抗式的即時審查 |
frontend-ui-engineering | 元件、設計系統、WCAG 2.1 AA 無障礙 |
api-and-interface-design | contract-first 設計、Hyrum's Law、版本管理 |
Verify 驗證（2）
| Skill | 作用 |
|---|---|
browser-testing-with-devtools | 即時檢查瀏覽器 runtime、效能剖析 |
debugging-and-error-recovery | 五步驟除錯分診流程 |
Review 審查（4）
| Skill | 作用 |
|---|---|
code-review-and-quality | 五軸審查，附嚴重度標籤 |
code-simplification | 用 Chesterton's Fence 原則判斷該不該砍，聚焦清晰度 |
security-and-hardening | OWASP Top 10、認證模式、機密管理 |
performance-optimization | 先量測再優化，目標對齊 Core Web Vitals |
Ship 上線（6）
| Skill | 作用 |
|---|---|
git-workflow-and-versioning | trunk-based 開發、原子化 commit |
ci-cd-and-automation | Shift Left、feature flag、品質關卡 |
deprecation-and-migration | 把程式碼當負債看待，遷移是強制流程 |
documentation-and-adrs | Architecture Decision Records，聚焦「為什麼」 |
observability-and-instrumentation | 結構化 log、RED 指標、OpenTelemetry |
shipping-and-launch | 上線前檢查表、分階段推出、上線監控 |
4 個專家 persona（agents/）
code-reviewer（資深 Staff Engineer 視角）、test-engineer（QA）、security-auditor（漏洞／威脅視角）、web-performance-auditor（Core Web Vitals 分析）——把「用什麼身分審查」也顯式寫出來，而不是讓同一個通用 Agent 戴不同帽子含糊處理。
7 份參考檢查表（references/）
definition-of-done、testing-patterns、security-checklist、performance-checklist、accessibility-checklist、observability-checklist、orchestration-patterns——供 Skill 內文引用，避免每個 Skill 各自重複寫一份清單。
SKILL.md 的共同骨架
repo 裡每個 Skill 都遵守同一套結構：
Frontmatter（name／description／觸發詞）
→ Overview
→ When to Use
→ Process（逐步流程）
→ Rationalizations（Agent 常見的偷懶藉口 + 反駁）
→ Red Flags
→ Verification（要求具體證據：測試通過、build 成功、runtime 資料）
**「Verification 不可妥協」**是明講的設計原則——光是「看起來對」不夠，要有測試通過、build 成功這類具體證據。Rationalizations 這個區塊尤其少見：直接列出 Agent 可能找的藉口（例如「這個測試先跳過也沒差」）並附上反駁，等於把「怎麼不讓模型偷懶」寫進 Skill 本體。
repo 明確引用《Software Engineering at Google》作為哲學根源：Hyrum's Law、測試金字塔／碧昂絲原則、change-sizing 與審查規範、Chesterton's Fence、trunk-based development、Shift Left——這些概念不是空泛引用，而是逐一對應到上面某個具體 Skill。
值得抄的三件事
- 用 SDLC 階段當骨架，而不是任務類型——8 個 slash command 對齊 8 個開發階段，24 個 Skill 全部有明確歸屬，不會變成一堆互相不知道彼此存在的散件。
Rationalizations區塊：與其信任模型「應該會做對」，不如先列出它可能找的藉口並逐一反駁——這比單純寫「請確實測試」更有效。- Verification 要具體、可檢查——測試通過、build 成功、runtime 資料，而不是「看起來沒問題」。