三器合一：gstack + Superpowers + OpenSpec 工程化 AI 編程實戰

作者：AgentBuff
日期：2026年5月12日 下午6:04
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

三器合一：OpenSpec、Superpowers、gstack 自動串聯嘅全流程AI編程

整理版摘要

呢篇文章介紹咗三個AI編程工具——OpenSpec、Superpowers、gstack——係點樣整合使用，形成一條由需求、編碼到發佈嘅全自動管道。作者從實戰角度，用一個「加暗色模式」嘅例子，清楚說明每個工具嘅角色同埋佢哋之間嘅串聯機制。

核心觀點係：三個工具唔係各自為政，而係喺同一個Claude Code會話入面自動生效、互相補位。OpenSpec喺寫code之前鎖住需求，Superpowers喺寫code嘅時候卡住質量，gstack喺寫完code之後包辦發佈。開發者只需要輸入七個斜槓命令，背後嘅串聯全部自動完成。

作者仲特別強調四個串聯點：OpenSpec嘅產物落盤後，gstack直接讀取做評審；Superpowers嘅HARD-GATE用OpenSpec嘅design作為批准條件；Superpowers嘅TDD鐵律確保每個功能都有測試，令gstack嘅review質素更高；最後gstack嘅/ship完成發佈，OpenSpec嘅歸檔收尾。呢套機制避免咗重複門禁，統一咗需求真相源，同埋提供咗例外情況處理。

  • 結論：三個工具分工明確——OpenSpec管需求、Superpowers管質量、gstack管流程，關鍵係自動串聯唔係手動接力。
  • 方法：七個命令一條龍——/opsx:propose→/autoplan→寫code→/review→/qa→/ship→/opsx:archive，背後自動執行評審、測試、發佈、歸檔。
  • 差異：每個工具管唔同層次，互不重疊；兩道門禁（Superpowers HARD-GATE 同 gstack review）需要協調，避免重複。
  • 啟發：工具整合嘅真正價值唔係功能疊加，而係規則自發銜接，開發者可以專注決策唔使操心流程。
  • 可行動點：安裝三個工具，先用OpenSpec寫proposal，再用gstack /autoplan評審，寫code時Superpowers自動執行TDD，最後/ship上線後歸檔。
結構示例

內容結構

內容結構 text 
Do NOT invoke any implementation skill, write any code, scaffoldany project, or take any implementation action until you havepresented a design and the user has approved it.
整理重點

工具角色與串聯核心

呢三個工具分別解決三個唔同問題：OpenSpec用DAG 產物依賴圖管需求，Superpowers用HARD-GATE加TDD 鐵律管質量，gstack用Browse 引擎加7 階段 Sprint 管線管全流程。關鍵唔係「三個工具都裝上」，而係佢哋之間點樣自動串聯。

DAG 產物依賴圖

HARD-GATE

TDD 鐵律

Browse 引擎

7 階段 Sprint 管線

自動串聯

整理重點

四個串聯點

三個工具之間有四條關鍵串聯線，確保數據同控制權自動流轉。

  1. 1 OpenSpec嘅產物落盤後，gstack嘅/autoplan直接讀取文件做評審，無需手動傳遞。
  2. 2 Superpowers嘅HARD-GATE將OpenSpec嘅design.md視為「已批准設計」，自動放行編碼。
  3. 3 Superpowers嘅TDD鐵律確保每個功能有測試，gstack嘅/review審查時可以用測試做行為契約，質素更高。
  4. 4 gstack嘅/ship發佈後，OpenSpec嘅/opsx:archive讀取Delta規範合入主規範並歸檔變更。

/autoplan直接讀取文件

HARD-GATE自動放行

行為契約

Delta規範

整理重點

完整案例：加暗色模式

以下用一個「加暗色模式」嘅功能，展示七個命令點樣串聯成完整管道。

  1. 1 /opsx:propose — OpenSpec生成proposal、specs、design、tasks四個文件。
  2. 2 /autoplan — gstack啟動四類評審，讀取OpenSpec產物，鎖定設計約束。
  3. 3 寫code — Superpowers TDD鐵律自動執行，先寫測試後寫code。
  4. 4 /review — gstack掃描diff，結合測試找出生產級bug。
  5. 5 /qa — gstack用Playwright做真實瀏覽器驗收。
  6. 6 /ship — gstack自動版本升級、生成CHANGELOG、創建PR並部署。
  7. 7 /opsx:archive — OpenSpec將Delta規範合入主規範，歸檔變更。

