跳至主要内容

Skills 即方法論

AppFuse 的開發方法論由 Claude Code Skills 組成。每個 Skill 對應一個開發活動，Skills 之間的前置條件形成品質閘門，串連成完整的開發流程。

團隊可以選擇完整採用所有 Skills，也可以選擇性採用部分 Skills，根據專案需求調整方法論的嚴格程度。

設計理念​

傳統方法論以文件描述流程，團隊靠紀律遵循。AppFuse 將方法論嵌入工具：

傳統方法論Skills 即方法論
「US 寫完後要跑品質檢核」/impl 拒絕在沒有 checklist 的情況下啟動
「開發前需確認 SBE 場景」/impl 自動載入 SBE 作為實作依據
「上游文檔變更後要重新評估下游影響」/impl 偵測 depends_on 上游變更並發出警告

方法論不再只是「建議遵循的流程」，而是內建於工具的行為。團隊不需要記住流程——使用 Skill 時，流程自然發生。

Rules 與 Skills 的職責分工​

AppFuse 的 Claude Code Rules（.claude/rules/）分為兩類，以檔名前綴區分：

前綴類型性質範例
00- ~ 04-基礎設施 / 框架技術事實，所有模式都適用語言設定、commit 規範、架構說明、版本策略
m-方法論資訊性說明，描述格式與用途文檔版本定義、依賴追蹤格式、模組角色說明

關鍵原則：

  • Rules 只提供資訊（定義、格式、位置、用途），不包含「必須」「不得」等強制約束
  • Skills 負責執行（前置條件檢查、品質閘門、開發護欄）
  • 不使用 Skills 時，Rules 的方法論內容僅供參考，不會限制開發者的行為

這個設計確保了選擇性採用的可行性：團隊可以閱讀 m- 開頭的 rules 了解方法論的概念，但只有在使用對應的 Skill 時才會觸發強制約束。

兩種採用模式​

模式一：完整採用​

使用所有 Skills，享受完整的品質閘門保障。適合重視規格品質、需要嚴謹開發流程的團隊。

/roadmap → /epic → /us → /sbe
                            ↓
              /checklist → /assess → published
                                        ↓
              /domain-model + /api-spec → /e2e → /impl → /uat → /progress → ✅

特點：

  • 品質閘門自動執行，不依賴人的記憶
  • 文檔鏈完整可追溯（Roadmap → Epic → US → SBE → 程式碼）
  • 變更影響自動偵測（/impact、depends_on）
  • 進度追蹤自動連鎖更新（/progress 同步 Feature List）

模式二：選擇性採用​

只使用部分 Skills，其餘流程由團隊自行處理。適合有既有流程、或處於探索階段的團隊。

常見的選擇性組合：

組合使用的 Skills自行處理
只用規格工具/us、/sbe、/checklist手動開發、手動測試
只用測試工具/e2e、/test-plan手動撰寫規格
只用追蹤工具/sprint、/progress、/next手動撰寫規格、手動開發
規格 + 開發/us、/sbe、/e2e、/impl跳過品質檢核

:::tip 漸進式採用 團隊不必一開始就全採用。建議從規格撰寫工具（/us、/sbe）開始，體驗 AI 協助的澄清循環，再逐步加入品質檢核與自動化實作。 :::

品質閘門鏈​

完整採用模式下，Skills 之間的前置條件形成三道品質閘門：

閘門一：規格品質（/checklist + /assess → published）​

/us → /sbe → /checklist → /assess → version: published
  • /checklist 從 7 個維度檢核 US 品質
  • /assess 以 Persona 視角評估文檔，完成修訂後標記為 published
  • 只有 published 的 US 才能進入實作階段

閘門二：實作就緒（/impl 前置條件）​

/impl 啟動時自動檢查：

檢查項目不通過時
US 版本為 published拒絕啟動
Checklist 報告存在拒絕啟動
Assess 摘要存在拒絕啟動
SBE 場景完備拒絕啟動
上游文檔未變更發出警告

閘門三：驗收就緒（/uat 前置條件）​

/uat 啟動時自動檢查：

檢查項目不通過時
US 階段為 P.E2E拒絕啟動
US 版本非 reference拒絕啟動
測試指南存在建議先跑 /test-plan

Skill 分類與入口​

入口級 Skills（無前置條件）​

這些 Skills 可以獨立使用，是選擇性採用的基礎：

Skill用途產出
/roadmap產品路線圖roadmap.md + feature-list.md
/epicEpic 文檔epic-{N}-{name}.md
/usUser StoryUS-{NNN}-{name}.md
/sbeSBE 場景scenario-{N}-{description}.md
/domain-model領域模型domain-model.md
/checklist品質檢核（唯讀）檢核報告
/analyze一致性分析（唯讀）分析報告
/sprintSprint 規劃sprint-{N}.md
/next工作建議建議清單

閘門級 Skills（有前置條件）​

這些 Skills 有嚴格的前置條件，是品質保障的核心：

Skill前置條件用途
/implUS published + checklist + assess + SBE依規格實作功能
/uatUS 階段 ≥ P.E2E互動式驗收測試

輔助級 Skills（增強工具）​

這些 Skills 增強開發體驗，但不在閘門鏈上：

Skill用途
/e2e從 SBE 產生 E2E 測試
/test-plan產生手動測試指南
/api-spec設計或萃取 API 規格
/assessPersona 視角評估
/progress階段推進與追蹤
/impact變更影響分析
/code-review程式碼審查

選擇性採用的影響​

選擇性採用時，團隊需要自行承擔跳過的環節：

跳過的 Skill團隊需自行負責
/checklist + /assess手動確保 US 品質，/impl 無法使用（需 published）
/sbe手動定義測試場景，/e2e 與 /impl 無法使用
/domain-model + /api-spec手動設計資料模型與 API 合約
/progress手動更新 Feature List 與 Sprint 進度
/impact手動追蹤上游變更的下游影響

:::note 關鍵觀察 /impl 是閘門最嚴格的 Skill——它要求規格鏈完整（US published + checklist + assess + SBE）。如果團隊想使用 /impl 進行 AI 協助開發，就必須先完成規格品質流程。這是刻意的設計：確保 AI 實作時有足夠的上下文與驗證依據。 :::

與開發流程的關係​

Skills 即方法論建立在 開發流程指南 定義的 4-Step 模型之上：

開發 Step相關 Skills
規格撰寫（Step 1 之前）/roadmap、/epic、/us、/sbe、/checklist、/assess
Step 1：Prototype/e2e、/impl（web-mockup）、/uat、/progress
Step 2–3：整合/api-spec、/impl（server / web）、/progress
Step 4：部署/deploy、/progress
跨階段/sprint、/next、/analyze、/impact、/code-review

Skills 不取代開發流程，而是讓流程中的每個活動有對應的工具支援。

新團隊建議​

  1. 第一個 Sprint：從 /roadmap → /epic → /us → /sbe 開始，體驗規格撰寫流程
  2. 第二個 Sprint：加入 /checklist → /assess，建立品質檢核習慣
  3. 第三個 Sprint：加入 /e2e → /impl → /uat，完整走過閘門鏈
  4. 持續改進：根據團隊回饋，決定哪些 Skills 帶來最大價值

詳細的上手指南請參閱 方法論總覽 的「新團隊上手指南」章節。

相關資源​

文檔說明
開發流程指南4-Step 開發流程與 US 階段追蹤模型
Claude Code Skills 總覽所有 Skills 的快速參考索引
AI 協助規格撰寫蘇格拉底式閉環模型與使用指南
ADR-001: AI 協助規格撰寫策略採用 AI 協助模式的決策記錄