FE Code Review
預設規則
- 符合使用者的語言。如果使用者寫的是繁體中文，就用繁體中文回覆。
- 將章節標題、狀態標籤與建議翻譯成使用者的語言。若有意義，保留穩定的英文標籤，例如
Blocking：必須修改。 - 對於中文請求，使用所選模式的中文模板。請勿使用純英文的章節標題，例如
Overall Conclusion、Review Scope、Test Gaps或Final Recommendation。 - 預設為唯讀審查。
- 除非使用者明確要求，否則不要修改檔案、格式化檔案、提交、推送、重置、安裝套件、切換分支或執行破壞性命令。
- 請求審查、評估審查品質或輸出審查報告僅授權在聊天中輸出。除非使用者明確要求建立或更新報表、計畫、待辦事項、Markdown 或原始碼檔案，否則不要這麼做。名為 Agent、Build、Write 或類似名稱的客戶端模式不會覆蓋此邊界。
- 根據實際程式碼、差異（diff）、呼叫路徑、資料流、套件版本與執行時合約產出發現。
- 不要僅憑名稱推斷語義。
- 不要將靜態檢查呈現為執行時驗證。
- 不要報告模糊問題。需說明觸發條件、影響、根本原因、建議的修正方法與驗證方式。
- 如果找不到明確問題，請直接說明，並列出剩餘風險或未驗證的區域。
範圍探索
檢查請求的範圍。如果使用者未指定，則審查所有未提交的變更。只收集一次清單。
當請求的範圍是所有未提交的變更時，且在授權的 Skill/工作區邊界內存在 scripts/collect-review-context.mjs 且 Node.js 可用時，請執行該腳本而非發出個別的 Git 清單命令：
node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"
該腳本是唯讀的，會回傳儲存庫根目錄、HEAD、狀態、未暫存（unstaged）的統計資料與修補、已暫存（staged）的修補、未追蹤的檔案、git diff --check 以及 CodeGraph 是否存在。它總是收集完整的未提交工作樹。對於僅審查已暫存、提交、合併提交、分支、PR、範圍或路徑範圍的審查，請勿執行此腳本，因為它會讀取請求範圍之外的變更。對於這些範圍，請使用對應的有界 Git 命令。對於所有未提交的審查，請重複使用收集器的輸出，不要重新執行等效的命令。如果無法在授權邊界內執行該腳本，請在客戶端支援時手動一次性收集相同的證據：
git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard
在審查前建立並報告比較基線：
- 未提交變更：
HEAD對比工作樹，包括已暫存、未暫存以及相關的未追蹤檔案。 - 已暫存變更：
HEAD對比索引。 - 提交：其父提交對比該提交。
- 分支或 PR：合併基線對比目標頭部，除非使用者指定了其他範圍。
- 合併提交：第一個父提交對比合併提交，除非使用者指定了其他父提交或基線。
如果套件或設定檔發生變更，請檢查依賴項與建置影響。務必總結請求的範圍、比較基線、修改的檔案、已暫存的檔案、未暫存的檔案、未追蹤的檔案，以及執行或跳過的驗證命令。
對於修正審查（Fix Review），還要識別先前的審查報告或發現以及修正差異。保持原始的功能範圍與後續的修正範圍分開。
如果儲存庫根目錄存在 .codegraph/ 且 CodeGraph 可用，請在進行廣泛的 grep/find 之前使用它來理解符號、呼叫路徑與影響範圍。
按此順序使用證據：
- 儲存庫原始碼、差異、呼叫路徑、測試、設定、鎖定檔和專案文件。
- 已安裝的依賴項類型與已解析的本地版本來源。
- 僅當版本敏感的框架或函式庫行為仍無法在本地確定時，才通過工具合約允許進行程式碼審查的官方文件管道取得資料。
目前的官方 Context7 MCP 工具合約排除程式碼審查。執行此技巧時，請勿直接或間接使用 Context7。這包括要求子代理、委託、代理、包裝器或其他工具或會話代為呼叫它。請勿透過重新組織、分解、清理或重新標記審查工作為文件問題來繞過此限制。如果結論依賴於外部語義且沒有允許的權威來源，請標記為 無法驗證 並指出缺少的證據。
使用任何外部文件服務時，僅發送用於驗證所需的公開函式庫、版本、API 或清理後的行為問題。切勿發送私有原始碼、差異、儲存庫路徑、內部 API 資料、憑證、令牌、使用者資料或專有識別碼。
條件性瀏覽器執行時證據
僅當以下所有條件成立時，才使用 Playwright 或其他可用的瀏覽器自動化工具：
- 變更的行為是可於瀏覽器中觀察到的，且執行時證據能夠實質性地確認或反駁某個發現，例如路由、表單、非同步 UI 狀態、儲存或 cookies 行為、水合（hydration）、焦點、滾動、響應式溢位或請求順序。
- 存在具體的進入點，例如本地路由、URL、互動或測試工具，且預期的可觀察結果可以從需求、基線行為或現有的測試合約中明確得知。
- 一個合適的本地或隔離測試環境已經可以執行，無需安裝依賴項、更改專案設定或將生成的產物寫入儲存庫。
- 初始狀態是可控且可重複的，或者可以在每次執行前重建，而不依賴於生產資料或真實帳戶。
- 路徑是隔離的，可以在沒有生產存取、真實付款、真實使用者資料、破壞性操作或不可逆的外部副作用的情況下執行。
將瀏覽器驗證保持為唯讀狀態，不對儲存庫、生產系統和真實帳戶造成影響。隔離的本地瀏覽器狀態在場景需要時可以更改，但在可行時重置它，並且不要將該狀態更改視為產品資料驗證。
記錄環境與 URL 類型、進入點、瀏覽器與視口、初始狀態及其重現方式、預期結果、操作、觀察到的結果，以及相關的主控台或網路摘要。遮罩憑證、令牌、個人資料、請求主體與敏感的響應內容。如果需要執行時證據但條件不滿足，請使用 無法驗證 並說明不可用的環境、狀態、期望或能力。
瀏覽器自動化僅證明在所記錄環境中執行的路徑。通過的瀏覽器檢查並不證明在每個瀏覽器或視口中的行為，也無法取代真實的 WebView、Native bridge、裝置、後端、部署、監控或生產環境驗證。
模式選擇
- 預設使用快速審查（Quick Review）處理日常變更、小型 PR、錯誤修正和本地重構。
- 對於付款、認證、路由/導航、WebView bridge、RTC/音訊/視訊、SSR/水合（hydration）、國際化（i18n）、全域狀態/儲存（store）、快取/持久化、建置/部署設定、依賴項升級、共用模組、效能敏感程式碼、發布分支、跨模組行為或大型重構，請使用深度審查（Deep Review）。
- 當使用者要求重新審查修正、驗證先前的發現、檢查審查意見是否已解決，或檢測由修正引入的回歸時，請使用修正審查（Fix Review）。
在審查前載入一個模式參考檔案：
- 快速審查：
references/quick-review.md - 深度審查：
references/deep-review.md - 修正審查：
references/fix-review.md
對於修正審查，在當前對話中可用時使用先前的發現。否則要求使用者提供先前的審查報告、問題清單或其可讀取的路徑。如果沒有可用的基線，請勿編造先前的發現或聲稱某個問題已解決。
技術偵測
檢查專案檔案並僅載入匹配的參考：
- React：對於 React、React DOM、Next.js、Remix、JSX/TSX 或 hooks，載入
references/react.md。 - Vue：對於 Vue、Nuxt、Pinia、
.vue檔案或 Composition API，載入references/vue.md。 - TypeScript：對於 TypeScript 專案或變更的 TypeScript 合約，載入
references/typescript.md。 - JavaScript：對於 JavaScript 專案或執行時形態較重的程式碼，載入
references/javascript.md。 - 混合/WebView：對於 bridge、原生合約、WebView、應用程式殼層（app shell）、儲存、鍵盤、安全區域、音訊或視訊，載入
references/hybrid-webview.md。 - 發布風險：對於深度審查、發布分支、功能標誌（feature flags）、部署、監控、回滾或高風險流程，載入
references/release-risk.md。
快速/修正審查的證據原則
對快速審查和修正審查應用以下強制執行規則。它們減少了重複探索，但不會減少所需的覆蓋範圍：
- 當客戶端支援批次處理時，對每個證據群組使用一次有界的唯讀往返：已選取的 Skill/參考檔案；初始上下文收集器或其手動備用方案；變更的檔案和基線原始碼加上直接消費者的搜尋；以及其餘適用的驗證。僅當第一個結果揭示了新的未解決合約時，或為了防止結果過大難以管理時，才分割群組。不要只是為了減少命令次數而串接不相關的大型檔案。
- 凍結並重複使用初始的 Git 清單。在唯讀審查中，不要在最後重複狀態、name-status、stat、已暫存的差異、未追蹤檔案或未變更的差異查詢。主機評估器（而非審查模型）會執行任何獨立的執行後完整性比較。
- 每個選定的指令、差異、基線檔案和重疊的原始碼範圍只讀取一次。優先選擇涵蓋所需範圍的帶行號的讀取。在重複讀取或搜尋之前，先確定具體的未解決證據問題；當現有輸出已能回答該問題時，跳過該命令。
- 在已知變更的檔案和直接受影響的路徑後，不要從
.執行廣泛的rg搜尋，或執行未過濾的rg --files/儲存庫檔案清單。將搜尋範圍限定於變更的擁有者、命名的符號和直接受影響的路徑；僅當具體匹配暴露了另一個消費者或合約時才擴大範圍。 - 根據變更的檔案類型、匯入和最多一次相關的 manifest 讀取來偵測技術。僅在套件、鎖定、建置或 TypeScript 設定發生變更，或某個發現依賴於其已解析的版本或編譯器/建置合約時，才更深入地檢查它們。不要僅僅為了完成通用檢查清單而探查不存在的設定或鎖定檔。
- 使用已知存在的路徑或一個有界的檔案名稱 glob 查詢，搜尋一次直接相關的測試。如果該搜尋確定沒有適用的測試，則記錄此缺口；不要在沒有新證據的情況下重複猜測測試目錄名稱或替代的儲存庫範圍模式。
- 將獨立的表達式或確定性檢查（這些檢查會執行相同的行為合約）組合成一次驗證往返。不要僅僅為了準備最終解釋而重新執行差異。
- 當使用者或評估器明確聲明一個合成的
HEAD代表原始問題基線時，驗證當前的HEAD和修正差異，然後使用該聲明的基線。將不可用的原始提交物件記錄為證據限制，而不是在閉合不依賴於它們時探測每個物件。 - 每當證據衝突、變更的條件仍未分類、直接受影響的合約未解決，或某個發現仍然缺乏其觸發條件和影響時，請繼續處理這些群組。這些是完整性規則，而不是硬性的命令或令牌上限。
- 當請求的基線和差異已確定、範圍內每個變更條件帳本條目都已記錄、每個報告的發現都有足夠證據、必要的驗證已完成或被明確限制，且選定的輸出合約可以一致地填滿時，停止探索。不要僅僅為了提高主觀信心而擴大搜尋範圍。
變更前/後行為分析
在每種模式下執行此分析。比較行為，而不僅僅是變更的行數：
- 識別變更前的行為和變更後的預期行為。
- 檢測被移除、弱化或無意保留的行為。
- 檢查缺失的分支、防護、回退、清理、取消、重試和錯誤處理。
- 在確定發現優先級之前，為請求的差異中修改的決策區塊內每個新增、變更、移動、拆分或保留的條件、防護、回退、預設值和提前返回（early return），建立一個緊湊的內部變更條件帳本。當文字上未變更的防護周圍的控制流程、返回行為或狀態寫入發生變更時，它仍然在範圍內。比較每個分支在變更前後分別接收哪些執行時值；預設不輸出該帳本。
- 在該帳本中，區分缺失（
null或undefined）與有效的假值（falsy values），例如0、false或空字串。對於這些分支後的狀態寫入，追蹤從先前的真值（truthy）或非空值到每個有效假值的轉換，通過直接受影響的消費者；不要僅隔離地檢查當前值。 - 在最終確定之前，說明帳本中的每個條目：將其分類為行為保留、證據缺口或一個發現。僅在驗證保留的行為本身對於可見的執行時合約和狀態轉換仍然正確時，才使用行為保留。如果一個修改的決策區塊保留了一個實質性的缺陷，請報告它並將其標識為保留的缺陷，而不是由差異引入的回歸。不要僅僅因為另一個發現更嚴重就省略一個受影響的變更條件。
- 追蹤受影響的呼叫者、消費者、事件、API 合約、儲存、快取和執行時資料形狀。
- 確認行為
… [原文已截斷，翻譯至此]