從需求到交付
先說清用戶要改變什麼、完成意味著什麼，隨後執行。把已授權的工作持續做完；需要決策時先完成不依賴該決策的部分。不要把「寫了計劃」「程式碼能編譯」「已開啟自動合併」當成最終交付。
工作約定
- 按目標、風險和反饋成本選擇開發方法。可先寫規格，也可在明確的公共介面上測試先行，或直接實現後驗證；方法可以組合。始終明確可觀察的完成條件，取得真實行為證據，不把某套流程強加給所有任務。
- 以當前程式碼、執行結果和實際發佈制品描述「現在是什麼」；以用戶確認的目標描述「要變成什麼」。發現差異就修正實現或過期記錄，不能拿舊文件覆蓋用戶目標。
- 依據規模選擇過程。小修改可把規格寫成幾句話；跨模組需求才拆切片、設計和記錄。不要為每次編輯載入全部知識、建立固定審批鏈或填寫空模板。
- 用戶已經授權的範圍持續有效。研究、實現、可逆驗證不重複確認；外部發佈按用戶明確目標執行。仍缺生產目標或授權時，先把制品、差異、回滾和檢查準備好，再說明缺什麼。
- 本技能可獨立使用。下表中的技能已安裝時按需呼叫；未安裝時直接完成該階段的結果，不要求用戶補齊整套技能。
- 一個任務由當前負責人持續推進。專門方法補充當前階段的證據與產物，沿用已確認決定和同一份記錄，不另開一套競爭流程。
選擇下一步
| 目前狀況 | 推進方式 | 可呼叫技能 |
|---|---|---|
| 不知道應該用哪個能力，或只想了解使用方法 | 按任務選擇最小入口；先解釋使用方式，不把諮詢誤當實施授權 | dev-help |
| 首次配置環境、角色模型或推理預算 | 核對真實可用工具和模型，儲存簡短偏好；不假定固定廠商或後台能力 | dev-setup |
| 想讓重複工作逐步符合自己的習慣 | 從允許讀取的歷史中提煉穩定模式，形成簡短可維護的專案技能 | dev-personalize |
| 用戶在任務中詢問進度，或需要交接簡報 | 彙總已完成、當前證據和待決事項；回答後繼續原任務，除非明確要求暫停 | dev-status |
| 輸入來自聊天、Issue、截圖、日誌或多處反饋 | 找到原始證據、實際行為、目標和範圍，合併重複訴求 | dev-intake |
| 要配置報告接入或按來源監控需求 | 分開選擇來源、追蹤器、倉庫路由、控制方式與實際觸發器，完成授權內初始化 | dev-issue-setup |
| 已配置來源適配器的報告需要分類、查重或分流 | 按原生報告、身份與追蹤器契約處理證據；來源可為聊天、工單、郵件、告警或手工輸入，本階段不復現或修復 | dev-issue-triage |
| 已配置報告管道，可信分診和真實 UI 控制條件齊備 | 核對歸屬，按完整協議復現或驗證已有補丁；需要且已授權時修復並交付草稿 PR | dev-issue-fix |
| 產品規則有關鍵歧義 | 先從程式碼回答事實，圍繞會改變方案的問題逐輪澄清 | dev-grill |
| 需求已清楚但還不能直接驗收 | 寫用戶行為、邊界、非目標和成功條件 | dev-spec |
| 用戶要深化或改寫待執行的請求 | 用四問檢查專業遺漏、原始材料、具體方法與獨立證據，交付可使用的提示詞 | dev-sharpen |
| 接手陌生模組 | 沿一個真實用例走通入口、業務、儲存、反饋和失敗路徑 | dev-learn |
| 不理解歷史設計為何存在 | 區分當前行為、當時理由和推測，追溯程式碼與可獲得的決策證據 | dev-why |
| 邊界或介面有實質取捨 | 比較不同結構；從呼叫方體驗、狀態所有權與領域術語判斷 | dev-architecture |
| 已有或明確要建立 TLA+ 模型，需要帶檢查結果的狀態圖 | 執行 TLC，生成規則標記和最短反例，逐步核對真實程式碼 | dev-statechart |
| 需要檢查關鍵屬性、選擇形式化工具或維護模型 | 明確屬性、假設與邊界，執行檢查並識別模型漂移；普通解釋圖不自動進入此流程 | dev-formal-verify |
| 涉及頁面、互動、設計系統或視覺驗收 | 沿用實際程式碼中的元件與 token；按產品或行銷場景讀取設計規範，不要求設計工具帳號 | dev-ui-design |
| 需求無法一次可靠交付 | 拆成可驗收的垂直功能切片，顯式相依，先跑通最小完整鏈路 | dev-plan |
| 有互不衝突的工作或值得比較的不同方案 | 分配寫入範圍和驗收規則，再整合並驗證最終結果 | dev-parallel |
| 規格或切片已具備實施條件 | 按既有工程規範實現，接通真實行為，驗證當前制品 | dev-build |
| 普通 Issue、CLI/API/UI 功能錯誤或驗收失敗 | 沿實際入口復現並定位根因；僅以效能指標為目標時進入測量流程 | dev-debug |
| 用戶指定測試先行，或當前實現已選擇 TDD | 按公共介面逐個完成失敗測試與最小實現；已有正確行為補測不自動進入紅綠實現 | dev-tdd |
| 同類錯誤反覆出現或關鍵約束容易被繞過 | 優先改善型別、介面與狀態所有權；有真實價值時增加可執行規則 | dev-guardrails |
| 實現完成 | 分開檢查規格符合度和工程品質；修復真實問題 | dev-review |
| 需要證明實際用戶路徑可用 | 驅動真實應用，核對結果與副作用，維護可重複驗證方法 | dev-verify |
| 目標是改善延遲、吞吐、資源或其他測量指標 | 固定工作負載和口徑，完成取證、優化或公平比較，複用同一份基線 | dev-benchmark |
| 目標包含上線 | 確認環境與版本，執行授權部署，驗證實際服務並記錄 | dev-deploy |
| 需要清晰的文件、提交說明或 PR 簡報 | 按讀者問題組織資訊，給出具體行為、證據與必要取捨 | dev-writing |
| 一個需求已交付或明確停止 | 整理新知識、修復衝突、保留有價值的理由並歸檔過程 | dev-archive |
已有規格直接實施；只要求設計就交付設計；只要求解釋就停在解釋。讀 推進與恢復 處理並行和中斷。需要完善需求時讀需求到實施的階段銜接，執行已選任務時讀工程執行程式方法；它們補充當前階段，不重新選擇已完成的階段。
複雜任務沒有合適現成流程時，用定製執行方法形成可驗證單元並繼續已授權工作。長任務的記錄與事後複核使用決策證據方法，檢查決定、替代方案與實際證據是否對應；只要求複核時交付審計結果，不自動繼續遷移或實施。追查某項設計當時為何被採用由 dev-why 負責。用戶明確要建構可操作的狀態面板時，將它作為實施任務；僅查詢進度使用 dev-status。
讓工作能繼續
本套技能新增的專案資料統一以 .agents/wtadev/ 為根，按需使用以下分區。已有資料按真實位置查閱並保留必要引用；只有明確要求遷移時才搬遷，並保留內容、標識和有效連結。用戶本次明確指定其他位置時按其指令執行：
.agents/wtadev/changes/<日期-主題>/：當前需求的 brief、spec、plan、progress、evidence，按需建立。.agents/wtadev/notes/：經過驗證的術語、背景、決策、錯誤經驗和模組理解；入口index.md只指路。.agents/wtadev/deploy/<環境>/：部署手冊及releases/下的歷史發佈記錄。.agents/wtadev/archive/changes/、.agents/wtadev/archive/notes/：已結束工作與歷史知識，明確不代表當前行為。
這些是目標專案的資料，不能寫進安裝包 .agents/skills/。需要恢復時，使用 交接模板，只留下當前結果、證據、未決問題和下一步。
收束
對照最初交付目標，給出實際改動、當前版本的驗證證據、交付地址或提交，以及確實未完成的部分。需要上線但尚未部署，明確寫「實現已完成，部署未完成」；部署成功後，把可複用知識與最新程式碼引用整理進專案，而非把聊天記錄全量塞入 AGENTS.md。
完整本地資料
按 資料索引 選擇本技能內的完整流程、檢查規則、示例和模板。所有執行必需資源都在本包中，不依賴安裝其他技能；只讀取當前任務分支需要的內容。