DAG引擎解析依賴

HARD-GATE檢查設計

TDD鐵律自動攔截

真實瀏覽器驗收

VERSION升級

CHANGELOG生成

整理重點

避坑指南與總結

  • 唔好重複門禁：Superpowers嘅HARD-GATE已經卡住設計，唔使再額外用gstack嘅/plan-design-review。
  • specs/係唯一真相源：需求衝突時以OpenSpec嘅specs為準，gstack嘅設計文件只描述實現細節。
  • /ship係唯一發佈出口：OpenSpec歸檔只係記錄，唔係發佈。
  • TDD有三個例外：一次性原型、生成代碼、配置文件可以跳過TDD。
圖片

OpenSpec 管需求，Superpowers 管質素，gstack 管成個流程

三個工具解決三個唔同嘅問題，裝埋一齊冇衝突：

工具管什麼核心機制
OpenSpec做什麼DAG 產物依賴圖，寫 code 之前先對齊需求
Superpowers做得好HARD-GATE + TDD 鐵律，自動攔截低質素 code
gstack點做、點發佈Browse 引擎 + 7 階段 Sprint 管線

關鍵唔係「三個工具都裝曬」，而係佢哋之間點樣自動串聯。下面用一個完整案例講清楚。

安裝：三者共存嘅方式

圖片

裝完之後，三個工具喺同一個 Claude Code 會話入面共存。OpenSpec 嘅 /opsx:* 命令、Superpowers 嘅 TDD 鐵律、gstack 嘅 /ship /review /qa 技能，全部喺同一個 REPL 入面用得。

佢哋唔會互相覆蓋，因為管嘅層次唔同。OpenSpec 嘅產物存在 openspec/ 目錄，Superpowers 嘅規則存在 CLAUDE.md 同 skill 文件入面，gstack 嘅狀態存在 .gstack/ 目錄。三套狀態互不幹擾。

核心問題：佢哋之間點樣串聯

圖片

呢個係最關鍵嘅部分。三個工具唔係「你用完成我用」嘅接力賽，而係喺同一個會話入面自動觸發、互相銜接。

#串聯點 1：OpenSpec 嘅產物 → gstack 嘅評審輸入

OpenSpec 嘅 /opsx:propose 會生成四個文件：proposal.md、specs/、design.md、tasks.md。呢啲文件寫入磁碟之後，gstack 嘅 /autoplan 可以直接讀取佢哋作為評審輸入。

具體機制：/autoplan 啟動 CEO → design → eng → DX 四類評審。每個評審角色會讀取當前工作區嘅文件。因為 OpenSpec 嘅產物就喺 openspec/changes// 目錄下，評審角色自然讀到 proposal 同 specs。

你唔需要手動複製貼上。OpenSpec 寫完產物，gstack 嘅評審直接讀文件。

#串聯點 2：Superpowers 嘅 HARD-GATE → 自動攔截編碼

Superpowers 嘅 brainstorming skill 有一個 HARD-GATE：

Do NOT invoke any implementation skill, write any code, scaffold

any project, or take any implementation action until you have

presented a design and the user has approved it.

呢個意味住：就算你跳過 OpenSpec 直接話「幫我加個功能」，Superpowers 都會強制你先行設計流程。佢唔需要知道 OpenSpec 嘅存在——佢只關心「設計有冇被批准」。

如果 OpenSpec 已經生成了 design.md，你將佢展示畀 Superpowers 睇，佢會將呢份設計當作「已批准嘅設計」，HARD-GATE 自動放行。呢個就係串聯：OpenSpec 嘅產物滿足咗 Superpowers 嘅門禁條件。

#串聯點 3：Superpowers 嘅 TDD → gstack 嘅 /review 自動生效

Superpowers 嘅 TDD 鐵律要求「先寫失敗測試再寫 code」。呢個過程唔需要你手動觸發——佢係 skill 文件入面嘅規則，Claude Code 每次寫 code 時自動遵守。

