OpenSpec

給 AI 寫程式用的 PRD + Technical Design + Task List + Change Log。

例如：

/opsx:propose add-google-login

它會建立類似：

openspec/
├── specs/                    # 系統目前應有的行為
└── changes/
    └── add-google-login/
        ├── proposal.md       # 為什麼改、改什麼
        ├── specs/            # 需求 / 行為規格
        ├── design.md         # 技術設計
        └── tasks.md          # 實作 checklist

也就是：

需求
 ↓
規格
 ↓
技術設計
 ↓
Task
 ↓
AI 寫程式
 ↓
驗證
 ↓
合併回正式 Spec

目前預設的核心流程是：

/opsx:propose
      ↓
/opsx:apply
      ↓
/opsx:sync
      ↓
/opsx:archive

另外也有 /opsx:explore、/opsx:new、/opsx:continue、/opsx:verify 等較完整流程。(GitHub)

它想解決的問題其實很實際。一般 AI coding 常是：

你：幫我加會員功能

AI：好的！
     改 LoginView
     重構 AuthManager
     改 API
     改 Navigation
     順便換 Keychain library

你：？？？

OpenSpec 中間多了一層：

你
 ↓
Spec
 ↓
AI
 ↓
Code

所以特別適合 既有專案 / brownfield 專案。它本身強調 lightweight、iterative，不希望變成很僵硬的 waterfall 流程。(GitHub)

套到 iOS，例如需求：

外資未平倉頁面增加日期切換，非交易日自動 fallback 到前一交易日。

OpenSpec 會先寫成：

Requirement:
使用者可以選擇日期查看外資未平倉資料。

Scenario:
Given 使用者選擇 2026/09/13
And 2026/09/13 為非交易日
When 系統要求資料
Then 應自動取得上一個有效交易日
And UI 顯示實際資料日期

再補 design：

ForeignFuturesView
        ↓
ForeignFuturesViewModel
        ↓
TradingDateResolver
        ↓
API

tasks：

[ ] 建立 TradingDateResolver
[ ] ViewModel 加 selectedDate
[ ] API request 支援 date
[ ] 非交易日 fallback
[ ] Unit Test

這樣 Claude Code / Codex / Cursor 實作時，就比較不容易一路自由發揮。

它和 GitHub Spec Kit 概念相近，都是 SDD；OpenSpec 自己的定位則偏向：

Spec Kit
偏完整 / 流程較重
        ↕
OpenSpec
偏輕量 / iterative
        ↕
純 Prompt coding
最自由、但最容易 drift

我覺得它真正有意思的地方，是把 AI coding 的工作單位從 Prompt 變成 Change：

Prompt-driven
「幫我改這個」

        ↓

Change-driven
「這個 feature 的需求、
設計、task、implementation
全部是一個可追蹤的 change」

這很像把 Git 的 commit / PR 思維，往前延伸到「需求」階段。