❯❯ 載具解析：同一種機制，完全不同的玩法

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 上線（今日：底盤，撐著整條線的東西）

前三天梳理了整體架構地圖，今天要往下看一層：這條路是用什麼鋪出來的？

自下一篇起，流程中將頻繁出現如 /feature-to-flow 等自動化指令。先把兩個詞的關係講清楚：

• Skill 是封裝在專案 .claude/skills/ 目錄下的工作規範檔案；
• 斜線指令（slash command） 則是它的觸發入口。

在對話中輸入 /feature-to-flow，就是要求模型載入 feature-to-flow 這支 Skill、依其規範執行，兩者是同一件事的檔案面與操作面。這些指令並非複雜的黑盒，而是結構化的自動化工作說明書（Standard Operating Procedures, SOP）。預先釐清其運作機制，有助於後續跟進整套流水線的實作細節。

Skill 的核心機制

仔細拆解 Skill 的本質，它其實就是封裝在資料夾內的結構化 Prompt 與工作規範：以純文字檔案形式明確定義「特定階段的執行步驟、約束條件與產出規格」。當 LLM 執行到特定任務時便會載入對應 Skill，並依據定義的規範執行。

相較於隨手臨機撰寫的單次 Prompt，採用 Skill 機制具備三項工程優勢：

1. 可重複性（Repeatability）：
   確保不同時間點、不同人執行的產出品質，都能維持高度的一致性。
2. 可版本控制（Version Control）：
   作為 Git 儲存庫中的實體檔案，所有異動都可以被追蹤、比對（Diff）甚至精確回滾（Revert）。
3. 團隊知識轉移（Knowledge Transfer）：
   將原本只存在於個人腦中的開發流程顯性化，轉為自動化指令，大幅降低團隊成員之間的口頭交接成本。

當後續有其他工程師接手專案時，只需讓模型讀取 Skill 的設計脈絡，或透過 /sdd-status 查看當前階段，即可無縫銜接開發流程。

Skill 的雙軌分類與 Context 治理

打開婚禮專案的 .claude/skills/，目錄下的 Skill，其結構分為兩大類型：

1. 流程 skill 是我自己寫的，負責串接整條自動化流水線：

2. 知識 Skill：直接整合生態系現成之領域知識。vue、nuxt、pinia 三支直接採用 Anthony Fu 維護的社群版本（由 antfu/skills 依官方文件生成），框架語法更新與邊界案例由社群維護者持續跟進；nuxt-ui 則是自己寫的薄殼，負責在要動元件前把官方文檔載進來，避免模型憑記憶寫出過時語法。無論哪一種，開發者都能專注於業務邏輯與衝突裁決，無須重複建構已成熟的技術棧規範。

以上述表格中的 test 為例，它是隨著開發過程持續擴充的規範指令集。
在其 E2E 模組底下，一共掛載了七份規範文件，精確對應 E2E 開發的各個工作階段：

• setup.md (/test e2e setup)：建立測試基礎架構
• spec.md (/test e2e spec)：將 .flow.md 轉譯為 .spec.ts 測試檔
• red.md (/test e2e red)：執行測試並收集失敗清單（紅燈）
• green.md (/test e2e green)：修復程式碼至全數通過（綠燈）
• pipeline.md (/test e2e pipeline)：執行批次與完整測試流程
• detect.md (/test e2e)：自動偵測並執行當前應進行的階段（不帶子指令時的預設行為）
• handwritten.md (/test e2e handwritten)：視覺樣式與 Vibe 測試

指令結構說明：
這裡的 test 是 Skill 本體，e2e 是傳入的第一個參數，後面接的則是子指令（如 setup）。它們是一個組合指令，而非兩個獨立的 Skill。

此外，系統包含 references 機制：將 Skill 執行過程所需的大型參考文件（如各階段的執行規範、共用規則、元件範例程式碼）自主文件中抽離，僅於執行至特定步驟時動態載入。此設計主要解決 Context Engineering（上下文工程）的優化問題，精確控制模型於各階段接收到的資訊範疇與載入順序，避免單次載入過多上下文造成模型注意力分散或邏輯偏離。

--

都是 Skill，卻有三種不同的玩法

Skill 作為通用載具，在不同團隊與應用場景下，自然會演化出全然不同的實務路線：

• 第一種：知識疊加與 Prompt 鏈結
  某些團隊設有專職撰寫 Skill 的角色。開發前期先進行資料研究與商業邏輯鋪設，隨後運用涵蓋不同知識領域的基礎 Skill，疊加生成下一階段的進階 Skill，最終基於累積的知識體系進行開發。這種模式能確保每一步驟均建立於前期驗證的知識基礎上。
• 第二種：全端能力封裝
  資深工程師可以建構覆蓋面極廣的知識 Skill 庫，開發時自己只需專注在工作流控制，在不同階段敲入對應的 Skill，一個人就能發揮出高純度的全端開發能力。
• 第三種：固定工程流水線（本系列採行模式）
  將開發階段收斂為標準化的流水線，透過嚴格的閘門（Gate）控制與測試驅動，確保程式碼產出的品質與可維護性。

這條流水線的設計核心是 input/output 鏈結：每一支 Skill 的 output，直接就是下一支 Skill 的 input。規格產出 flow → flow 產出型別合約 → 型別合約再往下長出 mock 與測試，一棒接一棒往下傳，而不是各自獨立呼叫。

仔細對比就會發現，第一種做法「疊加知識」與我們第三種「疊加工程產物」，底層其實貫穿著同一套哲學：後一步永遠吃前一步的輸出。差別只在於：他們疊加的是抽象的領域知識，而我們疊加的是具體的規格、型別與測試合約。

這三條路徑各有其最適合的舞台。工具本身只提供能力，至於要怎麼用，具體的應用型態終究取決於團隊的組織架構、專案規模與邊界約束。

結語

在接下來的章節中，即使你完全不熟悉 Skill 的語法細節也沒關係。我會優先拆解每一個工程節點背後的思考邏輯與架構設計；畢竟 Skill 只是將這些工程思想實體化的容器。只要搞懂了底層的運作脈絡，你的團隊完全可以自由選擇最順手的載具去實作落地。

明日將正式進入工程流水線的第一站：雙軌入口的設計與選擇。

📎 本篇證據｜.claude/skills/ 目錄（包含 Skill 實體檔案，公開於專案儲存庫中）