寫完 code 之後，你執行 gstack 嘅 /review。/review 唔關心 code 係點寫出嚟——佢只睇 diff。但佢會發現：因為 TDD 鐵律嘅存在，每個功能都有對應嘅測試。/review 嘅審查質素因此更高，因為佢有測試作為行為契約。

#串聯點 4：gstack 嘅 /ship → OpenSpec 嘅 /opsx:archive

/ship 發佈完成之後，你執行 /opsx:archive。歸檔過程讀取 openspec/changes// 下面嘅 Delta 規範，自動合併到 openspec/specs/ 主規範入面。

歸檔唔觸發發佈，發佈唔觸發歸檔。佢哋係兩個獨立步驟，但順序固定：先 /ship 上線，再 /opsx:archive 收尾。

舉個例子：畀應用加暗色模式

一個功能從想法到上線嘅完整流程。重點唔係「做咗啲乜」，而係每一步點樣觸發下一步、工具之間點樣銜接。

#第 1 步：OpenSpec 生成需求產物

/opsx:propose add-dark-mode
給應用加暗色模式：

1. 設置頁加主題切換開關

2. 支持跟隨系統偏好

3. 用戶選擇持久化到 localStorage

4. 所有頁面即時切換

OpenSpec 嘅 DAG 引擎解析依賴關係，自動生成四個產物：

openspec/changes/add-dark-mode/

├── proposal.md          ← 為什麼做

├── specs/ui/spec.md     ← 需求場景（GIVEN/WHEN/THEN）

├── design.md            ← 技術方案（CSS 變量 + Context）

├── tasks.md             ← 任務清單（4 組 8 個子任務）

└── .openspec.yaml       ← 變更元數據

DAG 引擎話畀你知：proposal 已完成，specs 同 design 可以並行創建，tasks 要等佢哋都完成先可以開始。你唔需要手動管理呢個順序——/opsx:propose 一次性生成曬全部產物。

串聯觸發： 產物寫入磁碟之後，gstack 嘅評審角色可以直接讀取呢啲文件。

#第 2 步：gstack /autoplan 讀取產物做評審

/autoplan

/autoplan 自動串起四類評審。每個評審角色讀取 openspec/changes/add-dark-mode/ 下面嘅文件：

  • CEO 評審讀 proposal.md：暗色模式係咪當前優先級最高嘅？範圍係咪合理？
  • 工程評審讀 design.md：CSS 變量方案嘅瀏覽器兼容性？Context Provider 嘅性能影響？
  • 設計評審讀 specs/ui/spec.md：暗色模式嘅色彩對比度係咪符合 WCAG 標準？
  • DX 評審讀 tasks.md：任務拆分係咪合理？其他開發者能否擴展暗色主題？

評審結論寫入 gstack 嘅計劃文件，鎖住設計約束：必須用 CSS 自定義屬性，唔可以用 CSS-in-JS。

串聯觸發： 評審通過後，進入編碼階段。此時 Superpowers 嘅 HARD-GATE 檢查「設計係咪已批准」——OpenSpec 嘅 design.md + gstack 嘅評審結論滿足咗條件，HARD-GATE 自動放行。

#第 3 步：Superpowers TDD 鐵律自動生效

你冇手動調用 Superpowers 嘅任何命令。TDD 鐵律係 skill 文件入面嘅規則，Claude Code 寫 code 時自動遵守。

開始實現 tasks.md 入面嘅第一個任務「創建 ThemeContext」：

圖片

子代理驅動（如果啟用）：每個 tasks.md 入面嘅任務用一個全新嘅子代理執行。子代理讀取 openspec/changes/add-dark-mode/specs/ui/spec.md 作為需求輸入，讀取 design.md 作為技術約束。執行完之後做兩階段審查：先查係咪符合 specs/，再查 code 質素。

串聯觸發： 所有任務實現完成後，執行 gstack 嘅 /review。

#第 4 步：gstack /review 審查 code

/review

/review 掃描當前分支嘅 diff。因為 Superpowers 嘅 TDD 鐵律確保咗每個功能都有測試，/review 嘅審查質素更高——佢可以用測試作為行為契約來驗證實現係咪正確。

/review 揾出一個問題：localStorage.setItem 冇 try-catch，喺 Safari 私隱模式下會拋異常。修復後繼續。

