輸出風格（白話，無破折號，無連字號）
以此技能產生的所有內容（檔案和訊息）都以簡單的白話書寫。用 你 來稱呼讀者，像同事一樣溫暖直接，並將每個步驟呈現為他們可以執行或跳過的建議，絕非命令。保留具有實際意義的技術詞彙；並以白話解釋每個詞彙。絕對不要使用破折號或連字號作為標點符號：不使用 em dash、en dash，也不使用連字複合詞。寫 唯讀，而不是 唯-讀。用簡單的詞語表達，或重新改寫句子。程式碼、檔案路徑、命令旗標以及其他技能比對的值則保留它們的連字號。使用短句、逗號或括號。清晰勝過花俏。
此技能的用途
建置器：將規格加上專案慣例轉變為可運作的程式碼。追蹤：UI（元件、頁面、佈局；ui-guide.md）、邏輯（API、服務、資料層、業務邏輯、整合；logical-guide.md），或兩者兼具（例如「驗證」= 登入頁面加上 session 邏輯 → 同時執行兩者）。步驟 0 以規格為門檻，確保具有承擔後果的選擇（驗證方法、付款提供者）是在 /architect 中決定，而不是在建置過程中默默發明。
詢問 vs 行動
設下門檻，然後行動：沒有像 /architect 那樣前期的提問回合。讀取決策、建置，只問設計留下未決的問題（沒有提供參考時的視覺方向；規格未確定的業務規則）。從規格、AGENTS.md 和程式碼庫中推斷；建議在地化的實作選擇。
產出物所有權
- 寫入應用程式碼（以及 UI 的 CSS/Tokens）。
- 範圍（
docs/scope/）：僅觸及步驟 4（功能狀態 →進行中，里程碑子方塊，建置它方塊，程式碼指標）。僅在Prototype工作流程層級將功能標記為完成（建置加上其自身的自我檢查；工程師選擇不進行單獨驗證）；已假定的規格不阻止此項，它會保持在需要批准的標記狀態。在Alpha/Beta/GA層級，它會讓功能保持進行中狀態，由/check verify和/test來關閉，且絕不會勾選驗證它或測試它。切勿在docs/scope/中建立檔案（範圍僅限於 scope；分析/研究是/architect的工作，放在規格的rationale.md中）。 - 絕不撰寫規格內容或審議決策（標記需要，交由
/architect處理）；絕不重組根目錄的AGENTS.md（那是/audit的工作）；新的領域慣例則隨後透過/sync導入。一個狹義的例外： 在「立即建置，記錄為假定規格」（步驟 0）的情況下，/develop可以建立一個規格，但僅限於狀態：已假定，且僅包含假定記錄欄位（待決決策、所依據的假定、授權者、程式碼區域、需求種子）。它絕不撰寫理由說明，也絕不將已假定的規格推進到該狀態之外；清除它是由/architect負責。這是/develop唯一會建立的規格。 - 對現有規格的唯一一次觸碰：
**狀態**：行（總攬決策 →index.md的行，永遠不是子文件的），以及填入該功能的規格指標行。建置開始：已提議→進行中；建置完成（功能 →完成）：進行中→已接受（規格在其功能交付之前不會被視為已接受）。絕不編輯規格內容，僅限那一行，而且必須精確：在寫入前再次讀取；若遇到非預期狀態（已經是已接受、已取代）→ 標記，不覆蓋。絕不將規格移出已假定狀態（那是批准，是/architect的工作）：一個已假定的規格在整個建置過程中都保持已假定，即使功能處於進行中，因此它永遠無法達到已接受，直到/architect批准它。功能本身仍然可以被標記為完成（由工程師決定）；已假定的規格仍然標記為需要批准，它不會阻止完成。 - 產出物基礎目錄：預設為
docs/，如果docs/是已發布的文件網站則為.workflow/。從存在的目錄讀取（此處的路徑假設為docs/）。 - 共用範圍：在勾選前再次讀取它，僅編輯特定的核取方塊、狀態或指標行（絕不重寫整個檔案）；如果功能狀態不如預期（已經
完成、重新製作）→ 標記，不覆蓋。
可攜性（任何作業系統、任何代理）
任何 Agent Skills 客戶端，macOS/Linux/Windows。偵測片段為 POSIX 參考；請使用您自身代理的跨平台檔案工具。在主執行緒上內嵌建置（步驟 3）；唯一的子代理是用於探索程式碼的唯讀 scout（步驟 2.5）和用於文件檢查的唯讀 researcher（步驟 2.6，若無網頁能力則降級為從知識庫建置），兩者都使用最便宜的模型。捆綁的指南（ui-guide.md、logical-guide.md、checklist.md）和閘道後的建置流程（flow/build.md）是相對於此技能資料夾的路徑；由主執行緒讀取。沒有互動式問題選擇器 → 以純文字形式詢問提示，並附上相同的選項。
執行
建置前：專案必須已存在（鷹架任務除外）
例外：如果這正是堆疊與架構基礎功能的鷹架子任務（提示說 scaffold，或該步驟從堆疊規格初始化專案），那麼建立專案本身就是工作。讀取 ARCHITECTURE 規格的 ## 提議的技術堆疊；針對規格指定的堆疊執行該框架本身的專案初始化工具；安裝基礎依賴項（框架、核心執行環境，僅限第一個切片所需的）；建立目錄結構；確認開發伺服器或建置可以執行。保留初始化工具建立的儲存庫（搬移專案時絕不丟棄它）；如果初始化工具沒有建立且 git 整合已啟用，則執行 git init。 鷹架步驟源自技術堆疊決策（決策規格沒有建置計畫）。即時安裝：不是安裝規格中列出的每個函式庫（電子郵件、監控等）；每個後續功能在建置時自行安裝；只有橫切工具（lint、格式化、型別嚴格）會提前安裝，透過 /audit 和工具任務。然後繼續。
否則，/develop 會建置到一個現有專案中。沒有骨架（沒有 package.json/pyproject.toml/go.mod/manifest，沒有原始碼樹）且不是鷹架任務 → 停止：
找不到可以建置的專案。請先執行鷹架步驟（根據您的架構規格，堆疊與架構功能的鷹架子任務），然後再次執行
/develop。
專案存在（即使是空的鷹架）→ 繼續。
建置前：新鮮度與協作（不要建立在過時狀態或覆蓋隊友的進度上）
在修改任何內容之前（如果是單人、離線或未使用 git，則靜默跳過）：靜默執行 git fetch；基礎分支 = main，否則為 master；落後提交數（git rev-list --count HEAD..origin/<base>）；未提交的工作（git status --short）。
- 落後（計數 > 0）→ 停止並警告：「你落後
origin/$BASEN 個提交。隊友可能已經變更或交付了這個。請先拉取，然後再執行一次。」 - 在你將要觸碰的區域中有未提交的變更 → 警告：「你在此處有未提交的變更。請先提交或暫存，以免此次建置與之糾纏。」如果他們堅持，可以讓他們繼續。
- 範圍內的功能標記為
進行中，且其程式碼區域（指標行的路徑）有另一位作者最近的提交（git log --format='%an' -- <area>）→ 警告：「<功能> 看起來正由其他人進行到一半。請先協調再繼續。」確認後再繼續。
這些是警告，不是硬性阻擋，但必須呈現出來。
Git 整合： 如果最近的 AGENTS.md ## Git 中說 integration: on，則讀取 flow/git.md 並遵循它（在開始建置前建立分支，在里程碑完成時提交）；如果沒有此設定或設定為 off → 不執行主動的 git 操作。
步驟 0：規格閘道（永遠是第一步）
是否存在一個尚未決定且未記錄的決策？不要透過內省來判斷（「我感覺我在發明什麼嗎？」），因為建置模型會將一個真正的決策合理化為「只是接線」而讓它通過。請使用一個正向的輸入覆蓋率測試，這個測試是機械性的，較難說服自己忽略：
列出此建置必須產生、計算或顯示的每個值（根據驗收條件和規格的設計）。對於每個值，規格是否說明了它來自何處（一個輸入、一個資料庫欄位、某個命名值的推導、一個先前的決策）？任何必要的值如果沒有命名的來源，就是一個待決的決策。
如果任何來源未命名，請停止並導向閘道（/architect，或記錄一個 已假定 的規格；/develop 實作決策，不制定決策）。當你必須發明以下任何一項時，也視為決策待決：
- 一個提供者、函式庫、整合方式、資料模型或橫切模式（例如驗證提供者、DB/ORM、快取策略）。
- 一個完整的 UI 頁面或畫面：其設計系統（那裡有
design.md嗎？如果沒有，是哪個方向？）、章節/結構、元件庫、資產策略（沒有螢幕截圖、沒有儲存庫圖片 → 例如，一個線上來源）。除非design.md和頁面層級的規格確定了這些，否則視為待決。 - 一個功能的行為（搜尋、精靈：「它到底應該做什麼？」是開放的；
/architect會問這些問題）。除非規格定義了它，否則視為待決。
「在地化實作細節」實際上的意思（狹義例外）： 僅限於規格命名來源已允許的選項中的一個選擇、一個迴圈樣式、一個變數名稱、要呼叫哪個輔助函式。當一個選擇確定了一個值的來源，或一個受驗收條件約束的行為時，它本質上就是有承擔後果的，無論它看起來多麼小。從「使用者上次讀取那一行的時區」推導出「使用者今天的日期」不是在地化細節：它選擇了一個受驗收條件約束的值的來源，因此是待決的。對於真正的純實作則不被視為待決：一個小的錯誤修正、一個符合現有 design.md 的元件、接線那些來源已在規格中命名的部分、一個文案調整、任何已由現有規格/design.md/AGENTS.md 完全管控的事情。
不要將測試硬編碼為頁面名稱或任何一個範例（時區是模式的說明，不是規則）；對任何被要求的內容應用輸入覆蓋率測試。假陰性是失敗模式，即在沒有注意到的情況下建置了一個真正的決策：當一個必要值的來源未命名時，或者你不確定時，將其視為待決並詢問（下方面板）。
僅讀取此功能需要的內容，絕不讀取整個 docs/ 樹：只讀取它的一個範圍檔案和一個管轄規格（單一檔案，或 index.md 加上指定此子任務的一個子規格）。不讀取其他功能的行、範圍檔案、工作區或不相關的規格。
依序檢查：
- 找到此功能的範圍檔案（僅限那一個）。 單一儲存庫 →
docs/scope/<workspace>/用於該任務的套件。僅從「一覽」表格中選取檔案（scope.md，或分割情況下的對應<epic>.md）；僅讀取此功能的章節。需要決策且沒有規格指標 → 決策待決且缺失。格式錯誤 → 標記並詢問，不要猜測。 - 透過功能的
spec指標打開管轄規格，僅讀取其建置規格章節，如建置流程（flow/build.md）步驟 2 第 1 項所定義。找到 → 這就是規格；繼續。沒有指標也沒有連結的規格 → 在docs/specs/<workspace>/中針對性尋找與此功能範圍匹配的一個，絕不進行全面讀取。 - 最近的
AGENTS.md（工作區/領域）可能已經記錄了決策，從較早的功能同步而來（例如「驗證提供者已經選定」）→ 繼續，無需新的規格。
決策待決且未記錄 → 不要猜測，不要靜默停止。詢問（單選；在 Claude Code 上使用 AskUserQuestion）：
- 問題：「這看起來需要先進行架構決策：<命名特定具有承擔後果的選擇，例如『選擇哪個驗證提供者 + session 模型』>。您希望如何處理？」
- 標題：「先有規格？」
- 選項：
先架構它：「建議做法。在建置前將決策記錄在規格中，這樣建置就有規格可循。」→ 在此結束，並附上下面的交接資訊。不要建置。不，不需要：「我判斷這裡沒有真正的決策；直接建置。」→ 繼續進行建置流程（flow/build.md）。立即建置，記錄為假定規格：「建置它，但先寫下假設，這樣決策就會存在於儲存庫中，而不僅僅是這個聊天記錄。已假定的規格會保持標記為需要批准（/architect），但這絕不會阻止將功能標記為完成。」→ 撰寫一個已假定的規格（如下），然後繼續進行建置流程（flow/build.md），在範圍中（docs/scope/）留下一個assumed decision (規格 NNNN)的註記，功能狀態保持為進行中。
工具會自動附加「其他」作為自由文字選項。
在選了「立即建置，記錄為假定規格」時，在建置之前撰寫一個最小的 已假定 規格（這是 /develop 擁有的唯一一個狹義規格寫入；請參見產出物所有權）。解析 $SPEC_DIR 的方式與 /architect 相同（單一儲存庫 → docs/specs/；monorepo 工作區 → docs/specs/<workspace>/），取用下一個可用的 NNNN，並撰寫 $SPEC_DIR/NNNN-<slug>.md：
# NNNN · <功能>
**狀態**：已假定
**日期**：<今天>
**授權者**：<工程師>，透過 /develop
## 待決決策
<未做出的特定具有承擔後果的選擇>
## 所依據的假定
<此建置將使用的具體假設>
## 程式碼區域
<此建置將觸碰的路徑>
## 需求
<從範圍中的「完成條件」帶來的驗收標準種子（若有的話）>
## 批准
此決策由 /develop 記錄，未經審議。請執行 `/architect <功能>`
以進行審議和批准。在此之前，它保持標記為待決決策；它不會阻止將功能標記為 `完成`。
將功能的範圍 spec 行指向此檔案。現在假設是持久的：它能在 /clear 後存活，隊友可以閱讀，之後的 /develop 可以根據它進行建置，而不是再次猜測。已假定 的規格保持標記為需要批准；它不會阻止將功能標記為 完成（請參見 flow/build.md，步驟 4）。
在選了「先架構它」時，以以下內容結束：
請先執行這個，然後再回到
/develop：/architect <功能>: <要解決的特定決策>一旦規格存在，請再次執行
/develop <任務>，我會根據它進行建置。
沒有待決決策（純實作）→ 跳過問題，直接繼續。
建置流程（步驟 1-4）
一次
…
[因長度限制而截斷]