Genesis 專案工作
Genesis 是一個說明與驗證的夥伴。它不會取代 程式碼庫、測試、Git 審查或程式代理人。
建立新產品方向
對於藍圖尚未確立產品方向的新專案， 在使用者清楚說明正在建置的內容、誰或什麼會使用或呼叫它、 以及第一個可觀察的有用結果之前，請勿研究技術或建立原始碼。 僅詢問未解決的高衝擊問題。回覆僅確認其明確回答的內容； 技術棧確認並非產品意圖。
一旦產品方向明確，選擇一條最小的實作路徑， 通過選定的技術指南，或當目錄中沒有相符項目時， 參考權威的技術文件，並且只閱讀該路徑所需的內容。 不要調查替代方案、複製整個技術儲存庫、檢查不相關的套件內部、 或委派研究，除非一個具體的失敗需要一次精確的調查。
執行 Genesis 指令
在執行第一個 Genesis 操作之前，先解析呼叫方式。
不要使用 Genesis 操作或 genesis --version 作為可用性探測。
- 讀取儲存庫根目錄的
package.json。僅當該清單的name是genesis-compiler，或其dependencies、devDependencies或optionalDependencies包含精確的genesis-compiler鍵時， 才將 Genesis 視為專案鎖定。 - 對於專案鎖定的儲存庫，使用
npm exec --no -- genesis <引數>來呼叫每個 Genesis CLI 操作。這會在不擷取其他套件的情況下執行。 如果宣告的套件未安裝，請回報該專案的相依套件尚未準備就緒； 不要回退到另一個 Genesis 版本。 - 否則，不要嘗試
npm exec。執行command -v genesis（或目前 shell 的等效PATH查找）。當它解析到一個可執行檔時， 直接呼叫genesis <引數>。 - 當兩個來源都無法使用時，停止並回報 Genesis 不可用。 永遠不要僅為了滿足工作流程指示而安裝或更新 Genesis。
成功解析呼叫方式是常規操作。不要敘述 Genesis 是專案鎖定還是在 PATH 上，
並且永遠不要將直接使用 PATH 描述為回退。
僅在解析失敗或使用者明確詢問時，才提及呼叫方式的選擇過程。
對於面向使用者的更新，請遵循已設定的協作方法， 包括其技術深度和回應長度。回報具體的進度、 發現或阻礙；不要宣布您正在遵循指導。
解析明確的技術選擇
在進行外部技術研究或實作之前，當使用者明確指定一個 未選定的技術、框架、語言或資料庫時：
- 執行 Genesis
stack list操作作為第一個技術動作。 - 如果某個目錄元件完全符合此選擇，請詢問：「<技術> 可在 Genesis 中使用。
您是否希望我將其新增到此專案並使用其官方指南準備應用程式？」
在未獲得確認前，不要執行
stack add <piece...>。 - 如果獲得確認，新增該元件，讓 Genesis 套用其宣告的相依封閉包，
並同步該元件宣告的任何權威性 Agent 技能。在同一個任務中遵循
stack add返回的準備提示：使每個具體化的專案契約成真， 或用有證據的現實取代完整的章節。然後執行context .， 或一旦原始碼存在則執行相關的原始碼路徑，載入適用的已安裝技能（如果存在）， 並遵循該技術擁有的指南來準備實際的專案相依套件。 永遠不要從元件 ID 推斷安裝指令。 - 如果被拒絕，繼續進行而不新增該元件或再次詢問。如果沒有目錄元件相符， 不要發明一個；正常繼續，使用該技術擁有的權威文件。
建立上下文
- 讀取
genesis/blueprint.md以了解非技術性的產品意圖。 - 讀取
genesis/engineering.md以了解選定的工程輪廓和任何 專案特定的需求。 - 讀取
genesis/stack.md以了解選定的技術組成、資源、 和驗證指令。 - 定位請求中所涉及的原始碼。
- 在新增輔助或公開操作之前，執行 Genesis
index <名稱或路徑>操作。 當一個既有函式已擁有該行為時，重複使用它。 - 對於相關的程式解釋和選定的技術棧上下文，
執行 Genesis
context <路徑...>操作。 - 從
.agents/skills/或從代理人自己的已安裝技能目錄中， 載入適用的技術技能。
對於現有應用程式的首次技術棧選擇，在接受具體化的元件提案之前，
檢查其實際的設定、建置和輸出指令。
一個選定的元件描述其當前基礎；它不會默默地移植舊的原始碼。
當現有指令不同時，保持實作不變，並替換完整的
專案擁有的消費者操作（例如，主機的 ## Workspace setup 或 ## Outputs）。
Genesis 將這些章節視為不透明文字；
命名的消費者單獨擁有其意義和執行。在提案與原始碼匹配之前，
不要聲稱提議的配方是可用的。
程式(Program)是簡潔、可能出錯的說明。其來源和可選的 實作地圖有助於導航，但絕不能取代閱讀程式碼、測試和執行時期行為。
.genesis/machine-city.json 是一個衍生的詳細檔案/函式對應圖。
.genesis/program-city.json 是一個衍生的較簡單子系統/操作對應圖。
兩者都不是權威或證據；它們都被 git 忽略，並且可以使用 Genesis index 操作重新產生。
實作一般本地工作
- 套用 Genesis 提供的有效工程方法。每個變更 必須易於推理，並且是滿足已知需求的最小目標實作。 不要過度工程化或複雜化，也不要新增投機的抽象層、 依賴項、基礎設施、相容性路徑、分散式模式、 加密或其他高階機制。
- 當一個具體需求使得實質的複雜性成為必要時，在撰寫之前停下來。 解釋為什麼直接設計是不足的，以及提議的最小新增複雜性是什麼， 然後讓使用者批准或闡明權衡。 永遠不要默默地覆蓋工程方法。
- 直接在當前的 Git 樹中工作，並讓有用的編輯在一般的 diff 中可見。
- 當實作有意圖地改變可觀察的產品行為時，在同一個來回中
保持藍圖和受影響的程式模組對齊。
私有的重組可能只需要修正的來源或資訊性的實作地圖，
並且可能不需要編輯說明。當實作有意圖地改變相應的指令或
能力時，保持精確的消費者擁有的操作宣告（例如主機的
## Outputs）對齊。 僅在該處記錄能力元資料和環境變數名稱， 永遠不要記錄值或機密；不要推斷或將該章節作為 Genesis 行為執行。 將.genesis/視為可替換的衍生的導航資料，而非撰寫的產品意圖。 - 遵循既有的專案和技術接縫，而不是建立平行的框架、 持久層、傳輸層、驗證器或 UI 系統。
- 永遠不要發明不可用的外部資源值，或將文字的環境變數名稱 作為資料傳遞。回報缺失的資源並保留有用的工作。
- 保持實作直接且內聚。在報告完成之前，套用任何提供的技術棧 變更後指導；它是此實作回合的一部分，不是對另一個代理人回合的請求。 在有用時執行重點檢查。
驗證與報告
在實作期間，選擇與變更相關的檢查。當專案的驗證政策或使用者的
請求要求時，在選定技術的工作區子系統存在後，透過 Genesis verify
執行技術棧宣告的最終檢查。完成一個項目或恢復一個工作階段
本身並不需要廣泛的驗證執行。將完整輸出保留在本地工件中，
保留退出狀態，並在展開日誌之前閱讀摘要和相關的失敗摘錄。
不要為了節省時間或令牌而削弱斷言或省略所需的覆蓋率。
一個未設定的結果意味著宣告的工作區或檢查尚不存在；
它不是一個失敗的檢查。在報告完成之前，將請求的可觀察行為、
所需的輸入和資源、宣告的專案操作以及重點證據與實際存在的內容進行比較。
報告已變更的檔案、實際執行的檢查、
任何未經證明的部分，以及任何仍需關注的事項。
永遠不要聲稱未執行的檢查已通過，或通過的檢查證明了整個產品。
子系統維護
當一個變更新增、移除或改變了子系統責任、程式成員資格或
資料擁有權/使用時，在同一個實作回合中維護 genesis/subsystems.md。
在變更相關程式碼之前，先閱讀該對應圖。重複使用現有的子系統，
除非有證據顯示一個不同的責任。每個子系統需要一個來源目錄，
並且每個程式模組只宣告一次；程式資料夾名稱不決定成員資格。
保持表格參考植根於綱要/遷移；Genesis 不會檢查資料庫。
當這些關聯保持不變時，私有輔助程式的變更不需要編輯對應圖。
如果 genesis/subsystems.md 缺失，或在一個現有的已說明應用程式中為空，
請在實作之前從實際的原始碼、綱要和現有程式建立它。
這是正常的說明性採用，不是阻礙或需要再次請求許可的理由。
保留現有的程式和原始碼；檢查相關的責任並完成最小的真實對應圖。
初始化可以建立空檔案，但只有代理人撰寫其意義。