串聯觸發： 審查通過後，執行 /qa 做真實瀏覽器驗收。

#第 5 步：gstack /qa 瀏覽器驗收

/qa

/qa 用 Playwright Chromium 打開應用，執行真實用戶操作：

  1. $B goto http://localhost:3000/settings — 打開設置頁
  2. $B snapshot -i — 獲取可訪問性快照，找到主題切換開關
  3. $B click @e5 — 點擊切換開關
  4. $B screenshot — 截圖驗證暗色模式生效
  5. $B reload — 刷新頁面
  6. $B screenshot — 驗證主題持久化
  7. $B eval prefers-color-scheme — 驗證跟隨系統偏好

QA 報告發現 3 個頁面嘅對比度唔達標。修復後重新驗證，全部通過。

串聯觸發： QA 通過後，執行 /ship。

#第 6 步：gstack /ship 發佈

/ship

/ship 自動執行一系列操作：

  1. git fetch origin main — 同步遠程
  2. bun test — 跑免費測試
  3. 覆蓋率審計 — 檢查新增 code 嘅測試覆蓋
  4. VERSION 升級 — v1.5.0.0 → v1.6.0.0（MINOR，因為係新功能）
  5. CHANGELOG 生成 — 從 git log 提取變更摘要
  6. git push — 推送 code
  7. gh pr create — 創建 PR
/land-and-deploy

合併 PR、等 CI、部署到生產環境。

/canary

監控部署後 30 分鐘嘅錯誤率同性能指標。

串聯觸發： 發佈完成後，執行 OpenSpec 嘅歸檔。

#第 7 步：OpenSpec /opsx:archive 歸檔

/opsx:archive add-dark-mode

歸檔過程：

  1. 讀取 openspec/changes/add-dark-mode/specs/ui/spec.md 裏面嘅 Delta 規範
  2. ## ADDED Requirements 追加到 openspec/specs/ui/spec.md
  3. ## MODIFIED Requirements 取代主規範入面同名嘅需求
  4. 變更文件夾移入 openspec/changes/archive/2026-05-12-add-dark-mode/

歸檔後，openspec/specs/ 目錄始終反映系統當前狀態。下次再加功能時，OpenSpec 嘅 AI 會讀取呢啲 specs 作為上下文。

串聯機制

成個流程入面，你手動輸入嘅命令得 7 個：

/opsx:propose → /autoplan → (寫代碼) → /review → /qa → /ship → /opsx:archive

但背後自動發生嘅嘢遠不止呢啲：

你輸入嘅自動發生嘅
/opsx:proposeDAG 引擎解析依賴，生成 4 個產物文件
/autoplan4 個評審角色讀取 OpenSpec 產物，輸出評審結論
（寫 code）Superpowers HARD-GATE 檢查設計係咪批准（係），TDD 鐵律自動攔截（先寫測試）
/reviewgstack 讀取 diff + 測試，揾出生產級 bug
/qaPlaywright Chromium 執行真實瀏覽器操作
/shipVERSION + CHANGELOG + PR + 推送
/opsx:archiveDelta 規範合入主規範，歸檔變更

三個工具之間嘅銜接唔需要你手動傳遞數據。OpenSpec 嘅產物寫入磁碟後，gstack 嘅評審角色直接讀文件。gstack 嘅評審結論滿足咗 Superpowers 嘅 HARD-GATE 條件。Superpowers 嘅 TDD 鐵律確保咗 /review 有測試可以依靠。

呢個就係「三器合一」嘅核心：唔係三個獨立工具嘅拼湊，而係三套規則喺同一個會話入面自動生效、互相補位。

避坑指南

唔好重複門禁。 Superpowers 嘅 HARD-GATE 已經卡住設計審批，就唔好再用 gstack 嘅 /plan-design-review 重複審查同一份設計。兩套門禁同時行會出矛盾。推薦：Superpowers 管設計門禁（更嚴），gstack 管 code 審查（有瀏覽器驗證）。

specs/ 係唯一真相源。 OpenSpec 嘅 openspec/specs/ 定義需求，gstack 嘅設計文檔只描述實現細節。需求有衝突時以 specs/ 為準。

/ship 係唯一發佈出口。 OpenSpec 歸檔只係收尾記錄，唔係發佈。所有 code 通過 gstack 嘅 /ship 流向生產。

