主體驅動的領域設計
讓業務所有權從路徑、名稱、合約和依賴關係中清晰可見。 最佳化正確行為、可讀性變更、可衡量的效能以及經濟的演進。 將此技能套用於請求的變更；它並非授權重新設計專案。
自動執行
在規劃或編輯生產程式碼之前套用此基準；不要等待技能調用、觸發詞或架構請求。作為編碼任務的一部分，執行已授權的實作、重用、間隙修復、驗證和交接，而不僅僅是建議它們。對於僅審查或僅規劃的任務，套用相同的推理原則，但不要編輯程式碼。保持工作與範圍和風險成比例；自動使用不會授權無關的變更或委派。
代理程式的可攜性和交接
這些是工具中立的指令，適用於能夠讀取 Markdown 和檢查專案的代理程式。使用可用的搜尋、建置、測試和執行時期工具；不需要特定的供應商、外掛程式或 CLI。遵守主機的指令層級、權限和明確的任務範圍。此技能不會啟用已禁用的功能，也不會授予部署、發布或執行破壞性變更的權限。
當委派已經被授權時，在任務指派中傳遞技能的可存取路徑或相關指令、擁有的檔案/模組、驗收條件和追蹤義務。不要假設子代理程式繼承了父代理程式的對話、已載入的技能或全域指令檔案。要求每個工作者提供證據和未解決的邊界；在工作者邊界之間協調追蹤。委派已驗證的不變項；將提議的演算法標記為假設並挑戰矛盾。如果子代理程式無法讀取此技能，請在允許的上下文內提供其相關內容。不要僅僅因為此部分描述了交接就生成代理程式。
在採用其他工作流程之前，記錄使用者授權的團隊成員數量和角色。每個探索、實作和審查代理程式都會消耗該預算；當預算耗盡時，後續審查由協調者負責。可選的工作流程技能不能擴展使用者的限制。將任務簡報和虛擬碼視為提案：獨立檢查它們的演算法是否符合原始合約。修正有缺陷的計劃，而不是將其保留為實作要求。
交接合約
每個授權的代理程式指派或可暫停的交接都必須標識：
| 欄位 | 所需內容 |
|---|---|
| 目標與限制 | 使用者成果、驗收檢查、授權的操作、排除事項 |
| 位置 | 可存取的工作區根目錄、實際分支/工作樹或修訂版、相關的指令/技能路徑 |
| 所有權 | 代理程式擁有的確切檔案/模組；其他活躍的所有者和共享的介面依賴項 |
| 架構 | 領域所有者、公開的進入點/合約、重要的呼叫者和消費者路徑 |
| 目前狀態 | 已實作與待辦工作、本機編輯內容、決策及其原因、已知的失敗 |
| 證據 | 指令和結果、追蹤分類帳路徑/ID、已驗證的修訂版、不可用的環境 |
| 下一步 | 具體的下一步、阻礙因素、所需的輸入以及預期的回傳格式 |
主機可以使用委派守衛來強制執行此合約。
可選的 Claude 守衛提供此基準，並檢查本地使用者回合中的明確數字代理程式限制（Use N teammates/agents/workers）；遺失歷史記錄則將執行留給協調者。它不會授予工具或保證語義正確性。
當安裝了該守衛時，請在指派前加上 HANDOFF_JSON= 和一個包含 goal、limits、workspace、revision、owns、interfaces、state、evidence、next、return、traces、checks 和 baseline 的 JSON 物件。return 必須是一個包含非空的 paths、contracts、checks、gaps 和 remaining 指令的物件。trace 指定要追蹤的路徑和失敗案例；checks 指定要執行的檢查或為何不可用。baseline 是此技能的可存取路徑。這也適用於探索和審查任務指派。被拒絕的指派必須在重試前修正。
使用接收代理程式主機上的實際路徑；當路徑不同或不可存取時，請包含必要的內容。為指令提供其工作目錄和所需的非機密配置名稱。切勿將憑證或私有執行時期負載放入交接記錄中。僅分支名稱並不能證明子代理程式看到未提交的工作；確認簽出是共享的還是隔離的。
對於並行工作，在重疊變更之前同意公開合約和檔案所有權。告訴代理程式它們並非孤軍奮戰：保留他人的編輯，並透過指定的所有者協調共享檔案。在聲稱整合之前，重新基底或協調隔離的變更；不要默默地丟棄工作。返回時，報告變更的路徑、公開合約的變更、帶有結果的檢查、間隙 ID/狀態以及剩餘的操作。協調者協調追蹤分類帳，並驗證跨代理程式的接縫和受影響的消費者；幾個通過的工作者檢查並不能建立一個正常運作的整合工作流程。
對於中斷或上下文遺失，將帶有時間戳記和內容修訂版的交接儲存在現有的任務/追蹤記錄中，然後連結該記錄。恢復時，在執行操作前檢查簽出和目前的差異；重新驗證過時的假設。不要建立第二個任務事實來源。
本地安裝並不意味著雲端、遠端主機或無關代理程式的安裝。在每個執行主機上建立發現機制；使用主機原生的全域指令將相關工作路由到此處。如果發現或檔案存取不可用，請報告該限制，而不是聲稱全域執行。
主體工程合約
- 從業務能力、不變項、使用者工作流程和營運限制開始。
- 偏好領域內的高內聚性和領域之間的低耦合性。
- 將領域特定的程式碼與其所有者放在一起；在該邊界內按功能分組程式碼。
- 為每個業務规则和權威性寫入模型指定一個清晰的所有者。
- 在新增另一個實作之前，重用現有的實作；避免重複的業務知識。
- 選擇滿足已證明需求並支援可能變更的最小架構。
- 區分觀察結果、假設、決策和證據。不要憑空發明需求或基準。
- 在結構變更期間保留有效的公開行為，除非請求了行為變更。
- 改進受影響的路徑及其必要的依賴項。不要將無關的程式碼納入任務中。
1. 在編輯前建立上下文
檢查適用的儲存庫指令、清單、套件匯出、進入點、現有的領域模組、遷移、測試和相關的執行時期證據。在建立檔案之前，搜尋等效的行為和現有的共享套件。使用儲存庫的語言和工具。
從使用者或事件輸入，到授權、服務、領域規則、持久化、下游影響以及返回或顯示的狀態，追蹤一個相關的工作流程。包括錯誤路徑。標識真實的消費者和寫入者；僅目錄名稱並不能建立所有權。
對於重要的架構工作，建立一個簡潔的決策框架：
| 問題 | 所需答案 |
|---|---|
| 業務成果 | 哪個使用者工作流程或不變項發生了變更？ |
| 所有權 | 哪個限界上下文擁有意義和權威性寫入？ |
| 消費者 | 哪些應用程式、任務、模組或外部系統需要該功能？ |
| 限制 | 相容性、資料量、延遲、多租戶、可用性、成本、部署？ |
| 目前證據 | 相關路徑、合約、失敗、時序或查詢行為？ |
| 最小變更 | 哪些可以重用，哪些邊界實際需要變更？ |
| 完成 | 可觀察的驗收條件和適當的驗證？ |
僅當未解決的業務決策阻礙了正確的工作時才提問；否則陳述假設。
2. 定義領域邊界
限界上下文擁有一致的業務詞彙、規則和模型。功能、表格、畫面、框架層、部署或團隊名稱並不一定就是限界上下文。使用業務功能名稱，例如 billing、scheduling、playback 或 execution。
- 當同一個術語具有不同的含義、不變項、生命週期或所有者時，分離上下文。
- 當不變項必須在一個原子操作中強制執行時，將實體保持在一起。
- 避免過大的聚合：區分真正的原子不變項和跨上下文工作流程，後者需要顯式的一致性、編排或補償，而不是共享交易。
- 區分核心業務差異化與支援性和商品功能。
- 在複雜性或業務價值需要的地方投入建模工作；保持簡單的 CRUD 簡單。
- 在重要的上下文邊界記錄上游/下游所有權和轉換。
- 透過另一個上下文的公開 API、連接埠或合約來消費它；不要導入其內部實作。
- 在邊界轉換外部/提供者模型，而不是將它們洩露到業務規則中。
- 偏好模組化單體，直到獨立部署、擴展、故障隔離或所有權證明需要拆分服務。單一儲存庫並不意味著微服務。
如果變更跨越領域，請標識編排用例和每個領域的職責。將編排放在工作流程的所有者處，而不是全域輔助函式或 UI 元件中。
3. 按領域建構，然後按功能
首先選擇擁有的範圍，然後選擇功能類別。在該範圍內：
| 類別 | 職責 |
|---|---|
model/ | 實體、值物件、不變項、策略、領域事件 |
services/ | 命名的應用程式用例和編排 |
ports/ | 持久化、時鐘、身分、佇列、提供者的介面 |
adapters/ | 具體的資料庫、傳輸、提供者或平台實作 |
contracts/ | 公開的 DTO、事件綱要、驗證、相容性合約 |
components/、hooks/ | 當該領域擁有前端時的領域 UI 和 UI 行為 |
shared/ | 供該範圍內消費者重用的程式碼 |
tests/ 或同位測試 | 使用儲存庫慣例的行為和邊界驗證 |
服務實作屬於其所在層級的 services/。當需要一個跨實體的規則的領域服務時，將其放在 model/services/ 中；編排則保留在領域的主要 services/ 中。當有用時，提供者服務可以放在 adapters/services/ 中。
對於一個應用程式，根據需要使用 src/domains/<domain>/{model,services,ports,adapters,contracts,shared}、一個公開進入點、精簡的框架路由和一個組合根。將領域中立的原始類型放在 src/shared/ 下。僅建立包含真實程式碼的目錄。
單一儲存庫範例；尊重現有的套件慣例和明確的匯出：
apps/
web/ # 應用程式的組合和呈現
api/ # 精簡的傳輸進入點
worker/ # 任務註冊和組合
packages/
billing/ # 擁有的工作區套件
package.json # 公開匯出和執行時期相容性
src/
services/ # API/工作者共享的用例
shared/ # Billing 本地重用
index.ts # 明確的公開外觀
shared/
contracts/ # 領域中立的工作區套件
ui/ # 相容的前端消費者
在工作區註冊真實的套件；僅路徑不能使它們可導入。在多語言工作區中，從規範綱要中公開相容的函式庫或生成的客戶端；不要嘗試跨不相容的執行時期導入程式碼。
放置規則
- 一個消費者和領域特定的含義：將其保留在該領域中。
- 一個領域內的多個消費者：使用該領域的
services/或shared/。 - 多個相容的應用程式需要可重用的領域程式碼：將其放在工作區領域套件中；特權伺服器行為保留在授權的 API 或客戶端合約之後的伺服器端。
- 多個領域需要相同的領域中立原始類型：使用限定的
shared/程式碼。 - 消費者需要不同的業務含義：保持分離的模型並明確轉換。
- 跨領域工作流程：使用擁有的應用程式服務和公開的領域合約。
- 路由、畫面、控制器和任務：將規則委派給服務；保持傳輸關注點在本地。
切勿僅僅為了使導入方便而將功能複製到多個應用程式中。切勿讓一個應用程式成為另一個應用程式的函式庫。將可重用的所有權向下移動到兩者都可以依賴的套件。保留所需的框架目錄；將它們路由到領域結構中，而不是與框架對抗。尊重語言標準的封裝和有效的現有架構。
4. 強制依賴方向
進入點 -> 公開應用程式服務 -> 模型 + 連接埠
適配器 -> 連接埠 + 模型
引導 -> 服務 + 適配器 # 連接具體實作
領域套件 -> 領域中立的共享套件
- 模型不依賴 HTTP、UI 框架、資料庫、佇列或提供者 SDK。
- 服務透過顯式依賴項編排用例；適配器實作連接埠。
- 共享套件不導入應用程式或領域內部實作。避免循環依賴。
- 跨領域呼叫使用公開合約；避免同步呼叫循環和冗長鏈。
- 匯出有意的進入點。使用現有的套件、lint 或建置工具阻止深度導入。
- 將瀏覽器安全的合約與僅伺服器實作和特權依賴項分開。
- 將特權 SDK、資料庫客戶端、機密和檔案系統程式碼保留在客戶端依賴圖之外。
- 提供者 SDK 可能會在受限環境中運行。
（文件其餘部分被截斷，保持與原文一致。）