這篇是我自己的備忘錄：在 Claude Code 裡，我把每天反覆在做的工作流寫成了 8 支「旗艦」skill，從開一個新專案、寫功能、審程式碼、驗畫面、部署，一直到寫部落格發文。下面每支只講兩件事——它做什麼、它厲害在哪。
我認定「旗艦」的標準是：跨越一整段工作流、有多個階段、有明確的「完成」定義，而且會被我反覆當骨幹用。只做一個動作的薄殼指令（例如跑 build、推一次部署）不算。這 8 支在我的 plugin repo 裡都標了 flagship: true。
8 支旗艦 skill 一覽
| 工作階段 | skill | 一句話 |
|---|---|---|
| 開案 | /wez-cms-scaffold | 一條指令從範本開出整組前後端新專案 |
| 開案 | /springboot-init | 建立或升級公司標準 Spring Boot 服務 |
| 新專案開發 | /spec-flow | 規格驅動：節點 ID 一路串到線上驗收 |
| 日常開發 | /plan | 從需求到交付的整條龍，只停一次 |
| 收斂交付 | /review-and-clean | 審查加安全清理，分批可回復 |
| 前端閘門 | /screenshot-review | 逐張看截圖、修 code 重截，順便產手冊 |
| 部署 | /jenkins-docker | test 分支到上線驗收，附回滾文件 |
| 寫文 | /blog-create | 研究、查證、寫文、發布、線上驗證 |
開案：/wez-cms-scaffold 與 /springboot-init
/wez-cms-scaffold
功能
- 從公司的權限後台範本，一條指令開出
<代號>-backend與<代號>-web兩個專案。 - 流程固定是 doctor（檢查環境）→ clone 範本 → 把範本命名換成新案命名 →
git init並做第一個 commit。 - 加
--verify會跑後端測試、把服務真的起來打一次 ping，再跑前端 lint、typecheck、test。
- 它是一支確定性的 node 腳本，裡面沒有任何 AI 判斷，同樣的參數每次結果一樣。
- 驗證結果用數字回報。今天實跑一次：後端 82 個測試全過、ping 回來服務名與
UP都對、前端 330 個測試全過。 - 開出來的專案自帶
CLAUDE.md，裡面寫好公司共用 starter 的對照表、TDD 加 round-trip 的開發規範，之後的 AI 協作一開始就有規矩。
/springboot-init
功能
- 建立或升級一個公司標準的 Spring Boot 服務（Java 21、公司共用 starter）。
- 依目標路徑自動判斷模式：Create（全新）、Adopt（接手既有專案）、Docs-only（只補文件）、Ambiguous（看不出來就先問）。
- 中間有 Gate 1–5 五道關卡，一關過了才進下一關。
- 第一個功能切片走 TDD，要先秀出真的會紅的測試，不靠「把好程式改壞」來製造紅燈。
- build 綠不算完成，要實際打一次 HTTP 拿到預期回應才算。
- 接手既有專案時，不會盲目覆寫原本的
CLAUDE.md與README.md。
/springboot-init；要整套權限後台前後端用 /wez-cms-scaffold。
開發：/spec-flow、/plan、/review-and-clean
/spec-flow
功能
- 給從零開始的新專案或大功能用：先寫規則、流程、架構三份文件，再拆成帶 ID 的節點與驗收條件。
- 測試名稱帶
[ID-n]，跑flow:status會把每個節點的狀態自動回填成 ✅ 🟡 ❌ ⬜。 - Claude 寫、Codex review，最後用真瀏覽器驗證。
- 規格、測試、進度是同一條線串起來的，規格上每個節點做到哪，看狀態表就知道，不用人工維護。
- 上線驗收會比對頁面上的 commit 資訊與 main 分支的 SHA，確認線上跑的就是剛推的版本。
- 遊戲類專案會開兩個瀏覽器 context 實際打完一整局，不是只開首頁看有沒有 200。
/plan
功能
- 我收到實作型任務的起手式。流程 P0–P8：盤點並選模式 → 寫驗收契約（規格、實作位置、round-trip 怎麼驗）→ 請 Codex 畫 UI 參考圖 → 把計畫做成 HTML 上站。
- 計畫上站後是唯一一道確認閘門，我說 confirm 之後就一路跑完 TDD、前端截圖審查、完整 round-trip、code review、對帳。
- 另有「養計畫」模式：拿既有計畫跟程式碼對帳回填進度。
- 只停一次。confirm 之後遇到可逆的設計岔路它自己選，把「做了哪些決策、卡在哪、怎麼處理」寫進最後的決策與卡點日誌，我事後可以逐條翻案。
- 對帳不灌假的
[x]：沒有驗證證據的項目標 ⚠️，不會為了好看打勾。 - 驗收契約在動手前就寫好，「完成」的定義不會做到一半才改。
/review-and-clean
功能
- 功能做完、準備交付時用。流程 R0–R8：界定範圍並保存使用者現況 → 建 baseline → 證據式審查分級 → 分批修正。
- 批次順序固定：修 bug 與安全問題 → 清死碼 → 去重 → 必要的重構。每一批做完都驗證一次。
- 開工先保存我沒 commit 的修改，並且禁止用
git reset --hard、git clean、git checkout --回復批次，只准反向套它自己剛做的 patch。 - 一類風險一批：清死碼的批次不會順便改名，修漏洞的批次不會順便換架構，出事時知道是哪一批。
- 死碼分 SAFE／CAUTION／PROTECT 三級。刪之前要查動態引用、依賴注入、反射這些靜態工具看不到的引用，Spring 專案尤其需要。
驗收與部署：/screenshot-review、/jenkins-docker
/screenshot-review
功能
- 前端的品質閘門，常被
/plan與/review-and-clean呼叫，也可以單獨跑。 - 一個迴圈同時做三件事：找 bug、看 UI/UX、產或更新操作手冊。
- 有寫入資料庫的操作時會開 DB 軌：操作前後各存一次快照、比對差異、附上「SQL 加查詢結果」的資料庫截圖，還要配一個預期 DB 零變化的負向案例。
- 反橡皮圖章：每張截圖都真的打開來看，看到問題就改程式碼重截，不是修圖，一直循環到能說「邏輯合理、UI/UX 沒問題」才停。
- 四大支柱：精髓固化、記錄踩坑、手冊照同一份模板、用完自我學習。
- 它是 8 支裡唯一會自己演化的：跑完會提議回填新踩到的坑與手冊規範，我點頭才寫入，越用越準。
/jenkins-docker
功能
- 指定一個 repo：test 分支不存在就從 develop 建，修好部署檔，跑測試與建置，部署到目標主機，從對外網址驗收。
- 三種交付模式：A 自己部署到有權限的主機、B 整理成交付物給維運、C 本機驗證後再交給維運。
- 產出部署、驗收、回滾三份文件，還能接
/jenkins-docker-letter產給維運的交接信。
- 部署設定有機械檢查：
check-deploy.py --all以一份基準keys.yml當判準，逐項驗.env、compose、Dockerfile，不靠肉眼。 - 「部署完成」的定義是從對外網址看到服務正常，不是 Jenkins 顯示綠燈。
- 每次都留回滾文件，出事時照著做就能退回上一版。
寫文：/blog-create
功能
- 這個部落格每一篇正式文章的入口，你現在讀的這篇就是它發的。
- 流程 B0–B8：盤點 → 建 Evidence Brief（每個數字、版本、名稱都要有來源）→ 標題三件套 → 撰寫 → 內文圖與封面 → 發布前驗證 → 發布 → 線上驗證 → 回報。
- 寫作前先整理證據，「我實測」一定要有本機輸出或紀錄撐著，群體概括沒來源就刪。
- 有一道 150 分的 editorial gate，130 分以下不准發；標點、禁用詞也有機械 gate。
- 發布順序是先寫資料庫、成功後才 push，避免網站建置跟資料寫入賽跑；最後要在正式網址看到文章、圖片逐張 200、瀏覽器畫面正常，才算「已發布」。
這 8 支共通的設計
- 完成要看輸出端：build 綠、log 寫 success、process 起來都只是握手，要從使用者那端看到結果才算完成。
- 誠實對帳：沒驗過的就標沒驗過，不灌假勾、假分數、假截圖。
- 只在業務層停下來：可逆的實作決策自己選並記錄，不可逆或對外的動作才停下來問我。
- 能機械化的就機械化：會重複犯的錯改寫成腳本、gate 或測試，不靠「下次記得」。
想要這些 skill？
這 8 支是我依自己的工作環境寫的，其中幾支綁著公司內部的範本與共用模組，直接拿去不一定能跑，但流程設計與 gate 的寫法可以照抄。想要的話寫信到 bobchen184@gmail.com 跟我本人要，信裡說一下你想用在什麼專案，我比較好挑適合的給你。