TDD 有三個例外。 一次性原型、生成嘅 code、配置文件——呢三種場景可以同 AI 講「呢個係原型，跳過 TDD」。除此之外，Superpowers 嘅鐵律唔打折扣。

總結

OpenSpec 喺寫 code 之前將需求鎖住，Superpowers 喺寫 code 嘅時候將質素卡住，gstack 喺寫完 code 之後將發佈包辦。三套規則同一個會話入面自動生效，你淨係輸入斜槓命令，剩下嘅串聯係自動嘅。

最後圖片
同時畀大家推薦一個中轉站，我自己都用緊：https://api.bjxrouter.com/register?aff=ffOu，充值後截圖，充 100 我再通過我嘅渠道額外贈送 50 到大家賬號裏
注意先加我微信好友：coderbuffer
圖片

OpenSpec 管需求，Superpowers 管質量，gstack 管全流程

三個工具解決三個不同的問題，裝在一起不衝突：

工具管什麼核心機制
OpenSpec做什麼DAG 產物依賴圖，寫代碼前先對齊需求
Superpowers做得好HARD-GATE + TDD 鐵律，自動攔截低質量代碼
gstack怎麼做、怎麼發Browse 引擎 + 7 階段 Sprint 管線

關鍵不是"三個工具都裝上"，而是它們之間怎麼自動串聯。下面用一個完整案例講清楚。

安裝：三者共存的方式

圖片

裝完之後，三個工具在同一個 Claude Code 會話裏共存。OpenSpec 的 /opsx:* 命令、Superpowers 的 TDD 鐵律、gstack 的 /ship /review /qa 技能，全部在同一個 REPL 裏可用。

它們不互相覆蓋，因為管的層次不同。OpenSpec 的產物存在 openspec/ 目錄，Superpowers 的規則存在 CLAUDE.md 和 skill 文件裏，gstack 的狀態存在 .gstack/ 目錄。三套狀態互不干擾。

核心問題：它們之間怎麼串聯

圖片

這是最關鍵的部分。三個工具不是"你用完我再用"的接力賽，而是在同一個會話裏自動觸發、互相銜接。

#串聯點 1：OpenSpec 的產物 → gstack 的評審輸入

OpenSpec 的 /opsx:propose 會生成四個文件：proposal.md、specs/、design.md、tasks.md。這些文件落盤後，gstack 的 /autoplan 能直接讀取它們作為評審輸入。

具體機制：/autoplan 啓動 CEO → design → eng → DX 四類評審。每個評審角色會讀取當前工作區的文件。因為 OpenSpec 的產物就在 openspec/changes// 目錄下，評審角色自然能讀到 proposal 和 specs。

你不需要手動複製粘貼。OpenSpec 寫完產物，gstack 的評審直接讀文件。

#串聯點 2：Superpowers 的 HARD-GATE → 自動攔截編碼

Superpowers 的 brainstorming skill 有一個 HARD-GATE：

Do NOT invoke any implementation skill, write any code, scaffold

any project, or take any implementation action until you have

presented a design and the user has approved it.

這意味着：即使你跳過了 OpenSpec 直接說"幫我加個功能"，Superpowers 也會強制你先走設計流程。它不需要知道 OpenSpec 的存在——它只關心"設計有沒有被批准"。

如果 OpenSpec 已經生成了 design.md，你把它展示給 Superpowers 看，它會把這份設計當作"已批准的設計"，HARD-GATE 自動放行。這就是串聯：OpenSpec 的產物滿足了 Superpowers 的門禁條件。

#串聯點 3：Superpowers 的 TDD → gstack 的 /review 自動生效

Superpowers 的 TDD 鐵律要求"先寫失敗測試再寫代碼"。這個過程不需要你手動觸發——它是 skill 文件裏的規則，Claude Code 每次寫代碼時自動遵守。

寫完代碼後，你運行 gstack 的 /review。/review 不關心代碼是怎麼寫出來的——它只看 diff。但它會發現：因為 TDD 鐵律的存在，每個功能都有對應的測試。/review 的審查質量因此更高，因為它有測試作為行為契約。

#串聯點 4：gstack 的 /ship → OpenSpec 的 /opsx:archive

