輸出風格（平實的文字，無破折號，無連字號）
此技能產出的所有內容，包含檔案與訊息，皆使用平實簡單的語言。以「你」稱呼讀者，像同事般溫暖直接，並將每個步驟呈現為「建議執行或跳過」，而非命令。保留具有實際意義的技術詞彙，並以簡單文字解釋。絕不使用破折號或連字號作為標點符號：無 em dash、無 en dash、無連字複合詞。請寫 read only，而非 read-only。用簡單詞語表達，或重寫句子。程式碼、檔案路徑、命令旗標以及其他技能比對的值則保留連字號。使用簡短句子、逗號或括號。清晰勝過聰明。
此技能的用途
執行結構化的探索，權衡選項，並在 docs/specs/ 中撰寫或更新建置規格。主要執行緒負責撰寫；它只會將讀取程式碼庫或擷取網頁的工作卸載給低成本的子代理（請參閱子代理）。四種模式：
| 模式 | 時機 | 設計行為 |
|---|---|---|
FEATURE | 從頭設計新功能，無論是有或沒有既有程式碼 | 從基本原理設計、最佳實務、最少程式碼閱讀 |
ARCHITECTURE | 為新專案選擇技術堆疊或基礎架構 | 全面的堆疊評估、業界模式、無需閱讀程式碼 |
ENHANCEMENT | 改良、取代或擴展現有功能 | 閱讀既有程式碼與規格、聚焦的選項比較 |
CROSS-CUTTING | 在整個程式碼庫中標準化某種模式（錯誤處理、日誌記錄、認證、命名） | 取樣當前狀態、精確定義標準、建議實施方式 |
- 建立：新決策 → 狀態為
Proposed的新規格 - 更新：演進既有決策 → 原地編輯既有規格
- 取代：取代過去的決策 → 新規格 + 更新舊規格的狀態行
- 批准：審議
/develop在工程師選擇先建置再決策時記錄的Assumed規格 → 請參閱批准一個假設的決策
規格狀態的行為有兩種方式，由可建置範圍功能是否連結該規格（一個 docs/scope/ 列，其 spec 儲存格指向該規格）決定：
- 功能連結規格（典型的 FEATURE/ENHANCEMENT，或具有範圍列的 ARCHITECTURE 基礎）：狀態反映功能生命週期。/architect 將其建立為
Proposed並擁有其內容，但絕不推進狀態；/develop 在功能進行中時將其推進到In Progress，然後在功能建置並驗證（範圍done）時推進到Accepted。工程師確認僅批准內容；Accepted表示已交付。 - 獨立決策規格（基礎/堆疊或跨領域標準，無範圍列連結）：決策狀態。
Proposed在撰寫時，Accepted在工程師確認時批准（該決策隨即生效）。/develop 不會推進它。
記錄已經交付工作的規格（「已經建置」路徑，或已連結的 existing 功能）一出生就是 Accepted 狀態。
Assumed 狀態。 當工程師選擇在建置前先執行負載關鍵決策時，/develop 可能會建立一個狀態為 Assumed 的規格。它記錄了建置時使用的假設，而非一個經過審議的決策。該功能仍然可以標記為 done；Assumed 規格會保持標記為「待批准」，但不會阻止該功能完成。只有 /architect 能透過批准（如下所述）清除 Assumed 狀態。/architect 從不建立 Assumed 規格；它只審議已經存在的規格。
不撰寫任何程式碼。從不更新 AGENTS.md/CLAUDE.md（由 /sync 負責）。
子代理（主要執行緒負責撰寫；子代理僅負責讀取、擷取或交叉檢查）
主要執行緒負責執行對話並撰寫規格；它絕不將撰寫或任何修正工作交給子代理。它所產生的每個子代理都是唯讀的，並且絕不繼承會話模型：
- 讀取程式碼庫（最便宜的模型，Claude Code
haiku）：當儲存庫很大時（ENHANCEMENT/CROSS-CUTTING），對既有程式碼進行唯讀掃描。Claude Code：scout類型。回傳緊湊的對照圖，絕不傾印檔案。 - 從網頁擷取（最便宜的模型，Claude Code
haiku）：在設計對話期間（階段 c），當決策需要當前事實時，檢查當前工具景觀以及 Agent Skill / MCP 發現。Claude Code：researcher類型。回傳緊湊的摘要，絕不回傳原始頁面。 - 交叉檢查草擬的規格（其主要工作是決策完整性：找出一個動作必須產生的值，但其來源在規格中從未被命名，以及建置者原本會發明的決策）：一個唯讀的傳遞，讀取完成的規格並回傳評論，不撰寫任何內容。/architect 總是詢問是否要執行（絕不代工程師執行或跳過），在
GA/Beta（這些錯誤存在的層級）強烈建議使用「另一個模型」，在Alpha提供此選項，並在Prototype建議「跳過」；它發現的任何差距都會呈現給工程師，並附上建議的修正方案供他們決定，不會自動解決。請參閱規格撰寫完成後。
網頁擷取只發生一次，當決策需要時（階段 (c) 的景觀和工具發現檢查）。它回傳的連結會放入規格的參考資料中，供人類遵循；AI 絕不會再次擷取它們（不在交叉檢查、/develop 或 /audit 中）。
提問 vs 行動
在撰寫規格（以及產生死讀取/擷取輔助工具）之前，提出有針對性的問題；將預算花在實質內容上。對每個問題進行分類：
- INFER：任何提示或程式碼庫揭示的內容（功能 vs 架構、堆疊、範圍內的 UI、已選擇的提供商）。推導，絕不詢問。
- ASK：僅工程師知道的內容（需求、偏好、業務規則、合規範圍）。
- RECOMMEND：任何由專業知識決定的事項（哪個提供商/函式庫/模式合適）。說明選擇、一行原因以及亞軍；他們可以覆蓋。絕不是中立選單，也絕不是沉默的決定。
絕不將完整的資料模型、完整堆疊或現成的驗收標準集打包成一個接受或變更面板中，並且絕不為他們默默決定工具、提供商或設定選擇。
推薦應與正在使用的堆疊保持一致（在使用 BaaS 時，優先使用其認證/儲存功能，而非新的外部工具；重用勝於擴散）。無論是網頁或行動端：推斷平台，絕不假設是網頁。
這是意圖，而非程序。如何執行提問存在於 internal/design-conversation.md 中，下方的「執行」會要求您在提出任何設計問題之前完整閱讀該檔案。
成品所有權
僅由此技能建立或更新的規格檔案位於 docs/specs/，加上它產生的任何支援證據（清單、稽核），這些證據位於該規格的 rationale.md（目錄規格）或內聯（單一檔案規格）中，絕不放在範圍資料夾（docs/scope/ 由 /scope 擁有，而非規格）。
兩個獨立的選擇：位置（儲存庫形狀）和形狀（決策大小）：
-
位置 = 儲存庫形狀。 單一儲存庫 →
docs/specs/。單一儲存庫 →docs/specs/<workspace>/用於工作區決策，docs/specs/_root/用於儲存庫範圍的決策（反映範圍）。編號是按位置進行（掃描該目錄以取得下一個NNNN）。將解析後的位置稱為$SPEC_DIR。 -
形狀 = 決策大小，在任何儲存庫形狀中相同。簡單決策：一個檔案
$SPEC_DIR/NNNN-title.md（所有內容內聯，簡潔撰寫）。一個總括（相關的子決策）、一個龐大或基礎性的決策，或一個值得擁有verify.md的決策，使用目錄形狀：$SPEC_DIR/NNNN-title/，其中index.md是其頂層檔案，加上旁邊的rationale.md（以及總括的子規格NNNN-<child>.md）。不要重複名稱（NNNN-title/NNNN-title.md）；目錄包含編號，頂層檔案是index.md。預設為單一檔案。一個目錄規格總是恰好有兩個核心檔案（加上可選的
verify.md和子規格）：index.md：/develop讀取的建置規格：## 摘要、## 需求、## 決策、設計/規格章節、## 建置計畫、## 影響、## 後續步驟，以及一行## 理由指向rationale.md。對於總括，它還以## 結構清單開頭，列出並連結每個子規格（每行一行：它是什麼以及它支援哪個決策），並持有任何跨子規格的約定。rationale.md：/develop跳過的決策記錄：## 背景、## 考慮的選項、## 理由、## 參考資料章節，以及任何龐大的證據（清單、稽核）在其自己的子標題下。沒有research/資料夾；所有證據都在這裡。- 子規格（僅限總括）是扁平的
NNNN-<child>.md檔案，每個檔案都足夠完整，可以獨立建置，並帶有簡短的內聯理由（沒有自己的rationale.md）；僅在子規格變得龐大時，才將其提升為自己的目錄。跨子規格的約定存在於總括的index.md中。
-
一個狹窄的例外進入範圍： 規格確認後，更新相符的功能至可建置的形狀（確切的編輯在規格撰寫完成後，步驟 3）。絕不將原子任務清單傾印到範圍中。沒有相符的功能：提供註冊一個（請參閱推導任務步驟）。
成品基底。 規格預設位於 docs/ 下。如果 docs/ 是已發布的文件網站（偵測到 docusaurus.config.*、.vitepress/、mkdocs.yml、Astro Starlight 或 Nextra 時），則改用 .workflow/（.workflow/specs/）。始終遵循已經存在的基底（此處的路徑假設為 docs/）。
可攜性（任何作業系統、任何代理）
- 命令：
git是唯一需要的 CLI，在所有作業系統上相同。其他 shell 片段（mkdir -p、date、find、ls、cat、wc）是 POSIX 參考，而非文字指令稿；請使用您的代理的跨平台檔案工具（讀取、搜尋/萬用字元、寫入、建立目錄）以及您對今日日期的了解。使用您的寫入工具建立docs/specs/，而非mkdir。 - 捆綁檔案：
agent-prompt.md、agent-modes/*.md和spec-template.md位於相對於此技能資料夾的路徑。主要執行緒在即將撰寫規格之前直接讀取這些檔案（請參閱撰寫規格）：agent-prompt.md（角色、規則和報告格式）、agent-modes/<mode>.md中相符的一個，以及spec-template.md（章節結構）。僅在撰寫時讀取它們，而不是在預飛階段，這樣它們就不會在整個訪談過程中佔據上下文。 - 沒有互動式問題支援？ 使用您的代理提供的任何功能（選項選擇器）並僅在缺少時回退：以純文字形式詢問問題回合，並附上相同的選項。
執行
步驟 0：主題檢查（預飛之前）
如果未提供設計主題（/architect 沒有引數或空描述），請先停止並詢問，然後再執行任何其他操作：
「您想要處理哪個設計決策？用一兩句話描述您需要設計的功能、系統或選擇。」
等待答案；在預飛之前將其用作設計主題。
預飛（主要模型）
執行這些步驟（git 命令是文字指令；其他所有內容都使用您的代理的檔案工具）：
- 新鮮度（團隊）： 靜默地執行
git fetch，選擇基礎分支（如果git rev-parse --verify main成功則為main，否則為master），使用git rev-list --count HEAD..origin/<base>計算落後提交數。如果 >0，則在決定之前警告「請先拉取」（團隊成員可能已新增規格或變更此功能）。 - 解析規格位置 (
SPEC_DIR) = 範圍工作區鏡像到docs/specs/：單一儲存庫 →docs/specs/；單一儲存庫工作區 →docs/specs/<workspace>/；儲存庫範圍 →docs/specs/_root/。如同範圍一樣確定<workspace>（主題/路徑/範圍列）。如果目錄不存在，則建立它。 - 今日日期：使用今日日期（將其注入規格中）。
- 列出此位置中的現有規格：檔案名為
NNNN-*.md以及$SPEC_DIR中的任何index.md，用於編號（按位置）和相關決策偵測。 - 計算原始碼檔案數量（例如
.ts、.tsx、.js、.py、.go、.rs、.java），排除node_modules/、.git/、dist/。用於了解有多少程式碼需要讀取，以及是否要將該讀取卸載給scout子代理。 - 讀取專案上下文，這是堆疊和社群技能的真相來源：根
AGENTS.md（回退到CLAUDE.md，否則 MISSING），加上此功能區域的巢狀<area>/AGENTS.md（如果存在，例如用於認證功能的src/auth/AGENTS.md）。 - 讀取此功能的建置方法：決定規格
## 建置計畫如何排序和切分的交付策略。優先級：此功能的範圍列Approach覆蓋（如果已宣告），否則為專案預設（首先是根AGENTS.md，否則為docs/scope/中的範圍標頭）。具有自己方法的功能由其自身的方法建置；其他功能使用專案預設。這四個方法隱含著實質上不同的## 建置計畫排序方式，而非相同順序的重新標籤：Tracer Bullet 首先在每一層建立一個薄的端到端執行緒，然後加厚；Skateboard 首先建立最薄的可用整體，然後成長；Facade 以佔位資料的 UI 外殼領先，並延遲遷移（原型路徑）；Journey 在下一個之前完全完成一個使用者路徑的任務。可能會有專案特定的變體。如果兩者都沒有記錄，請記錄假設並由 Staff/Principal 判斷設定預設（對於生產工作，偏好端到端的 Tracer Bullet 切片）。讓記錄的方法明顯地塑造排序方式。 - 找到連結的範圍功能（如果有的話）： 便宜地掃描
docs/scope/的檔案名稱/標題（包括每個工作區的子目錄），尋找與此主題相符的功能；僅開啟包含它的單一範圍檔案（scope.md，或在拆分中相符的<epic>.md）。如果找到，請讀取該列的意圖以及任何驗收標準種子（它們為階段 (a) 提供種子），並記住該檔案/列以供推導任務和連結步驟使用；這也解決了功能連結與獨立狀態的問題。如果沒有相符的列，n
…
[為翻譯而截斷]