在使用此工作流程之前，請先閱讀 .codex/docs/codex-runtime.md。請遵循目前的使用者授權與主機權限。
引數： [path-to-design-doc] [--review full|lean|solo]
在繼續之前，請從專案根目錄執行此設定指令：
bash ".codex/hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow,system_overrides
使用上述指令解析結果 — 請直接使用；--review 會覆寫 review_mode。--depth 是 1.1 版之前的同名旗標：請將 --depth <mode> 完全視為 --review <mode> 來處理，並說明一次該名稱已變更。若兩者同時存在，--review 優先，--depth 會被忽略 — 請說明此情況。若無區塊 → 採用 .codex/docs/config-resolution.md 中的預設值。
設計審查 是做什麼的？
第 0 階段：解析引數
請參閱 .codex/docs/director-gates.md 以了解完整的檢查模式。個別閘道定義位於 .codex/docs/director-gates/[gate-id].md — 衍生的代理程式會讀取自己的閘道檔案；請勿在父工作階段中讀取它。
每個 request_user_input 呼叫都遵循 .codex/docs/automation-modes.md
（協作模式總是詢問 · 引導模式僅重大事項詢問 · 自動模式記錄後繼續執行；
automation_always_ask 類別總是提示使用者）。
workflow 用於正在審查的 GDD — 如果區塊列出了 <system>，則使用 system_overrides 中該 system 的列；否則使用專案值。驗證範圍遵循層級：
full— 驗證全部 8 個章節；任何遺失的章節都會阻止核准。standard— 遺失 5 個必要章節（概述、詳細規則、邊際案例、相依性、驗收標準）會阻止核准；公式章節僅在系統定義數值規則（比率、曲線、閾值、成本 — 分類是提示，不是測試）時才阻止；玩家幻想和調整旋鈕是建議性的（發出警告，絕不阻止），除非workflow_overrides要求它們。minimal— 不預期有 GDD；如果存在，則以建議性方式驗證 5 個標準章節。
解析後的控制模式決定了此審查的詳細程度：
full：完整審查 — 所有階段 + 專家代理委派（第 3b 階段）lean：所有階段，無專家代理 — 更快，單一工作階段分析solo：僅第 1-4 階段，無委派，無第 5 階段的下一步提示 — 當從另一個技能內部呼叫時使用
第 1 階段：載入文件
先進行新鮮度檢查 — 對未變更的文件進行重新審查會花費完整成本並產生相同的結論。 執行：
Bash: bash .codex/scripts/review-receipts.sh check "design/gdd/reviews/[doc-name]-review-log.md" "[target-doc-path]" "design/registry/entities.yaml" ".agents/skills/design-review/SKILL.md"
註冊表被納入檢查是因為此審查會查閱它以獲取跨文件事實 — 針對已變更註冊表審查未變更的 GDD 可能得出不同結論，因此僅當每一行都顯示 UNCHANGED 時跳過才是安全的（從不存在的註冊表不會出現在輸出中，也不會阻止跳過）。此技能的檔案被納入是因為變更的技能會以不同方式審查。檢查還會比較日誌中記錄的每個其他檔案 — 相關的 GDD、概念或簡報以及敘事檔案（先前審查中讀取的） — 並對不再存在的檔案印出 GONE:。
然後讀取最新條目的 Review mode: 行。僅當其模式與現在解析的模式相同或更深（full > lean > solo），且其工作流程相同或更深（full > standard > minimal）時，該審查才涵蓋本次執行。沒有該行的條目是在該行存在之前寫入的，且不涵蓋任何內容。
- 全部
UNCHANGED且日誌的最新條目帶有裁決 — 顯示它： "此文件與其在 [date] ([mode] 審查，裁決：[verdict]) 的最後一次審查在位元組級別上完全相同。" 如果該裁決是 APPROVED 且該審查涵蓋本次執行，則透過request_user_input提供：[A] 使用先前的裁決（建議）/[B] 無論如何重新審查—guided模式使用 [A] 並記錄；autonomous模式透過log_decision記錄並使用先前的裁決。如果裁決是 APPROVED 但現在要求的審查比記錄的審查更深，請說明 — "那是 [mode] 審查，工作流程 [tier]；本次執行要求 [mode] 審查，[tier] 工作流程。" — 並提供[A] 以 [mode] 重新審查（建議）/[B] 使用先前的 [mode] 裁決；guided和autonomous模式都會重新審查（autonomous模式透過log_decision記錄）。如果裁決是 NEEDS REVISION 或 MAJOR REVISION NEEDED，請直接說明：自文件審查失敗以來，文件未變更 — 先前的發現仍然成立；修改文件是下一步，而不是重新審查。提供顯示日誌中先前發現的選項。 - 目標文件和此技能的檔案
UNCHANGED，且僅註冊表或其他記錄的跨文件檔案CHANGED、NEW或GONE— 先前的裁決仍然成立，但跨文件事實除外：根據變更的檔案重新驗證文件的值並重新發布裁決；如果出現衝突或該審查不涵蓋本次執行，則升級為完整重新審查。 - 目標文件或此技能的檔案
CHANGED或NEW，或RECEIPT: NONE— 繼續進行下面完整的審查。不要提供跳過讀取或重新分析未變更章節的部分/差異重新審查。 章節範圍的重新審查會遺漏完整審查中發現的缺陷，且幾乎無法節省任何時間或精力。"自上次審查以來未變更" 僅表示在位元組級別上與當時審查的內容相同 — 它沒有說明該先前的審查本身是否完整，而且即使在指令要求掃描所有內容的情況下，注意力也會集中在標記的變更上。
完整閱讀目標設計文件。此步驟需要完整的 GDD：按其標題範圍讀取（使用 Grep 工具：模式 ^#，內容模式），因為超過 40 KB 的整個檔案讀取會被拒絕。閱讀 AGENTS.md 以了解專案背景和標準。
對於跨文件事實，優先使用註冊表而非同級 GDD。 如果
design/registry/entities.yaml 存在且為此系統列出了條目，
對其進行 grep —這些是此 GDD 不得與之矛盾的公認事實，而且它們取代了閱讀同級 GDD 以重新發現它們的需求：
Grep pattern="source: design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -A 6
Grep pattern="design/gdd/[system].md" path="design/registry/entities.yaml" output_mode="content" -B 8
第一個找到此系統擁有的條目 — -A 6 上下文包含其
referenced_by: 區塊。第二個找到引用此系統的條目 —
referenced_by: 是一個區塊序列（鍵和路徑在不同行上），
因此使用 -B 8 上下文匹配路徑以查看擁有的條目，而不是 referenced_by.*name 單行（它永遠不匹配區塊形式）。
如果 design/registry/entities.yaml 不存在，或未為此系統列出任何條目 — 該檔案作為空存根提供，因此這是預設情況，直到 $design-system 已填充它 — 回退到讀取目標文件在其相依性章節中命名的相關 GDD。將讀取範圍限制在這些 GDD，而不是所有「暗示的」內容。不要使用 Glob 讀取所有 design/gdd/。
相依性圖驗證： 對於相依性章節中列出的每個系統，使用 Glob 檢查其 GDD 檔案是否存在於 design/gdd/ 中。標記任何尚不存在的檔案 — 這些是下游作者會遇到的斷裂引用。
知識/敘事對齊： 如果 design/gdd/game-concept.md（或者，在 rigor: minimal 時，單頁簡報 design/game-brief.md）或 design/narrative/ 中的任何檔案存在，請閱讀它們。記下此 GDD 中與已建立的世界規則、基調或設計支柱相矛盾的任何機制選擇。在第 3b 階段將此背景傳遞給 game-designer。
先前審查檢查： 檢查 design/gdd/reviews/[doc-name]-review-log.md 是否存在。如果存在，請閱讀最近的條目 — 記下給出了什麼裁決以及列出了哪些阻礙項目。此工作階段是重新審查；追蹤先前的項目是否已被處理。
第 2 階段：完整性檢查
步驟 2a — 確定性地收集章節存在性（無需讀取文件）：
Bash: bash .codex/scripts/gdd-structure-check.sh [target-doc-path]
它會印出 PRESENT: 列表，以及適用的 ABSENT: 列表和
PLACEHOLDER: 列表（存在的章節僅包含 [待設計]：尚未撰寫，因此將其視為遺失以進行清單檢查）。它僅報告存在性，不做 REQUIRED/ADVISORY 判斷 — 這是步驟 2b 的工作。它已經接受 ## Detailed Design 作為滿足 Detailed Rules 要求的條件，因此不要將其標記為遺失。
步驟 2b — 應用層級。 使用步驟 2a 的列表，根據下面的設計文件標準清單進行評估。根據解析的工作流程層級（第 0 階段）將每個章節標記為 REQUIRED 或 ADVISORY。 遺失的 REQUIRED 章節會阻止核准；遺失的 ADVISORY 章節會作為建議提出，但不會阻止。
如果報告為 PRESENT 的章節只是一個空白標題，則它仍然可以導致審查失敗 — 對裁決實際依賴的任何章節進行抽查閱讀。
- 有概述章節（一段摘要） — 所有層級均為 REQUIRED
- 有玩家幻想章節（預期感受） — 在
full層級為 REQUIRED；在standard層級為 ADVISORY - 有詳細規則章節（明確的機制） — 在
full/standard層級為 REQUIRED。GDD 模板將此章節命名為## Detailed Design（它包含核心規則 / 狀態 / 互動子標題）；接受任一標題作為滿足此要求 — 當存在## Detailed Design章節時，不要將 "Detailed Rules" 標記為遺失。 - 有公式章節（所有數學定義使用變數） — 在
full層級為 REQUIRED；在standard層級時，每當系統定義數值規則（比率、曲線、閾值、成本、傷害、掉落權重）時為 REQUIRED，否則為 ADVISORY。系統的Category是提示，不是測試 — 不要僅基於分類標記就清除此項 - 有邊際案例章節（處理異常情況） — 在
full/standard層級為 REQUIRED - 有相依性章節（列出其他系統） — 在
full/standard層級為 REQUIRED - 有調整旋鈕章節（識別可設定的值） — 在
full層級為 REQUIRED；在standard層級為 ADVISORY，除非workflow_overrides.tuning_knobs - 有驗收標準章節（可測試的成功條件） — 在
full/standard層級為 REQUIRED
第 3 階段：一致性和可實作性
內部一致性：
- 公式產生的值是否與描述的行為相符？
- 邊際案例是否與主要規則矛盾？
- 相依性是否是雙向的（其他系統是否知道此系統）？
可實作性：
- 規則是否足夠精確，讓程式設計師無需猜測即可實作？
- 是否有任何「含糊」的章節遺漏了細節？
- 是否考慮了效能影響？
- 每個驗收標準是否都可以獨立測試？引用每個不可測試的標準 — "感覺平衡"、"運作正確"、"表現良好" 不是標準 — 並提供可衡量的改寫。在
full模式下，qa-lead也會檢查它們（第 3b 階段）；在lean和solo模式下，沒有專家執行，因此此主要審查檢查是唯一的檢查。
跨系統一致性：
- 這是否與任何現有機制衝突？
- 這是否會與其他系統產生非預期的互動？
- 這是否與遊戲既定的基調和支柱一致？
註冊表值，無論 GDD 在何處陳述它們。 在表格、目錄條目或變體註釋中重申的值與在詳細規則中一樣肯定地與註冊表矛盾，而且按章節閱讀使得這些主體易於瀏覽。列出註冊表的條目名稱（grep -E '^ - name:' design/registry/entities.yaml），然後在整個目標文件中搜尋所有這些名稱及其攜帶的數值鍵一次，不區分大小寫，將每個 _ 寫為 [_ ]，以便 goblin_scout 也匹配 "Goblin scouts"：
grep -n -i -E 'goblin[_ ]scout|iron[_ ]sword|health|value[_ ]gold' [target-doc-path]
檢查它印出的每一行與註冊表的關係，無論它在哪個章節。一個為條目賦予不同值的行，即使只是一個房間、變體、等級或例外，也與擁有該條目的 GDD 矛盾：在「實作前必備條件」下列出它，並附上行號、此文件的值和註冊表的值。如果沒有註冊表條目，則對相關 GDD 定義的實體和值執行相同的搜尋。
第 3b 階段：對抗性專家審查（僅限 full 模式）
在 lean 或 solo 模式下跳過此階段。
此階段在 full 模式下是強制性的。 不要跳過它。
在孵化任何代理之前，印出此通知：
"完整審查：正在平行孵化專家代理。這通常需要 8–15 分鐘。使用
--review lean可進行更快速的單一工作階段分析。"
步驟 1 — 識別 GDD 觸及的所有領域
使用第 1 階段已載入的 GDD — 不要重新讀取它 — 識別存在的每個領域。一個 GDD 可以同時觸及多個領域 — 要徹底。常見信號：
| 如果 GDD 包含... | 孵化這些代理 |
|---|---|
| 成本、價格、掉落、獎勵、經濟 | economy-designer |
| 戰鬥統計、傷害、生命值、DPS | game-designer, systems-designer |
| AI 行為、尋路、目標選取 | ai-programmer |
| 關卡佈局、生成、波次結構 | level-designer |
| 玩家進度、經驗值、解鎖 | economy-designer, game-designer |