Vibe Coding 工作流
幫助程式設計新手把小型 Web 專案從想法推進到可檢查的結果。用使用者能理解的語言討論產品決定；根據任務大小調整流程。這個 Skill 是工作方法，不預設框架、資料庫或部署平台。
首版重點是簡單的公開展示頁面。登入、站內管理、檔案上傳、付款和敏感資料處理超出這個簡化範圍；遇到這些需求時，先指出需要新增的產品、資料、權限和部署決定，再依使用者確認後的擴充範圍規劃，不把它們悄悄塞進原路線。
入口：先分流，再確定終點與現狀
- 從使用者已有的話中提取目標、約束和授權，判斷是明確的小改動、新專案，還是已有專案的多步驟功能。小改動走快速路徑；新專案和多步驟功能走完整路徑。
- 完整路徑若尚未說明交付終點，再詢問使用者想要：只梳理方案、本地可執行、準備部署，還是正式發布。小改動僅在交付方式會影響任務時才問。後續工作只推進到使用者已選擇或明確授權的程度。
- 已有專案先讀倉庫說明、
AGENTS.md（若有）、相關程式碼、執行與檢查方式、現有規劃文件以及 Git 狀態。辨認使用者未提交的改動，不覆蓋或混入自己的提交。空目錄先確認要做的產品和現有資源。 - 用簡短摘要列出已知事實、尚待確認的產品決定和當前建議。優先每輪只問一個最影響下一步的問題；多個決定彼此緊密相關且使用者希望批次回答時再合併提問。低影響細節可作為明確標註的假設。
完整路徑：先確定產品，再選擇實作方式
1. 確定首版產品
- 釐清目標使用者、要解決的問題、首版成功標準和約束。依角色整理主要使用者故事，選出 P0 核心路徑，並記錄 P1/P2 和暫不做的內容。避免把 AI 提出的所有功能都加入首版。
- 從故事推導頁面、導覽、主要操作和必要的空白、載入、成功、失敗狀態。讓使用者能順著一個真實場景講清從進入網站到完成目標的步驟。
- 把「好用」「完整」等模糊目標改成可觀察的行為。若故事或優先級互相衝突，先指出衝突。
- 保留簡短的對應關係：每條 P0 故事對應的頁面或行為、開發切片和驗收方式。規劃結束前檢查是否有 P0 故事沒有落到切片，避免寫完文件卻漏做核心功能。
2. 給出技術、資料和部署建議
- 已有專案優先沿用合理的現有技術和約定。新專案先了解使用者熟悉什麼；沒有偏好時，推薦一個滿足首版需求且易於開發、部署和維護的組合。說明推薦理由和主要代價；使用者要求比較時再展示備選。
- 先問哪些內容需要儲存、更新、共享或跨裝置讀取，再判斷資料庫是否必要。若固定內容能滿足首版，明確寫出無需資料庫的理由。確需持久化時，說明資料實體、關係、讀寫路徑、資料遺失影響和遷移方式；不要憑空增加後台或帳號系統。
- 根據交付終點提前考慮執行環境、資料位置、環境變數、費用、域名、建置方式和回退。涉及目前版本、相容性、平台能力或價格時核驗官方資料，並註明依據和不確定性。
- 讓使用者確認會改變成本、資料、架構或後續維護的決定。不要讓新手先猜框架名、資料庫產品或表欄位。
3. 確認路線後開工
- 把工作拆成使用者能看到結果的端到端切片；每個切片寫清目標、範圍、依賴、驗收行為和驗證方式。首個切片優先跑通最重要的路徑。
- 新專案開始改檔案前，展示產品範圍、主要技術決定和第一個切片。若使用者尚未確認這些決定，先取得確認；使用者已明確確認並授權開工時直接繼續，不重複詢問。普通實作細節由 Codex 處理；範圍、架構或高影響決定變化時再重新對齊。
- 使用者若只要方案，停在方案或使用者要求的規劃文件。不要把規劃請求自動升級為編碼或發布。
快速路徑：明確的小改動
檢查相關程式碼和工作區狀態，用一句話說明預期行為與驗收方式，完成限定範圍的改動並驗證。使用者只要求步驟或方案時，也說明實際改動後將怎樣驗收，並區分計劃中的檢查與已經執行的檢查。只有當需求實際牽涉多模組、資料結構、架構或發布方式時，才轉入完整路徑。無需為小改動新建產品文件或測試框架。
每個開發切片的循環
- 開始前重讀目前切片、相關原始碼及專案約定，確認工作區沒有會被覆蓋的使用者改動。本地 Git 用於可回退的檢查點；若尚無倉庫，在開始實作前建立本地倉庫。不要提交使用者無關的改動，遠端倉庫按需設定。
- 開發新功能時，從主要分支或專案現有的整合分支建立功能分支，在該分支實作和提交。先處理工作區未提交的使用者改動，避免把它們帶進功能分支或合併結果。明確的小修復可按專案習慣決定是否開分支。
- 實作目前切片，不順手擴大範圍。若遇到未決定的產品行為、影響資料的變更或明顯偏離原方案的依賴，先說明影響並更新計劃。
- 根據風險執行現有測試、建置、啟動檢查或頁面操作驗收。關鍵路徑可增加有價值的自動化測試；簡單改動可用明確的手動步驟。驗證失敗時診斷、修復並重查；沒有執行的檢查不得報告為通過。
- 將實際結果逐項對照目前切片和相關 P0 故事的驗收條件；未滿足的條件標為待完成。檢查改動範圍，更新必要的專案文件與本地 Git 檢查點。
- 功能分支的相關驗收和檢查通過後，確認目標主要分支狀態，才將功能合併回去。若有衝突或主要分支在開發期間變化，解決後對合併結果重新執行相關檢查；失敗則保持待合併狀態並報告原因，不把未驗證的結果標為完成。完成這個切片後再進入下一切片。
專案記錄與恢復
- 將確認後的關鍵決定留在專案
docs/。新專案通常用docs/PROJECT.md記錄產品事實、首版範圍和重要選擇，用docs/ROADMAP.md記錄切片與進度；技術和資料方案複雜時再單獨維護架構文件。單項功能確實需要獨立驗收規格時才增加規格檔案。 - 保持一個事實只有一個主要記錄位置。已有專案優先更新其現有文件結構，避免建立內容重複的新檔案。以後續做時，先讀專案記錄，再與目前程式碼核對；文件與程式碼不一致時指出差異。
- 使用者改變需求時，說明受影響的故事、頁面、資料、技術或里程碑；更新相應記錄和未完成切片，不把舊決定靜默覆蓋。
發布與完成
依使用者最初選擇的交付終點收尾。若需要部署，先準備建置、環境變數範例、資料遷移、正式環境檢查及回退步驟；建立真實資源、產生費用或正式發布前，說明具體操作並取得相應確認。不要將真實金鑰寫入程式碼、文件或提交記錄。
交付時用簡短清單說明：完成了什麼、如何執行、實際做了哪些驗證及結果、仍有哪些限制和下一步。無法執行或驗證的部分須明確標註。