/ship 發佈完成後，你運行 /opsx:archive。歸檔過程讀取 openspec/changes// 下的 Delta 規範，自動合併到 openspec/specs/ 主規範裏。

歸檔不觸發發佈，發佈不觸發歸檔。它們是兩個獨立步驟，但順序固定：先 /ship 上線，再 /opsx:archive 收尾。

舉個例子：給應用加暗色模式

一個功能從想法到上線的完整流程。重點不是"做了什麼"，而是每一步怎麼觸發下一步、工具之間怎麼銜接。

#第 1 步：OpenSpec 生成需求產物

/opsx:propose add-dark-mode
給應用加暗色模式：

1. 設置頁加主題切換開關

2. 支持跟隨系統偏好

3. 用戶選擇持久化到 localStorage

4. 所有頁面即時切換

OpenSpec 的 DAG 引擎解析依賴關係，自動生成四個產物：

openspec/changes/add-dark-mode/

├── proposal.md          ← 為什麼做

├── specs/ui/spec.md     ← 需求場景（GIVEN/WHEN/THEN）

├── design.md            ← 技術方案（CSS 變量 + Context）

├── tasks.md             ← 任務清單（4 組 8 個子任務）

└── .openspec.yaml       ← 變更元數據

DAG 引擎告訴你：proposal 已完成，specs 和 design 可以並行創建，tasks 等它們都完成才能開始。你不需要手動管理這個順序——/opsx:propose 一次性生成全部產物。

串聯觸發： 產物落盤後，gstack 的評審角色可以直接讀取這些文件。

#第 2 步：gstack /autoplan 讀取產物做評審

/autoplan

/autoplan 自動串起四類評審。每個評審角色讀取 openspec/changes/add-dark-mode/ 下的文件：

  • CEO 評審讀 proposal.md：暗色模式是不是當前優先級最高的？範圍是否合理？
  • 工程評審讀 design.md：CSS 變量方案的瀏覽器兼容性？Context Provider 的性能影響？
  • 設計評審讀 specs/ui/spec.md：暗色模式的色彩對比度是否符合 WCAG 標準？
  • DX 評審讀 tasks.md：任務拆分是否合理？其他開發者能否擴展暗色主題？

評審結論寫入 gstack 的計劃文件，鎖住設計約束：必須用 CSS 自定義屬性，不能用 CSS-in-JS。

串聯觸發： 評審通過後，進入編碼階段。此時 Superpowers 的 HARD-GATE 檢查"設計是否已批准"——OpenSpec 的 design.md + gstack 的評審結論滿足了這個條件，HARD-GATE 自動放行。

#第 3 步：Superpowers TDD 鐵律自動生效

你沒有手動調用 Superpowers 的任何命令。TDD 鐵律是 skill 文件裏的規則，Claude Code 寫代碼時自動遵守。

開始實現 tasks.md 裏的第一個任務"創建 ThemeContext"：

圖片

子代理驅動（如果啓用）：每個 tasks.md 裏的任務用一個全新的子代理執行。子代理讀取 openspec/changes/add-dark-mode/specs/ui/spec.md 作為需求輸入，讀取 design.md 作為技術約束。執行完後做兩階段審查：先查是否符合 specs/，再查代碼質量。

串聯觸發： 所有任務實現完成後，運行 gstack 的 /review。

#第 4 步：gstack /review 審查代碼

/review

/review 掃描當前分支的 diff。因為 Superpowers 的 TDD 鐵律確保了每個功能都有測試，/review 的審查質量更高——它可以用測試作為行為契約來驗證實現是否正確。

/review 找出一個問題：localStorage.setItem 沒有 try-catch，在 Safari 隱私模式下會拋異常。修復後繼續。

串聯觸發： 審查通過後，運行 /qa 做真實瀏覽器驗收。

#第 5 步：gstack /qa 瀏覽器驗收

/qa

/qa 用 Playwright Chromium 打開應用，執行真實用戶操作：

  1. $B goto http://localhost:3000/settings — 打開設置頁
  2. $B snapshot -i — 獲取可訪問性快照，找到主題切換開關
  3. $B click @e5 — 點擊切換開關
  4. $B screenshot — 截圖驗證暗色模式生效
  5. $B reload — 刷新頁面
  6. $B screenshot — 驗證主題持久化
  7. $B eval prefers-color-scheme — 驗證跟隨系統偏好

