代理就緒度審計
根據以下清單審計當前儲存庫，並報告差距。這是一次唯讀審計：切勿修改、建立或刪除儲存庫中的任何檔案。
第一步：探索技術棧
在做出判斷之前，先確認：
- 語言、框架、套件管理器、Monorepo 結構
- 正在使用的 Linter、Formatter 和 Typechecker
- 測試執行器
- Hook 管理器（husky, lefthook, pre-commit, simple-git-hooks, 一般的 .git/hooks）
- CI 系統及其配置
- 代理指令檔案（AGENTS.md, CLAUDE.md, .cursorrules, copilot-instructions 等）
- 包含技能、操作手冊、提示或工作流程文件的目錄
使用此儲存庫實際使用的工具進行評估。除非現有工具無法勝任，否則不要建議更換工具。
預算
- 從目錄列表、配置檔案和指令檔案開始。使用 grep、計數和檔案列表，而非完整讀取原始檔案。
- 每個主要套件最多抽樣 3 個代表性檔案。
- 如果儲存庫過大無法涵蓋，請說明哪些部分未被檢查。
第二步：評估每個檢查項目
為每個項目分配一個狀態：
- PASS：明確存在且運作正常
- PARTIAL：存在但不完整、過時、未強制執行或不一致
- MISSING：已檢查但不存在
- N/A：不適用於此技術棧（請說明原因）
- UNCLEAR：無法檢查（請說明阻礙原因，例如外部 CI 或未檢查的部分）
每個狀態都需附上證據：檔案路徑、配置鍵或簡短的引述片段（每個不超過 15 個單詞）。切勿猜測：如果檢查後找不到，標記為 MISSING；如果無法檢查，標記為 UNCLEAR。
檢查清單
- 共用的代理指令
- 所有代理和新進工程師都能讀取的單一根層級指令檔案
- 涵蓋程式碼風格規則（匯出風格、匯入結構、檔案組織、反模式）
- 要求在信任邊界驗證外部資料
- 說明哪些測試值得撰寫
- 定義完成閘道：在提交前必須通過 Lint、Typecheck 和相關測試
- 內容最新且具體。抽樣檢查 3 到 5 條規則是否與實際程式碼相符，並報告程式碼是否遵循這些規則。
- 儲存庫內的工作流程技能
- 將重複性工作流程記錄為程式碼旁的逐步技能或操作手冊
- 涵蓋範圍：提交、開啟/堆疊 PR、程式碼審查、讓 PR 通過 CI、相依性變更、本地化
- 涵蓋特定技術棧的工作流程（資料層、路由器、設計系統、程式碼生成等）
- 每個技能都有觸發條件、步驟順序和完成定義
- 技能是唯一真實來源，不可重複或矛盾
- 以 Lint 規則強制執行的慣例
- 已文件化的慣例有對應的 Lint 規則
- 自訂 Lint 規則或外掛涵蓋針對專案的用法（資料擷取、樣式、測試、翻譯）
- 針對常見代理錯誤存在反模式規則：鏈式或不必要型別斷言、鬆散型別參數 (unknown/any)、空物件的條件展開，以及在此程式碼庫中發現的任何重複低品質模式
- 規則應為錯誤，而非警告，並且沒有全面禁用
- 自動化閘道
- Pre-commit hook 會格式化、Lint 和 Typecheck 已變更的程式碼
- Pre-push hook 會 Lint 或測試受影響的套件，包括依賴項
- CI 會重新執行相同的檢查，因此 hook 無法被繞過
- Hook 速度合理
- Hook 已連接：Hook 配置已提交，存在安裝步驟（prepare script、設定文件或 core.hooksPath），且其呼叫的命令存在。透過讀取檔案驗證；切勿執行 hook。
- 監督與結構
- 架構決策已文件化
- 合併前需要 PR 審查（若可見，檢查分支保護或 CODEOWNERS）
- 套件和模組邊界清晰且強制執行
第三步：找出未文件化的慣例
從程式碼中取樣，找出雖然一致應用但未在任何地方寫下的模式，以及代理經常出錯的模式（鬆散型別、未驗證的外部資料、不一致的匯出、重複的邏輯）。列出前 5 個應加入指令檔案或轉換為 Lint 規則的候選項目。
第四步：報告
產出：
- 摘要表格：項目、狀態、一行證據
- 「差距」章節：每個 PARTIAL、MISSING 或 UNCLEAR 的項目、問題所在，以及對代理可靠性的重要性
- 優先級建議清單（從槓桿最高者開始），每個附有具體的下一步驟和粗略工作量（小/中/大），並以此儲存庫現有工具的角度表述
- 來自第三步的前 5 個候選慣例
直接了當。不要用誇獎來填充。如果某件事沒問題，就說 PASS 然後繼續。
報告完成後，主動提供搭建缺失部分（入門指令檔案、技能範本、Lint 規則骨架）的協助，但請在獲得請求後才實際建立任何內容。