specshape-plan 是做什麼的？
在程式碼存在之前進行程式碼審查：在變更還是草圖時就展示其樣貌，並保留每一個決策。
您撰寫一個計劃：一份粗略、以程式碼為基礎的工作描繪，儲存至 .specshape/<id>.md。使用者審查、引導並核准它。程式碼稍後由 /specshape-build 一次一個任務地撰寫。此技能絕不撰寫程式碼。
您可以變更的內容
.specshape/下的檔案：計劃，以及核准時的.specshape/context.md。- 在使用者明確同意且僅在核准時：他們的問題追蹤系統中的票證，以及儲存庫中
AGENTS.md的一行。
其他任何內容都不行。不修改原始檔、分支、提交、票證評論或任何改變狀態的命令。如果使用者要求您實作計劃中的工作，請遵循步驟 7 中的可用性規則；絕不在這裡實作。一個「調整」會結束此技能並交給一般的代理工作（步驟 3）。
0. 定位
- 讀取上下文。 如果
.specshape/context.md存在，請讀取它，以及它所連結的任何詞彙表。其詞彙表、合約和規則適用於您撰寫的所有內容。讀取AGENTS.md以及專案本身的慣例（CLAUDE.md、CONTEXT.md、ADR、貢獻指南）。 - 確定輸入是什麼。 首先檢查
.specshape/中現有的計劃： - 為新工作選擇 ID： 如果有票證金鑰則使用它，否則使用一個簡短的短橫線分隔的 slug。
1. 讀取請求
完整閱讀票證或規格：描述、驗收標準、評論、連結和父層票證、連結的合併請求。寫下驗收標準；計劃必須涵蓋每一項，或將其列為超出範圍。如果輸入太過模糊而無法評估規模，問一個能解除規模評估阻礙的問題，並且只問那個問題。
2. 調查程式碼
事實是您的工作。 絕不詢問使用者您可以在程式碼、票證或您擁有的工具中找到的資訊。如果您可以將探索工作交給輔助工具，就這麼做；否則請自行執行。
深度取決於規模，因此先快速進行一次，評估規模（步驟 3），然後根據需要深入：
| 規模 | 調查 |
|---|---|
| 變更、功能 | 受影響的完整程式碼：存在什麼可以作為基礎，缺少什麼，它目前如何連接（進入點、呼叫路徑、設定），附近的測試以及它們的撰寫方式 |
| 計劃 | 僅受影響的區域：進入點和主要型別，每個都帶有 path:line。深入的閱讀在規劃每個故事時進行 |
| 專案 | 無：沒有程式碼 |
為您將依賴的每個事實記錄 path:line。記下程式碼使用的領域術語，以及票證和程式碼對同一事物使用不同詞語的任何地方。不要從 Git 狀態或檔案列表中推斷未變更的內容；重新讀取受影響的檔案，或比較已驗證的內容基準。
3. 評估規模
使用 sizing.md 評估工作規模。以規模和決定它的信號作為回覆的開頭，然後繼續。 不要等待確認；使用者可以在任何時候覆蓋它（「視為變更」）。覆蓋會改變提問輪次和計劃細節，但不會改變計劃審查或核准。
調整 → 在此停止。用 1-3 行說明要變更的內容和位置，以及不需要計劃。結尾附上：「請您的代理直接進行此編輯，或說『修正它』以在 Specshape 之外繼續。」不儲存任何內容，也不進行任何原始碼變更。之後要求修正它是此技能之外的普通代理工作；它不需要 /specshape-build。
4. 提問
提出那些會改變計劃樣貌且只有使用者能回答的問題：意圖、優先級、含義、程式碼無法解決的權衡取捨。
| 規模 | 輪次 |
|---|---|
| 變更 | 無 |
| 功能 | 一輪。只有在答案開啟新問題時才進行第二輪 |
| 計劃、專案 | 直到沒有什麼是未決定的為止 |
- 在一個輪次中提出所有現在可以回答的問題。 依賴於您尚未收到之答案的問題會等到後續輪次。
- 對於專案，第一輪是關於詞彙表： 每個核心術語的含義以及術語之間的關係（「什麼是帳戶？一個使用者可以屬於兩個帳戶嗎？」），然後才是技術堆疊或樣貌。
- 當票證和程式碼對同一事物使用不同詞語時， 詢問哪一個是正確的。
- 沒有真正的問題，就沒有輪次。 不要為了湊數而發明問題。對於計劃/專案，檢查答案是否留下了重大的邊界問題未解決；技術堆疊或託管選擇並不能解決暴露、註冊或傳輸政策。在聲稱發現完成之前，先問出相依的問題（請參閱 review.md）。
- 計劃本身可見的選擇（命名、哪個模組擁有什麼）不是問題。它們是計劃中的決策，預設為您的建議。
像這樣格式化每個問題，然後等待答案：
❓ **Q1 - <標題>**: <問題，如果有選項請列出>
➡️ <您的推薦答案及原因>
5. 撰寫計劃
按照 plan-format.md 中的格式撰寫 .specshape/<id>.md。計劃包含的內容取決於規模：
| 規模 | 包含內容 |
|---|---|
| 變更 | 摘要、決策、變更地圖、一個包含 1-4 個任務的平面列表 |
| 功能 | 摘要、決策、附有程式碼草圖的設計樣貌、變更地圖、任務 |
| 計劃 | 摘要、決策、受影響的區域、故事（目標和驗收，沒有任務） |
| 專案 | 摘要、決策、樣貌（資料夾、模組、資料模型、主要流程）、故事；第一個故事是可行走骨架 |
當計劃新增或變更詞彙表術語、合約或規則時，每個計劃還有一個上下文變更章節（請參閱 context-format.md）。
規則：
- 證據。 每個關於現有程式碼的主張都引用
path:line。任何您無法驗證的內容都標記為assumption:。驗證引用支援該主張，包括現有測試覆蓋率。絕不為了證明建議的合理性而發明專案歷史或過去的失敗。 - 粗略，而非詳細。 程式碼草圖顯示簽名、型別以及承載想法的行，最多約 15 行。在公開邊界說明無效輸入的行為；一個經過驗證的 CLI 並不會讓無效引數對直接服務呼叫者來說無法到達。每個任務的詳細草圖會在其預覽中出現，就在它即將被建置之前。
- 決策。 包含具有影響設計或行為的重要替代方案的選擇。直接在樣貌或任務中處理例行工作（記錄標誌、遵循既定的驗證慣例），除非它具有重大的權衡取捨。標準的解析器驗證不需要僅僅因為自訂驗證是可能的就做出決策。例行工作保持在範圍內：更新已變更公開介面的現有使用文件；排除無關的清理工作。為整個計劃中的決策編號 D1、D2 ...，包括故事。每個決策都有選項、您的建議，以及使用者關心的後果（「預設值為
true，因此 ad-hoc 執行現在會因groupBy而失敗」）。狀態：open直到被回答；decided當使用者選擇時；assumed當使用者未選擇就核准時。「全部採用建議」是一個明確的選擇。 - 任務。 每個任務都讓建置和測試保持綠色，並列出其檔案、它執行的決策、它依賴的任務，以及一個完成檢查，該檢查會執行其新增或變更的行為。將行為及其測試保留在同一個任務中；絕不將驗證推遲到後續任務。使用 testing.md 來規劃紅-綠-重構切片、它們的公開測試邊界、結果和命令。一個未變更的綠色測試套件單獨並不證明新行為。
- 風險。 指出可觀察到的失敗及其影響的證據。顯示執行順序的引用並不使該順序成為必要；如果順序重要，請解釋相關的副作用。
- 故事。 每個故事都可以獨立交付，作為自己的票證和合併請求，並附有目標和驗收標準。將骨架保持在最小有用的端到端路徑，而不是所有基礎能力。在票證存在之前，故事 ID 為
<id>.<n>。絕不重複使用數字。 - 使用詞彙表中的詞語， 且不使用它說不能用的任何詞語。
- 呈現。 遵循 presentation.md：使用表格來呈現可比較的記錄，使用相依性樹來呈現故事/任務，並在需要解釋流程或關係時使用 Mermaid。
- 只寫下某人會再次閱讀的內容。 沒有章節是為了完整性而存在；對於不適用的章節，寫下
n/a: <原因>，而不是填充它。
在顯示之前檢查。 對於計劃/專案，也請閱讀 review.md 並審查跨故事的一致性與假設。在收到回饋後和核准前重新檢查。修正失敗：
- 每個驗收標準都被涵蓋，或列為超出範圍
- 變更地圖中的每個檔案都有一個任務，且每個任務的檔案都在變更地圖中
- 每個決策都有有意義的替代方案、建議和後果
- 每個關於現有程式碼的主張都有一個
path:line或一個assumption:標籤 - 每個選定的合約都有驗證，包括寬鬆的預設值或後備方案
- 每個行為任務都包含其測試、公開測試邊界和紅-綠-重構檢查；每個故事都有目標和驗收標準
- 決策、故事/任務、上下文和超出範圍的主張在可觀察的行為上一致
- 上下文中的詞彙表術語、合約或規則沒有被矛盾
-
base_commit是目前HEAD；如果沒有提交可用，則省略它並解釋原因
6. 展示與審查
展示：
- 總是完整展示： 摘要和未決決策，因為這是使用者會操作的內容
- 變更、功能： 完整計劃主體，包括實際程式碼草圖、變更地圖、任務和完成檢查。摘要、樣貌描述或指向已儲存檔案的連結不能替代
- 計劃、專案： 帶有相依性和相依性樹的故事總覽表格，然後是通往計劃檔案其餘部分的路徑
- 計劃中的故事審查： 其摘要、驗收、未決決策、樣貌、完整變更地圖、任務表格和相依性樹。顯示每個任務的檔案、邊界、結果和檢查命令；共享的套件命令或散文式任務列表不能替代
以您需要使用者提供的內容結尾：
選擇 D1a 或 D1b、提供回饋，或說 已核准。
使用實際的未決決策 ID；如果沒有未決決策，只要求提供回饋或核准。
關於回饋：
- 修改計劃，增加
version，並用變更的內容替換Changed since行 - 將已回答的決策標記為
decided - 當使用者陳述一個持久的偏好（「絕對不要在類別名稱中放入版本號碼」）或一個專案範圍的事實時，將其新增到上下文變更中；該內容會在核准時應用
7. 核准時
- 將明確的選擇記錄為
decided，未選擇的建議記錄為assumed。重新檢查計劃的一致性，然後設定status: approved和approved: <日期>，如果存在提交則重新整理base_commit。當選擇改變計劃內容時，增加版本號。 - 將上下文變更應用到
.specshape/context.md，如果需要則建立它。如果儲存庫已有詞彙表，則連結到它並只新增缺少的內容；在規劃故事時使用父層的標準詞彙表。不要同時將重複的定義排入專案文件。然後清空計劃的上下文變更章節。 - 計劃或專案：提供票證。 列出您將建立的票證：每個故事一個，作為輸入票證（史詩）的子項，或為專案建立在一個新的史詩下。每個票證包含標題、目標、驗收標準和指向計劃的連結，而不是任務。只有在使用者同意後，使用您擁有的任何追蹤器存取權限來建立它們。在計劃中將每個本地故事 ID 替換為其票證金鑰。檢查可用的追蹤器整合和輸入票證來源；缺少 Git 遠端儲存庫並不證明缺少追蹤器存取權限。如果無法存取，請說明並保留本地 ID。如果只有目的地未知，請詢問要使用哪個追蹤器/專案。
- 此儲存庫中的第一個計劃： 提議在
AGENTS.md中新增一行，並且只有在同意後才新增它：「在處理此程式碼之前，如果.specshape/context.md存在，請先讀取它。計劃存在於.specshape/中。」僅當該技能可用時，才附加「對於計劃中的工作，請使用/specshape-build。」對此提議和下一步驟使用相同的可用性發現；在顯示提議行之前先檢查它。 - 說明接下來會發生什麼：
- 變更或功能：如果
/specshape-build技能可用，則使用/specshape-build <id> T1。否則說明計劃已準備好實作，但/specshape-build不可用。在不撰寫程式碼的情況下停止。 - 計劃或專案：
/specshape-plan <第一個故事 ID>。在建議另一個故事之前，檢查其先決條件；如果未建置，請解釋提前規劃將依賴假設，並且必須在實作前根據已實作的介面重新驗證。 保持交接忠實於已儲存的任務定義和完成檢查。不要附加新的手動檢查或要求；如果需要另一個檢查，請先修改並審查計劃。
- 變更或功能：如果
規劃故事
輸入：一個來自已核准計劃的故事 ID。
- 如果父層計劃尚未核准，請說明並停止。
- 讀取故事的相依性，並完整調查其受影響的程式碼，如同它現在的樣子。如果先決條件程式碼缺失，請標記假設的介面，並指出在實作前必須重新驗證的內容。對於專案的可行走骨架，將其建立在父層的決策和樣貌之上。不要從狀態或檔案列表中推斷未變更的程式碼。將 review.md 應用於新的邊界選擇。
- 如果故事提出只有使用者才能回答的問題（功能規則），則進行提問。
- 填入故事的細節...
...（原文被截斷，但翻譯已根據給定內容完成）