QA 報告發現 3 個頁面的對比度不達標。修復後重新驗證，全部通過。

串聯觸發： QA 通過後，運行 /ship。

#第 6 步：gstack /ship 發佈

/ship

/ship 自動執行一系列操作：

  1. git fetch origin main — 同步遠程
  2. bun test — 跑免費測試
  3. 覆蓋率審計 — 檢查新增代碼的測試覆蓋
  4. VERSION 升級 — v1.5.0.0 → v1.6.0.0（MINOR，因為是新功能）
  5. CHANGELOG 生成 — 從 git log 提取變更摘要
  6. git push — 推送代碼
  7. gh pr create — 創建 PR
/land-and-deploy

合併 PR、等 CI、部署到生產環境。

/canary

監控部署後 30 分鐘的錯誤率和性能指標。

串聯觸發： 發佈完成後，運行 OpenSpec 的歸檔。

#第 7 步：OpenSpec /opsx:archive 歸檔

/opsx:archive add-dark-mode

歸檔過程：

  1. 讀取 openspec/changes/add-dark-mode/specs/ui/spec.md 中的 Delta 規範
  2. ## ADDED Requirements 追加到 openspec/specs/ui/spec.md
  3. ## MODIFIED Requirements 替換主規範中的同名需求
  4. 變更文件夾移入 openspec/changes/archive/2026-05-12-add-dark-mode/

歸檔後，openspec/specs/ 目錄始終反映系統當前狀態。下次再加功能時，OpenSpec 的 AI 會讀取這些 specs 作為上下文。

串聯機制

整個流程中，你手動輸入的命令只有 7 個：

/opsx:propose → /autoplan → (寫代碼) → /review → /qa → /ship → /opsx:archive

但背後自動發生的事情遠不止這些：

你輸入的自動發生的
/opsx:proposeDAG 引擎解析依賴，生成 4 個產物文件
/autoplan4 個評審角色讀取 OpenSpec 產物，輸出評審結論
（寫代碼）Superpowers HARD-GATE 檢查設計是否批准（是），TDD 鐵律自動攔截（先寫測試）
/reviewgstack 讀取 diff + 測試，找出生產級 bug
/qaPlaywright Chromium 執行真實瀏覽器操作
/shipVERSION + CHANGELOG + PR + 推送
/opsx:archiveDelta 規範合入主規範，歸檔變更

三個工具之間的銜接不需要你手動傳遞數據。OpenSpec 的產物落盤後，gstack 的評審角色直接讀文件。gstack 的評審結論滿足了 Superpowers 的 HARD-GATE 條件。Superpowers 的 TDD 鐵律確保了 /review 有測試可依。

這就是"三器合一"的核心：不是三個獨立工具的拼湊，而是三套規則在同一個會話裏自動生效、互相補位。

避坑指南

不要重複門禁。 Superpowers 的 HARD-GATE 已經卡住設計審批了，就不要再用 gstack 的 /plan-design-review 重複審查同一份設計。兩套門禁同時跑會出矛盾。推薦：Superpowers 管設計門禁（更嚴），gstack 管代碼審查（有瀏覽器驗證）。

specs/ 是唯一真相源。 OpenSpec 的 openspec/specs/ 定義需求，gstack 的設計文檔只描述實現細節。需求有衝突時以 specs/ 為準。

/ship 是唯一發布出口。 OpenSpec 歸檔只是收尾記錄，不是發佈。所有代碼通過 gstack 的 /ship 流向生產。

TDD 有三個例外。 一次性原型、生成的代碼、配置文件——這三種場景可以跟 AI 說"這是原型，跳過 TDD"。除此之外，Superpowers 的鐵律不打折扣。

總結

OpenSpec 在寫代碼之前把需求鎖住，Superpowers 在寫代碼的時候把質量卡住，gstack 在寫完代碼之後把發佈包了。三套規則同一個會話裏自動生效，你只管輸入斜槓命令，剩下的串聯是自動的。

最後圖片
同時給大家推一箇中轉站，我自己也在用：https://api.bjxrouter.com/register?aff=ffOu，充值後截圖，充 100 我再通過我的渠道額外贈送 50到大家賬號裏
注意先加我微信好友：coderbuffer