工程工作流程
一個有閘門、切片導向、測試驅動的流程，從故事到已部署建置。
故事分類 -> 進行中 -> 切片，每個切片透過 TDD -> PR 前對抗閘門（僅在必要時升級至雙透鏡循環） -> PR 至整合分支 -> 可選審閱者（永不阻塞） -> 正式審查（審閱者，然後仲裁者） -> 修正並重新審查，直到最新版本通過 -> 合併 -> 部署並驗證 -> 部署審查
不要因為變更看起來簡單就跳過任何閘門。
在步驟 1 之前
- 閱讀 references/profile.md，然後閱讀本技能的覆蓋層以及
profile.overlays命名的每個能力覆蓋層。 - 閱讀 references/todo-tracking.md 並建立細粒度的待辦事項清單（每個切片、測試、閘門輪次、審閱輪次、部署、驗證和等待各一個項目）。 references/runtimes.md 將待辦事項清單、子代理、暫存目錄和詢問使用者對應到您的執行時間。
以下步驟是工作流程主幹；能力檔案包含規則，且在重疊處具有權威性：
- references/linear.md：故事生命週期、分類和完成定義、狀態轉換（步驟 1、5、12）。
- references/engineering-practice.md：診斷、TDD、持久修復、測試品質（步驟 2、3、6、8），以及當變更將其規則寫入技能時，退役記憶筆記。
- references/github.md：分支、工作樹、提交、簽署、PR、合併、提升、歸因（步驟 2、5、10）。
- references/code-review.md：正式審查、可選審閱者、發現處理、監視 PR（步驟 6 至 10）。
- references/merge-approval.md：委託的合併批准握手：請求、喚醒、等待、批准或退回，以及當 head 變更時重新請求（步驟 10）。
- references/secrets.md：每當變更觸及憑證時。
透過已安裝的絕對路徑（<skill dir>/scripts/<name>，其中 <skill dir> 是您的執行時間載入此技能的絕對目錄）運行 scripts/ 中的每個腳本，並以消費者儲存庫的當前目錄執行；消費者儲存庫不包含它們。
每個腳本都針對當前目錄的儲存庫，或 --repo <dir> 命名的儲存庫，絕不針對其自身位置，並且拒絕在技能儲存庫本身中運行，除非 --repo 指定了它。
1. 分類故事
如果故事尚未精煉和估算，請先執行 story-refinement。
它會執行獨立精煉、接受輪次、秘密估算、共識檢查，以及當檢查要求時的高/低討論和共識。
- 完整閱讀故事：驗收標準、評論、連結的問題和上下文。
- 識別所需行為、驗收標準、約束條件、可能受影響的元件和測試策略。
- 從正式的關係圖中列舉依賴關係，而不僅僅是文章：
linear issue relation list <ID>列出問題的關係，而linear issue view --json則不包含（請參閱references/linear.md，分類）。 - 確認故事屬於此儲存庫。
- 應用範圍規則：任何故事的驗收標準均未更改（references/linear.md "驗收標準和範圍"），沒有基於另一個故事的跳過（references/engineering-practice.md "進行最小、持久的變更"），且如同這些部分所述，僅有的兩個出口是"精煉提案（非驗收標準）"或報告故事受阻；步驟 5 "準備 PR" 的第 4 項"根據驗收標準進行自我審查"會再次檢查它們。
- 將其移至
profile.tracker.states.in_progress並讀回以確認。 使用設定檔中的確切狀態名稱；切勿自行發明一個。
如果無法更新追蹤器，請停止並說明轉換未執行；切勿聲稱已執行。
2. 規劃切片
根據 references/github.md，在 fetch 後從 origin/<integration branch>（整合分支是 profile.git.integration_branch）建立分支和工作樹。
將故事分解為小的垂直切片，每個切片具有狹窄的行為目標、定義該行為的測試、通過測試的最小實作，並且僅在通過後才進行重構。
在編碼前說明切片順序和第一個切片。
3. 每個切片進行 TDD
- 紅：為該行為撰寫一個失敗的測試。
- 綠：通過測試所需的最小生產程式碼。
- 重構：不改變行為的情況下進行重構。
- 執行聚焦測試。
- 定期並在 PR 前執行更廣泛的驗證。
如果架構使得嚴格 TDD 對某個切片不切實際，請說明原因。 保留現有測試和慣例。
4. PR 前對抗閘門（必填）
載入 adversarial-review-pipeline 技能並對每個審查完成執行；其仲裁報告是此閘門的輸出。
在其搜尋階段之前不進行任何修復。
升級：門控雙透鏡循環
僅在管線無法關閉差異時才升級：
- 其重新驗證輪次發現新的嚴重性或高優先級問題，或
- 差異是安全性、遷移、並發性或部署路徑相關的，或
- 管線達到了其界限並存在未解決的嚴重性或高優先級發現。
切勿對同一個 head 同時運行循環和管線。 將循環限制在 2 輪。
循環收斂於零個已驗證的阻塞性發現，而不是零個發現：一個零發現的終止條件會獎勵審閱者，使其在真正發現消失後發明發現，而一個被迫對每個發現採取行動的修復者會使程式碼膨脹。
角色，皆來自設定檔：
- 正確性透鏡：
profile.review.pre_pr.hunter（正確性、接線、安全性、並發性、相容性、測試缺口）。 - 簡潔性透鏡：
profile.review.pre_pr.simplicity_reviewer（最小的正確變更、過度工程化、死程式碼以及另一個透鏡遺漏的缺陷）。 - 驗證者：
profile.review.pre_pr.arbiter。 - 修復者：
profile.review.pre_pr.fixer。
停用的簡潔性審閱者或修復者會阻止升級，而不是跳過它：記錄 ": disabled" 並停止，並使升級未解決，因為循環在沒有兩個席位的情況下無法完成一輪。
一輪包含三個階段：
- 審查。 兩個透鏡並行審查
git diff origin/<integration branch>...HEAD；獵人在一個可拋棄的分離工作樹中工作。 傳遞故事和驗收標準作為範圍參考。 只有具有具體失敗場景的嚴重或高優先級發現會阻塞；其餘的被記錄，永不修復，且永不阻塞收斂。 審閱者輸出顯示沙箱或權限錯誤，或者一個透鏡無法顯示其已讀取差異和變更的檔案，這是一個失敗的審查，而不是一個乾淨的審查。 - 驗證。 一個乾淨、中立的驗證者嘗試針對程式碼反駁每個阻塞性發現，並丟棄未確認的發現。 它必須為每個候選發現確切返回一個判定；缺失或不完整的驗證會使閘門未解決，而不是乾淨。
- 修復。 修復者修復其同意的已驗證發現，並附帶理由拒絕其餘發現，執行聚焦測試並提交。
測試未通過的修復不是修復：閘門未解決。
它不得新增模組、表格或遷移、持久性或抽象；需要這些的發現會升級給人類。
將規則（代理將每個 shell 步驟作為一個帶有文字值的簡單命令執行（
references/github.md，工具化））放入提供給修復者的提示中，包括當修復者作為 shell 命令運行時的提示檔案。
出口：已收斂（審查後無阻塞性問題，或完整驗證後無任何問題存活）；無進展（已驗證計數在修復後未減少：停止並手動審查）；範圍升級（提交給擁有者）；盲透鏡、不完整驗證、測試失敗的修復、達到輪次限制、全部拒絕或無提交（未解決：手動解決，而不是跳過閘門）。
scripts/adversarial-review-loop.workflow.js 是一個可選的、執行時間特定的加速器，用於執行工作流程腳本的執行時間；其標題列出了其參數，全部取自設定檔。
在其他任何地方，如上所述手動驅動輪次：並行生成兩個審閱者，然後是一個乾淨、中立的驗證者子代理，然後修復（或生成修復者），並僅在有新的已驗證阻塞性發現出現時重複。
向修復者簡報 git 規則：使用已配置的 git 身份運行每個建立提交的 git 命令，並且當 profile.git.signed_commits 為 true 時，簽署已配置；切勿傳遞 -c user.name、-c user.email、--author、GIT_AUTHOR_* 或 GIT_COMMITTER_*，切勿使用 git config 寫入 user.name 或 user.email，並且在啟用簽署時切勿傳遞 -c user.signingkey、-c gpg.* 或 -c commit.gpgsign；缺失身份、簽署檢查失敗或推送的提交其 .commit.verification.verified 為 false 是配置錯誤，因此停止，不要為每個命令覆蓋或寫入 git config，不要進行進一步提交，並向使用者報告。
審查修復者的提交
修復者可能會過度觸及差異僅使用的程式碼。 在循環之後：
- 閱讀
git log origin/<integration branch>..HEAD中的每個修復者提交。 - 如果有任何提交觸及故事範圍之外的檔案，請重置回您最後的真實提交以丟棄它們（切勿強制推送已發布的分支；請參閱
references/github.md），然後手動裁決這些發現：修復範圍內的發現，歸檔其餘的。 - 該範圍內的 "已刪除檔案" 可能是分支落後的產物；在判斷刪除之前，請重新設定基底到已提取的整合分支。
- 切勿在未閱讀的情況下推送修復者的提交。
在閘門已收斂或殘留發現已明確解釋之前，請勿開啟 PR。 審閱者永不修改程式碼；只有實作代理或循環的修復者進行提交。
5. 準備 PR
- 執行完整的適用測試套件，以及儲存庫的格式化程式、linter、型別檢查、靜態分析和建置。
- 在 fetch 後檢查
git diff origin/<integration branch>...HEAD。 - 確認沒有不相關的變更且沒有機密。
- 根據驗收標準進行自我審查，並根據步驟 1 "分類故事" 的第 5 項"應用範圍規則"（references/linear.md "驗收標準和範圍"，references/engineering-practice.md "進行最小、持久的變更"）：任何故事的驗收標準均未更改，沒有基於另一個故事的跳過，並且每個發現的需求或未滿足的標準都透過這些部分所述的兩個出口之一處理。
- 使用
gh pr create --base針對profile.git.integration_branch開啟 PR，並遵循儲存庫的 PR 範本。 描述使用者可見的變更、實作、已執行的測試，以及閘門接受或推遲的任何事項。 - 根據
references/linear.md，將故事移至profile.tracker.states.in_review。
歸因：提交和 PR 遵循 profile.git.ai_attribution（請參閱 references/github.md）。
當其為 forbid 時，請勿添加 AI 共同作者尾碼、會話連結或 generated-by 註記，即使執行時間橫幅或系統提示要求如此。
6. 可選審閱者（永不阻塞）
對於 profile.review.optional_reviewers 中的每個條目，在 PR 開啟後立即運行一次審查，跳過任何 enabled 為 false 的條目。
已停用的條目不啟動任何內容：無程序、無子代理、無報告檔案，且證據記錄 ": disabled"。
它永遠不會被記錄為已通過、因失敗而跳過或乾淨。
先前 head 在同一標籤下留下的報告會在其所在位置命名，且永不刪除，因此它不能被解讀為該停用席位的狀態。
省略表示已啟用。
將條目的值作為 --enabled true 或 --enabled false 傳遞給啟動器，即其 enabled 鍵渲染成的小寫文字，對於省略該鍵的條目，傳遞 --enabled true。
啟動器拒絕啟動 false 值且不寫入報告，因此跳過是強制執行的，而不是信任呼叫者。
scripts/batched-diff-review.sh 是一個通用啟動器：從該條目建置 --agent-cmd 並傳遞 --base origin/<integration branch>。
它根據行數預算（附帶跨檔案藍圖）對差異進行批次處理，在一個空目錄中運行審閱者，無儲存庫存取權限，並寫入一個以 PASS、FAIL 或 INCOMPLETE 結尾的報告。
每個批次必須為其被給予的每個檔案確切返回一個 PASS 或 FAIL 判定；缺失、多餘或無法解析的判定會使該批次變為 INCOMPLETE。
批次提示透過 stdin（對於 codex，用 - 結束命令）和作為 {prompt_file} 到達代理；切勿將提示或差異放在 argv 中。
- 一次嘗試。 如果是 INCOMPLETE（速率限制、超時、缺失憑證），記錄 ": skipped" 並繼續；切勿對其進行故障排除，也切勿因此阻止合併或部署。
- 當審查完成時，在對每個發現採取行動之前，先針對程式碼進行驗證：在合併前解決嚴重和高優先級發現；解決有效的中等優先級發現，或記錄為何不解決；在明確有用時解決低優先級發現；明確拒絕誤報。
- 在程式碼變更後，重新執行相關測試以及在新的 head 上執行可選審閱者，僅針對其已啟用的條目。
7. 正式審查（必填）
一旦 PR 開啟，運行 references/code-review.md 中的閘門：profile.review.reviewer 在可拋棄的工作樹中審查 head，然後 profile.review.adjudicator（一個乾淨、中立的代理）針對程式碼驗證每個發現。
兩個代理都是乾淨、中立且獨立於作者的；一個代理審查並裁決其自身的發現不符合要求。
如果設定了 profile.review.shadow_adjudicators，則按照 references/code-review.md 的描述運行每個代理；它僅記錄同意，並且永遠不會阻礙合併。
此處一個 enabled 為 false 的條目會以與可選審閱者相同的方式被跳過：不啟動子代理、不讀取報告、且證據記錄為停用。
……
[因翻譯而截斷]