建置
根據自然語言描述來建置一個專案。它會自動協調設定、規劃與實作。
所有面向使用者的輸出都必須使用純英文。不要使用術語：不要出現「TDD」、「衝刺」、「PR」、「squash merge」、「CI/CD」、「ORM」、「中介軟體」。如果某個技術詞彙無法避免，請在括號中解釋它。
引數
$ARGUMENTS — 對要建置內容的純英文描述（例如：「一個包含使用者帳號和截止日期的任務管理應用程式」）。
階段 0：檢查設定
從 CLAUDE.md 讀取目前的設定檔。如果不是精簡模式，記下該設定檔但繼續進行 — /build 在內部一律使用精簡風格的執行方式，無論專案設定檔為何。
階段 1：分解
顯示：「正在規劃需要建置的內容...」
在內部使用 /ideate 邏輯將描述分解成有序的故事：
- 識別描述中的核心實體與功能
- 分解成具備依賴關係的實作步驟
- 將每個步驟分類為功能、基礎設施或測試
- 評估每個步驟的規模（目標是每個步驟觸及的檔案不超過 5 個）
不要向使用者透露任何這些資訊。 不要出現故事類型、不要出現 SPIDR、不要出現優先級標籤、不要出現方法論術語。將分解過程保持在內部。
建立一個簡單的內部計劃（不向使用者顯示）：
steps:
- summary: "建立資料庫表格"
type: infrastructure
files: [...]
- summary: "建置 API 端點"
type: feature
files: [...]
- summary: "新增使用者認證"
type: feature
files: [...]
- summary: "編寫測試"
type: testing
files: [...]
探索捕捉（回溯性）
為了將來的階段審查，無聲地捕捉探索上下文 — 使用者看不到這個：
- 從描述推斷原型（根據
.claude/skills/discover/references/scale-guide.md中的 10 種原型進行分類） - 將規模設為快速建置
- 自動生成一個最小化的
docs/reference/DECISION_LOG.md（從.claude/skills/discover/assets/decision-log.md複製範本），記錄所有技術決策，信心等級設為：ASSUMED - 包含階段轉換故事（E0N-REVIEW：3 個故事的快速變體 — E0N-001、E0N-004、E0N-006）作為最後的內部步驟
- 將分類結果儲存到
vision/classification.md
這樣可以確保 /build 的使用者能夠獲得審查循環，而無需初期繁瑣的步驟。
階段 2：執行
對於每個步驟，按照依賴順序：
-
用純英文顯示進度：
- 「正在設定資料庫...」/「正在建置 API...」/「正在新增使用者登入...」/「正在編寫測試以確保一切正常...」
- 使用使用者能理解的語言。永遠不要說：「正在執行故事 E01-003（類型：功能，規模：STANDARD）」
-
使用故事循環精簡模式執行：
- 規劃（輕量級 — 無需信心評分）
- 對非瑣碎的內容採用 TDD 進行建置（執行測試，不要解釋 TDD 方法論）
- 驗證測試通過
- 使用慣例格式提交（不要解釋提交慣例）
-
無聲地做出所有技術決策：
- 框架/函式庫選擇：挑選最適合的，在最終摘要中記錄
- 架構：遵循偵測到技術棧的標準模式
- 檔案結構：遵循現有專案慣例或偵測到的技術棧預設值
- 只在遇到真正的產品模糊性時才停下來詢問：「設計有兩種可能的方向：[A] 或 [B]。你偏好哪一個？」
- 永遠不要因為以下原因停下來：資料庫選擇、API 風格、檔案命名、測試框架、資料夾結構
-
優雅地處理失敗：
- 如果一個步驟在兩次嘗試後仍然失敗，請跳過它並附上一條註記：「我無法自動讓 [X] 正常運作。以下是需要手動完成的內容：[描述]」
- 繼續執行其餘步驟 — 不要阻塞整個建置流程
階段 3：完成
3A. 啟動與驗證（如適用）
檢查 CLAUDE.md 指令中是否有 dev: 指令。如果已設定：
- 顯示：「正在啟動你的專案...」
- 使用 Bash 並設定
run_in_background: true在背景執行開發指令 - 等待幾秒鐘。讀取任何輸出 — 尋找 URL、埠號、檔案路徑或狀態訊息。
- 顯示指令產生的所有內容。如果輸出一個 URL，請將其標記出來。如果是 CLI，顯示幫助輸出。如果是啟動伺服器，顯示其位址。
- 詢問：「請看一下，告訴我你的想法！」
- 等待回饋。正面回饋 → 繼續進行完成報告。有問題 → 修復後重新執行。
如果沒有設定 dev 指令（例如函式庫、套件、管道等） → 跳過此步驟。測試已經驗證了建置結果。
不要假設 localhost 或任何特定的 URL。 讀取實際的指令輸出。不同的專案會產生不同的結果。
3B. 完成報告
用純英文顯示一份完成報告：
## 全部完成！
### 已建置的內容
- [功能 1]：[用純英文描述它的功能]
- [功能 2]：[描述]
- ...
### 已建立/修改的檔案
- `src/models/user.ts` — 使用者資料模型
- `src/api/auth.ts` — 登入和註冊端點
- ...
### 測試
- [N] 個測試已編寫，全部通過
### 做出的技術決策
- **資料庫：** PostgreSQL（可靠、免費、與 [框架] 搭配良好）
- **認證：** [選擇的方法] — [一行原因]
- ...
### 試試看
[如果開發指令已執行：「你的專案正在執行 — 請參閱上方」]
[如果開發指令存在但尚未啟動：「執行 `[dev command]` 來啟動」]
[如果沒有開發指令：省略此部分]
### 後續步驟
- [建議 1，例如：「使用 /build 'Stripe 付款整合' 來新增付款系統」]
- [建議 2]
規則
- 僅使用純英文 — 每個面向使用者的訊息都必須讓從未寫過程式的人能夠理解
- 無聲的技術決策 — 挑選良好的預設值，在完成報告中記錄，永遠不要詢問
- 只在產品問題時停下來 — 「使用者應該能夠刪除他們的帳戶嗎？」是有效的問題。「REST 還是 GraphQL？」則不是。
- 安全鉤子仍然會執行 — 秘密檢測、Git 保護和測試執行會在幕後進行
- 精簡執行 — 不調度品質代理、不制定衝刺規格、不進行回顧、不生成超出工作所需的文件
- 優雅地跳過 — 失敗的步驟會被記錄下來，但不是致命的。建置流程會繼續。
- 一次性會話 — /build 的第一個版本會在單次會話中完成。多次會話的建置是未來的工作。