Communitygithub.com

kktbur/VibeCoding-Start

一個 Vibe Coding 治理技能,透過從第一天就建立清晰的文檔、可重複使用的專案知識、品質關卡、獨立審查、測試、可觀測性及可回滾的工作流程,防止專案變成難以維護的 AI 生成混亂。

VibeCoding-Start 是什麼?

VibeCoding Start 是為 Codex 代理設計的輕量級工程系統技能,涵蓋從首次專案會議到發布和觀察的完整生命週期。它能確保後續的工作階段無需重播整個對話即可理解、審查、驗證、接受並安全地繼續專案。該技能強制執行一個非協商的文檔骨架,包括 `AGENTS.md`、`docs/INDEX.md`、`PRODUCT.md`、`PRD.md`、`ACCEPTANCE.md`、`CURRENT.md` 和 `CODEMAP.md`,並根據複雜度調整文檔深度和關卡強度。它定義了從範圍界定(G0)到觀察(G9)的十個工程關卡,涵蓋意圖記錄、重複使用決策、規劃、構建、對抗性審查、驗證、人工驗收、發布和觀察。該技能還包括知識結算程序、參考文檔,以及一個禁止構建自定義數據庫或框架的明確邊界,鼓勵優先使用現有能力、標準庫和成熟的開源方案。

相容平台~Claude Code✓Codex CLI~Cursor
npx skills add kktbur/VibeCoding-Start

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

VibeCoding Start

使用此技能,從第一次專案會議到發布與觀察,為 Codex 提供一個輕量級的工程系統。期望的結果是,後續的工作階段能夠理解、審查、驗證、接受並安全地繼續專案,而無需重播整個對話。

首要動作

閱讀專案的 AGENTS.md,然後依照以下熱點上下文順序操作:

  1. docs/INDEX.md
  2. docs/CURRENT.md
  3. docs/PRODUCT.md
  4. docs/PRD.md
  5. docs/ACCEPTANCE.md

僅在任務需要時才閱讀 docs/CODEMAP.md、活躍的 ADR、計劃、工作紀錄、標準和當地的原始證據。如果缺少六個文件的骨架,請在實施之前使用配套的 vibecoding-project-knowledge 技能的 INIT 模式。

非協商的專案邊界

  • 每個專案都接收到相同的最低限度骨架:AGENTS.md、docs/INDEX.md、PRODUCT.md、PRD.md、ACCEPTANCE.md、CURRENT.md 和 CODEMAP.md。
  • 複雜度會改變文件深度和關卡強度;但不會移除骨架。
  • PRODUCT.md 說明原因,PRD.md 說明內容,而 ACCEPTANCE.md 說明如何證明。不要默默地合併這些職責。
  • 當工作階段更改需求、功能、非目標、約束條件或有意義的使用者場景時,請更新 PRD.md。
  • 預設將原始工作階段、日誌、失敗嘗試、調查和證據保留在 .project-memory/ 目錄下。僅將經過編輯、有意策劃的範例提升到 docs/examples/。
  • 在自訂基礎設施之前,優先使用現有的專案能力、標準函式庫、官方 SDK/API/工具、成熟的開源專案、套件、適配器或組合。
  • 不要在此工作流程中構建記憶體數據庫、向量數據庫、搜尋引擎、測試框架、部署框架、CI 服務或可觀測性後端。

工程關卡

對每個專案使用相同的詞彙,同時根據風險調整深度:

G0 範圍界定
→ G1 意圖
→ G2 重複使用
→ G3 計劃
→ G4 構建
→ G5 對抗性審查
→ G6 驗證
→ G7 人工驗收
→ G8 發布
→ G9 觀察

G0 範圍界定

將工作分類為應用程式/產品、整合/適配器或基礎設施/安全性/執行時期。越接近基礎設施,重複使用、審查和復原的證據就必須越強。

G1 意圖

使鏈條明確:

PRODUCT (原因) → PRD (內容) → ACCEPTANCE (如何證明)

在實施前記錄問題、使用者、當前和期望狀態、功能需求、非目標、約束條件、驗收標準和風險。

G2 重複使用

對於任何非瑣碎的通用能力,請在構建前搜尋,並按以下順序決定:

使用 → 改編 → 組合 → 構建 → 停止

如果選擇「構建」,請在 ADR 中記錄已搜尋的替代方案、被拒絕的重複使用路徑、維護責任以及擁有者的驗收方法。模型能編寫程式碼並非自訂程式碼是正確選擇的證據。

G3 計劃

將複雜工作分解為小的里程碑,每個里程碑後都有一個驗證點。當範圍、架構或風險發生實質性變化時,停止並重新計劃。

G4 構建

保持實施小而可逆。使用現有工具鏈,避免推測性的抽象、依賴項和基礎設施。

G5 對抗性審查

獨立的審查者檢查 PRODUCT.md、PRD.md、ACCEPTANCE.md、活躍的決策、相關結構、差異和測試。尋找遺漏、錯誤假設、回歸、重複能力、過度設計、安全/數據風險、測試缺口和回滾失敗。對於重要變更,作者不得是最終審查者。

G6 驗證

根據風險比例涵蓋正常、錯誤、邊界、無效輸入、回歸和復原路徑。提供機器證據和擁有者可讀的解釋;綠色勾選僅證明它實際檢查的不變量。

G7 人工驗收

擁有者確認結果是預期的產品,並且其可觀察的行為是可理解的。自動檢查和獨立審查不能取代此步驟。

G8 發布

在真正使用之前,記錄版本、最後已知的良好狀態、發布說明、備份、回滾方法、遷移風險和準確的發布目標。

G9 觀察

發布後,觀察健康狀況和使用者證據。僅在健康時繼續;當證據顯示問題時停止並回滾或向前推進。將結果反饋到測試、工作記錄、ADR、產品意圖、驗收或事後分析中(視情況而定)。

知識結算

在每個實質性的工作階段結束時,使用配套的 vibecoding-project-knowledge 技能的 UPDATE 模式:

  1. 將原始工作階段詳細資訊和大型輸出保留在當地的 .project-memory/ 目錄中。
  2. 策劃 CURRENT.md 和相關的活躍文件。
  3. 當結構發生變化時更新 CODEMAP.md。
  4. 當需求、功能、非目標、約束條件或用戶場景發生變化時更新 PRD.md。
  5. 在 ADR 中記錄重大選擇。
  6. 更新索引和工作記錄。
  7. 執行相關的確定性審計。

在沒有機器證據、人類可讀的解釋和擁有者驗收方法的情況下,不要聲稱完成。

參考資料

  • 閱讀標準 v1.3 以獲取規範性規則和發布邊界。
  • 閱讀配套的 vibecoding-project-knowledge 技能以獲取 INIT、UPDATE 或 AUDIT 程序。

相關技能