程式碼審查技能

根據 WCAG 2.2 指南審核並改善網頁無障礙性。當被要求「改善無障礙性」、「無障礙審核」、「WCAG 合規」、「螢幕閱讀器支援」、「鍵盤導航」或「使其無障礙」時使用。

針對深度學習研究儲存庫的嚴謹分析與稽核唯讀技能。當使用者希望閱讀並理解儲存庫、檢查模型結構與訓練或推論入口點、審查配置與插入點，或標記可疑的實作模式，且不修改程式碼或執行大量作業時使用。不適用於主動指令執行、大規模重構、推測性程式碼調整或自動錯誤修正。

生成 Angular 程式碼並提供架構指導。在建立專案、元件或服務時觸發，或針對反應性（signals、linkedSignal、resource）、表單、依賴注入、路由、SSR、無障礙（ARIA）、動畫、樣式（元件樣式、Tailwind CSS）、測試或 CLI 工具的最佳實踐。

應用現代網頁開發的最佳實踐，以確保安全性、相容性與程式碼品質。當被要求「套用最佳實踐」、「進行安全稽核」、「現代化程式碼」、「程式碼品質審查」或「檢查漏洞」時使用。

We need to translate the given text from English to Traditional Chinese. The text describes a decision guide for delegating to caveman-style subagents. It mentions specific names: cavecrew-investigator, cavecrew-builder, cavecrew-reviewer, and cavecrew. These names should be preserved as is. Also, technical terms like "Explore", "diff review", "tool-result", "main context" should be preserved or appropriately translated. The instruction says to preserve product names, protocol names, URLs, numbers, and technical terms. So we keep "cavecrew-investigator", "cavecrew-builder", "cavecrew-reviewer", "cavecrew", "Explore", "diff review", "tool-result", "main context". Also "~60%" should be preserved. The text inside <text> is the entire paragraph. We need to output only the translation, no extra commentary. Let's translate carefully: "Decision guide for delegating to caveman-style subagents." -> "委派給原始人風格子代理的決策指南。" "T

超壓縮提交訊息生成器。去除提交訊息中的雜訊，同時保留意圖與理由。採用 Conventional Commits 格式。主旨不超過50字元，僅在「原因」不明顯時加入內文。當使用者說「寫提交」、「提交訊息」、「生成提交」、「/commit」或呼叫 /caveman-commit 時使用。暫存變更時自動觸發。

超壓縮程式碼審查評論。減少PR回饋中的雜訊，同時保留可執行的關鍵資訊。每條評論僅一行：位置、問題、修正。當使用者說「審查此PR」、「程式碼審查」、「審查差異」、「/review」或呼叫/caveman-review時使用。審查拉取請求時自動觸發。

審查程式碼差異、PR、問題佇列、發佈就緒狀態、提交、推送、發佈及專案稽核。當使用者要求 review/看看程式碼/合併前/看看issue/PR/release/push，或執行已核准的計畫時使用，並對髒亂及未追蹤的工作目錄設有安全閘門。不適用於探索想法、除錯根本原因或文字審閱。

比較拉取請求的實作與 spec_context.md 中的規格上下文，並將任何重大不符之處寫入 review.json。在審查拉取請求時使用，當已核准或儲存庫規格上下文可用時。

從固定點（提交、分支、標籤或合併基礎）開始，沿兩個軸審查變更——標準（程式碼是否遵循此儲存庫記錄的編碼標準？）與規格（程式碼是否符合原始問題/PRD 的要求？）。透過平行子代理執行兩項審查，並並排報告結果。當使用者想要審查分支、PR、進行中的變更，或要求「從 X 開始審查」時使用。

執行多維度程式碼審查。在合併任何變更前使用。在審查自己、其他代理或人類撰寫的程式碼時使用。當需要在程式碼進入主分支前從多個面向評估程式碼品質時使用。

簡化程式碼以提升清晰度。適用於重構程式碼以增進可讀性但不改變行為時。適用於程式碼雖可運作但難以閱讀、維護或擴展時。適用於審查已累積不必要複雜性的程式碼時。

設計深度模組的共享詞彙。當使用者想要設計或改善模組介面、尋找深化機會、決定接縫位置、讓程式碼更易於測試或AI導航，或其他技能需要深度模組詞彙時使用。

Conventional Commits v1.0.0 分支命名、工作樹命名及提交訊息標準，適用於 GitHub 與 GitLab 專案。用於建立分支、命名工作樹、撰寫提交、生成提交訊息、審查分支慣例或設定變更日誌自動化。當專案需要一致的 Git 歷史、語意化版本驅動的發佈、可解析的變更日誌生成或自動關閉議題時適用。在使用者詢問如何命名工作樹、建立 Git 工作樹或...時觸發。

在 warp 儲存庫中為當前分支建立拉取請求。當使用者提及開啟 PR、建立拉取請求、提交變更以供審查或準備合併程式碼時使用。

引導系統性的根本原因除錯。當測試失敗、建置中斷、行為不符合預期，或遇到任何非預期錯誤時使用。當你需要系統性的方法來找出並修復根本原因，而非胡亂猜測時使用。

管理棄用與遷移。用於移除舊系統、API或功能時。用於將使用者從一個實作遷移至另一個時。用於決定是否維護或終止現有程式碼時。

針對難以解決的錯誤與效能回歸問題，採用嚴謹的診斷循環流程：重現 → 最小化 → 假設 → 檢測 → 修復 → 回歸測試。當使用者提出「診斷這個」/「除錯這個」、回報錯誤、表示某功能損壞/拋出異常/失敗，或描述效能回歸情況時啟用。

針對難以解決的錯誤與效能回歸的診斷循環。當使用者說「診斷/除錯這個」，或回報某個東西損壞、拋出錯誤、失敗、緩慢時使用。

當您有書面執行計畫需要在獨立會話中執行並包含審查檢查點時使用

We need to translate the given text from English to Traditional Chinese. The text is a description of an agent skill named "explore-code". The instruction says to preserve the name "explore-code" if it appears in the source text. It does appear in the source text: "explore_outputs/" and "explore-code" is the name but not directly in the text? Actually the name is "explore-code" but the text mentions "explore_outputs/". The instruction says "Do not include the name unless it appears in the source text." The name "explore-code" does not appear in the source text; only "explore_outputs/" appears. So we should not add "explore-code" anywhere. We just translate the text inside <text>. Also preserve technical terms like LoRA, adapter layers, etc. No extra commentary. Let's translate carefully. Original: "Rigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated branch or worktree to transplant

引導使用 TypeScript 或 JavaScript 開發 Fastify Node.js 後端伺服器與 REST API。適用於建置、設定或除錯 Fastify 應用程式時，包括定義路由、實作外掛、設定 JSON Schema 驗證、處理錯誤、最佳化效能、管理驗證、設定 CORS 與安全標頭、整合資料庫、使用 WebSocket，以及部署至正式環境。涵蓋完整的 Fastify 請求生命週期（鉤子、...）

在實作完成、所有測試通過，且需要決定如何整合成果時使用——透過提供合併、拉取請求或清理的結構化選項，引導開發工作的完成。

修復 warp Rust 程式碼庫中的編譯錯誤、lint 問題與測試失敗。涵蓋 presubmit 檢查、WASM 特定錯誤，以及執行特定測試。當使用者遇到建置錯誤、clippy 或 fmt 失敗、測試失敗，或需要在 PR 前執行或解讀 presubmit 時使用。

覆寫預設的LLM截斷行為。強制完整程式碼生成，禁止佔位符模式，並乾淨處理token限制分割。適用於任何需要詳盡、完整輸出的任務。

結構化 git 工作流程實務。在進行任何程式碼變更時使用。在提交、分支、解決衝突，或需要跨多個平行串流組織工作時使用。在進行版本發布、選擇語意化版本升級、標記標籤或撰寫變更日誌時使用。

Golang 基準測試、效能剖析與效能測量。適用於撰寫、執行或比較 Go 基準測試，使用 pprof 對熱點路徑進行效能剖析，解讀 CPU/記憶體/追蹤分析結果，透過 benchstat 分析結果，設定 CI 基準測試回歸檢測，或使用 Prometheus 執行時期指標調查生產環境效能。也適用於開發者需要針對特定效能指標進行深入分析時——此技能提供測量方法論，同時...

Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).

Golang 並發模式。在撰寫或審查涉及 goroutine、channel、select、鎖、同步原語、errgroup、singleflight、工作者池或扇出/扇入管線的並發 Go 程式碼時使用。當偵測到 goroutine 洩漏、競態條件、channel 所有權問題，或需要在 channel 與 mutex 之間做出選擇時，也會觸發。

Go語言中依賴注入（DI）的全面指南。涵蓋DI的重要性（可測試性、鬆散耦合、關注點分離、生命週期管理）、手動建構子注入，以及DI函式庫比較（google/wire、uber-go/dig、uber-go/fx、samber/do）。在設計服務架構、設定依賴注入、重構緊密耦合程式碼、管理單例或服務工廠，或當使用者詢問控制反轉、服務等問題時，使用此技能。

符合慣例的 Golang 設計模式 — 函數選項、建構子、錯誤流程與串聯、資源管理與生命週期、優雅關閉、韌性、架構、依賴注入、資料處理、串流等。適用於明確選擇架構模式、實作函數選項、設計建構子 API、設定優雅關閉、應用韌性模式，或詢問哪種慣用 Go 模式適合特定問題時。

Golang 專案的全面文件指南，涵蓋 godoc 註解、README、CONTRIBUTING、CHANGELOG、Go Playground、範例測試、API 文件及 llms.txt。適用於撰寫或審查文件註解、文件內容、新增程式碼範例、設定文件網站，或討論文件最佳實務。同時適用於函式庫與應用程式/命令列工具。

We need to translate the given text from English to Traditional Chinese. The text is about Golang error handling. We must preserve the name "golang-error-handling" but it's not in the text, so we don't include it. Also preserve technical terms like %w, errors.Is/As, errors.Join, panic/recover, slog, samber/oops, etc. No extra commentary, no labels. Just the translation. Let's translate sentence by sentence: "Idiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors." Translation: "慣用的 Golang 錯誤處理 — 建立、使用 %w 包裝、errors.Is/As、errors.Join、自訂錯誤類型、哨兵錯誤、panic/recover、單一處理規則、使用 slog 的結構化日誌、HTTP 請求日誌中介軟體

在 Golang 中使用 google/wire 進行編譯時期依賴注入 — wire.NewSet、wire.Build、wire.Bind（介面→具體實作）、wire.Struct、wire.Value、wire.InterfaceValue、wire.FieldsOf、清理函式、//go:build wireinject 注入器

提供gRPC使用指南、protobuf組織方式，以及適用於Golang微服務的生產級模式。適用於實作、審查或除錯gRPC伺服器/客戶端、撰寫proto檔案、設定攔截器、使用狀態碼處理gRPC錯誤、配置TLS/mTLS、使用bufconn進行測試，或處理串流RPC時使用。

Golang 技能編排器 — 在任何 Golang 編碼、審查、除錯或設定任務中始終保持啟用。讀取任務上下文並從 samber/cc-skills-golang 載入最相關的技能，通常一次載入多個：撰寫 gRPC 服務時載入 golang-grpc + golang-testing + golang-error-handling；除錯 panic 時載入 golang-troubleshooting + golang-safety；審查安全性時載入 golang-security + golang-lint + golang-safety。此外：當兩個技能看似重疊時，消除競爭叢集的歧義...

針對 Golang 專案的 lint 最佳實務與 golangci-lint 配置 — 執行 linter、設定 .golangci.yml、使用 nolint 指令抑制警告、解讀 lint 輸出，以及選擇 linter。適用於配置 golangci-lint、詢問 lint 警告或 nolint 抑制方式、設定程式碼品質工具，或挑選 linter 時。亦適用於使用者提及 golangci-lint、go vet、staticcheck 或 revive 時。

golang-linter — 一個可安裝的 AI 代理技能。

將 Golang 程式碼現代化，使用最新的語言特性、標準函式庫改進及慣用模式。在撰寫或審查 Go 程式碼時，若偵測到舊式模式或遇到棄用警告，應主動觸發。當使用者明確要求現代化、Go 版本升級或 CI/工具鏈更新時，也應採用。

Go (Golang) 命名慣例 — 涵蓋套件、建構子、結構體、介面、常數、列舉、錯誤、布林值、接收器、getter/setter、函數選項、縮寫、測試函數及子測試名稱。在撰寫新 Go 程式碼、進行程式碼審查或重構、選擇命名替代方案（New 與 NewTypeName、isConnected 與 connected、ErrNotFound 與 NotFoundError、StatusReady 與 StatusUnknown 在 iota 0 時）、討論 Go 套件名稱（utils/helpers 反模式）時，可使用此技能。

Golang 性能優化模式與方法論 - 若遇到 X 瓶頸，則應用 Y。涵蓋減少分配、CPU 效率、記憶體佈局、GC 調校、池化、快取以及熱路徑優化。適用於當性能分析或基準測試已識別出瓶頸，且需要正確的優化模式來解決時。亦適用於進行性能代碼審查時，提出改進建議或可協助快速識別性能增益的基準測試。不適用於測量方法論（→...

推薦適合生產環境的 Golang 函式庫與框架。適用於使用者明確要求函式庫建議、想比較替代方案、需要為特定任務選擇函式庫，或專案中正在新增相依套件時。

防禦性Golang編碼，用於防止恐慌、靜態數據損壞及微妙的運行時錯誤。在遇到nil恐慌、追加別名、映射並發訪問、浮點數比較陷阱或零值設計問題時使用。亦適用於審查代碼中的nil安全性、數值轉換溢出、資源生命週期問題（循環中的defer），或切片與映射的防禦性拷貝。

在 Golang 中使用 samber/do 進行依賴注入 — 服務容器、生命週期管理、作用域、健康檢查、優雅關閉與模組組織。適用於使用或採用 samber/do 時、程式碼導入 github.com/samber/do 或 github.com/samber/do/v2 時，或將手動建構子注入重構為 DI 容器時。

Monadic types for Golang using samber/mo — Option, Result, Either, Future, IO, Task, and State types for type-safe nullable values, error handling, and functional composition with pipeline sub-packages. Apply when using or adopting samber/mo, when the codebase imports `github.com/samber/mo`, or when considering functional programming patterns as a safety design for Golang.

Golang的安全最佳實踐與漏洞防範。涵蓋注入攻擊（SQL、命令、XSS）、密碼學、檔案系統安全、網路安全、Cookie、機密管理、記憶體安全及日誌記錄。適用於撰寫、審查或稽核Go程式碼的安全性，或處理涉及加密、I/O、機密管理、使用者輸入處理或身分驗證的高風險程式碼。包含安全工具的配置。

我们要求翻译一段文本，目标语言是繁体中文。需要保留产品名、协议名、URL、数字、技术术语。不要添加声明、解释、Markdown、项目符号、链接、标签、前缀或额外评论。只翻译<text>内的内容，不包括名称除非它出现在源文本中。不要添加"description"等标签。 源文本是英文，描述了一个Golang配置库spf13/viper的功能。需要翻译成繁体中文。注意技术术语如"flag", "env", "file", "KV", "default", "BindPFlag", "SetEnvPrefix", "SetEnvKeyReplacer", "AutomaticEnv", "ReadInConfig", "ConfigFileNotFoundError", "Unmarshal", "mapstructure struct tags", "Sub", "WatchConfig", "OnConfigChange", "hot reload", "viper.New()", "test isolation", "remote KV integration"等应该保留英文或翻译成常见的中文技术术语？要求保留技术术语，但通常中文技术文档中会使用英文

全面指南，介紹 stretchr/testify 在 Golang 測試中的應用。深入涵蓋 assert、require、mock 與 suite 套件。適用於使用 testify 撰寫測試、建立 mock、設定測試套件，或選擇 assert 與 require 時。內容包含 testify 斷言、mock 預期行為、參數匹配器、呼叫驗證、套件生命週期，以及 Eventually、JSONEq 與自訂匹配器等進階模式。當程式碼匯入 github.com/stretchr/testify 時適用。

Golang 結構體與介面設計模式 — 組合、嵌入、型別斷言、型別切換、介面隔離、透過介面進行依賴注入、結構體欄位標籤，以及指標接收器與值接收器。在設計 Go 型別、定義或實作介面、嵌入結構體或介面、撰寫型別斷言或型別切換、為 JSON/YAML/DB 序列化新增結構體欄位標籤，或選擇指標接收器與值接收器時，使用此技能。亦在使用者...

We need to translate the given text from English to Traditional Chinese. The text describes a Go testing skill. We must preserve the name "golang-testing" but it's not in the text, so we don't include it. We also preserve technical terms like "table-driven tests", "testify suites and mocks", "parallel tests", "fuzzing", "fixtures", "goroutine leak detection with goleak", "snapshot testing", "code coverage", "integration tests", "idiomatic test naming", "Go tests", "Go test CI", "flaky/slow tests", "testify-specific APIs", "samber/cc-skills-golang@golang-stretchr-testify", "measurement methodology". Also preserve URLs? There is no URL. Numbers? None. Technical terms should be kept as is or translated if common? Usually in Chinese tech context, terms like "table-driven tests" might be translated as "表格驅動測試" but often kept in English. The instruction says "preserve product names, protocol names, URLs,

當使用者想要「撰寫代理程式碼」、「使用 ADK 建置代理程式」、「新增工具」、「建立回呼」、「定義代理程式」、「使用狀態管理」，或需要 ADK（代理程式開發套件）Python API 模式與程式碼範例時，應使用此技能。屬於 Google ADK 技能套件的一部分。提供代理程式類型、工具定義、編排模式、回呼與狀態管理的快速參考。請勿用於建立新專案（請使用 google-agents-cli-scaffold）或部署...

執行預算感知的代理輔助工程健康審計，針對指令/配置漂移、hooks/MCP、驗證器表面及AI可維護性。當用戶要求檢查claude/檢查codex/檢查pi/配置檢查/健康度，或回報代理忽略指令、缺少驗證、程式碼難以維護時使用。不適用於除錯程式碼或審查PR。

在應用修正前找出錯誤、崩潰、回歸、測試失敗、行為異常及截圖回報缺陷的根本原因。當使用者提到「排查/報錯/崩潰/不工作/回歸/判斷為什麼報錯」，或表示某功能原本正常但現在失效時使用。不適用於程式碼審查或新功能開發。

安裝並將註冊區塊與元件接入 HyperFrames 組合中。適用於執行 hyperframes add、安裝區塊或元件、將已安裝項目接入 index.html，或處理 hyperframes.json 時使用。涵蓋 add 指令、安裝位置、區塊子組合接入、元件片段合併、註冊表探索，以及編寫新區塊或元件以向上游貢獻（構想 → 骨架 → 驗證 → PR）。

根據產品需求文檔或一系列問題來實施一項工作。

根據已核准的 PRODUCT.md 與 TECH.md 實作功能，在開發過程中保持規格與程式碼同步於同一個 PR 中。請於產品與技術規格核准後、下一步為建置功能時使用。

以資深顧問身份審查任何程式碼庫，並產出優先排序、可獨立執行的實作計畫，供其他模型/代理執行。嚴格以唯讀方式檢視原始碼——本身絕不實作、修復或重構任何內容。適用於被要求審查程式碼庫、尋找改善機會（錯誤、安全性、效能、測試覆蓋率、技術債、遷移、開發體驗）、建議功能或專案下一步方向（路線圖、產品策略），或為其他代理生成交接計畫時使用。

在程式碼庫中尋找深化機會，依據 CONTEXT.md 中的領域語言與 docs/adr/ 中的決策。適用於使用者想要改善架構、尋找重構機會、整合緊密耦合的模組，或讓程式碼庫更易於測試及便於 AI 導航時使用。

將 React 專案與元件從 Radix UI 遷移至 Base UI。適用於被要求從 radix 遷移、轉移至 base-ui、轉換 radix 基本元件，或切換 shadcn 專案的基礎函式庫時。可處理單一元件（如「遷移 accordion」）與整個專案。

Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

We need to translate the given English text into Traditional Chinese. The instruction says: preserve product names, protocol names, URLs, numbers, and technical terms. Do not add claims, explanations, Markdown, bullets, links, labels, prefixes, or extra commentary. Also, do not include the name "minimal-run-and-audit" unless it appears in the source text. The source text does not include that name, so we just translate the text inside <text>. The text describes a skill for "Rigor Run" for deep learning repo reproduction. It specifies when to use and when not to use. We need to translate accurately, keeping technical terms like "README-first", "repro_outputs/", "patch notes", etc. Also "smoke test", "inference", "evaluation", "training execution", "initial repo intake", "generic environment setup", "paper lookup", "target selection", "hidden scientific-meaning changes", "end-to-end orchestration". We should use appropriate Traditional Chinese terms. Let's translate: "Rigor Run skill for READ

探索並理解 Nx 工作區。在回答有關工作區、專案或任務的問題時使用。當 nx 命令失敗，或需要在執行任務前檢查可用的目標/配置時，也請使用。範例：「這個工作區有哪些專案？」、「專案 X 是如何配置的？」、「哪些項目依賴函式庫 Y？」、「我可以執行哪些目標？」、「找不到任務的配置」、「除錯 nx 任務失敗」。

強制採用實際可行、最簡單、最短、最精簡的懶人解法。模擬見多識廣的資深開發者：質疑任務是否真的需要存在（YAGNI），優先使用標準函式庫而非自訂程式碼，原生平台功能而非依賴套件，一行程式碼勝過五十行。支援強度等級：輕量、完整（預設）、極致。當使用者說出「ponytail」、「be lazy」、「lazy mode」、「simplest solution」、「minimal solution」、「yagni」、「do less」或...時啟用。

針對整個儲存庫進行過度工程審計。類似ponytail-review，但掃描整個程式碼庫而非差異：提供一份排名清單，列出應刪除、簡化或替換為標準庫/原生等效項目的內容。當使用者說「審計此程式碼庫」、「審計過度工程」、「我可以從此儲存庫刪除什麼」、「找出臃腫」、「ponytail-audit」或「/ponytail-audit」時使用。一次性報告，不套用修復。

Harvest every `ponytail:` comment in the codebase into a debt ledger, so the deliberate shortcuts and deferrals ponytail leaves behind get tracked instead of rotting into "later means never". Use when the user says "ponytail debt", "/ponytail-debt", "what did ponytail defer", "list the shortcuts", "ponytail ledger", or "what did we mark to do later". One-shot report, changes nothing.

專注於過度工程的程式碼審查。找出可刪除的內容：重新發明的標準函式庫、不必要的依賴、推測性抽象、無用的靈活性。每個發現一行：位置、要刪除的內容、替代方案。當使用者說「審查過度工程」、「我們可以刪除什麼」、「這是否過度工程」、「簡化審查」或呼叫 /ponytail-review 時使用。與正確性導向的審查互補，此審查僅針對複雜性。

pr-to-video 工作流程 - 一個 GitHub 拉取請求（網址格式如 github.com/ / /pull/ 、或 / # 、或在已檢出儲存庫中的「this PR」）-> 擷取 PR 資訊（標題、內容、差異、提交、檔案、增減統計）-> narrator_scripts.json + 音訊（語音 + 背景音樂）+ section_plan.md -> 程式碼差異 / 前後對比 / 影響說明影片。輸入內容為程式碼變更。該網址為 PR 連結，非行銷網站（無需爬取）；非文字摘要，亦非產品網站。若輸入非 PR 內容（產品網站、一般網站、主題文字），...

生成一個靜態互動式 D3 拉取請求逐步導覽。當使用者想要可縮放的 PR 地圖、圖表/畫布 PR 導覽，或 PR 系統元件、資料流、程式碼相依性及使用者操作的替代視覺化時使用。

互動式 QA 環節，使用者以對話方式回報錯誤或問題，代理程式會建立 GitHub 議題。在背景中探索程式碼庫以取得上下文與領域語言。當使用者想以對話方式回報錯誤、進行 QA、建立議題，或提及「QA 環節」時使用。

在接收程式碼審查意見時使用，特別是在意見不明確或技術上存疑時，於實施建議之前——需要技術嚴謹性與驗證，而非形式上的同意或盲目執行。

將現有網站與應用程式升級至頂級品質。審核當前設計，識別通用AI模式，並在不破壞功能的前提下應用高端設計標準。適用於任何CSS框架或原生CSS。

透過使用者訪談，建立包含小型提交的詳細重構計畫，並將其歸檔為 GitHub 議題。適用於使用者想要規劃重構、建立重構 RFC，或將重構拆解為安全漸進步驟時。

在完成任務、實作主要功能或合併前使用，以驗證工作是否符合需求

Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when `git status` shows unmerged paths, or when files contain conflict markers.

當你需要解決進行中的 Git 合併/重定基礎衝突時使用。

從固定起點（提交、分支、標籤或合併基準）開始，沿兩個維度審查變更——標準（程式碼是否遵循此儲存庫記錄的編碼標準？）與規格（程式碼是否符合原始問題/PRD 的要求？）。由兩個並行子代理分別執行審查，並將結果並排呈現。當使用者希望審查分支、PR、進行中的變更，或要求「從 X 開始審查」時使用。

審查拉取請求的差異，並將結構化反饋寫入 review.json，以供工作流程發布。適用於從本地工件（如 pr_diff.txt 和 pr_description.txt）審查已檢出的拉取請求，並產生機器可讀的審查輸出，而非直接發布到 GitHub。

針對深度學習研究工作的嚴謹除錯/嚴謹審查技能。當使用者貼出追蹤回溯、終端錯誤、CUDA記憶體不足、檢查點載入失敗、形狀不匹配、NaN損失症狀或訓練失敗，並希望在進行任何修補前獲得保守診斷，且除錯修復與研究貢獻明確區分時使用。請勿用於大規模重構、推測性改編、自動探索性修補或一般性倉庫熟悉。

在當前儲存庫中設定 Husky pre-commit hooks，包含 lint-staged（Prettier）、型別檢查與測試。當使用者想要新增 pre-commit hooks、設定 Husky、配置 lint-staged，或加入提交時的格式化/型別檢查/測試時使用。

snyk-agent-scan 的合規專家 — 僅針對代理技能檔案掃描器，不適用於其他 Snyk CLI 工具（snyk test、snyk code SAST、snyk iac、snyk container）。透過內容重組修復警報，絕不壓制或刪除資訊。涵蓋技能目錄中的所有檔案：SKILL.md、references/、assets/ 以及任何次要 markdown。適用於撰寫新技能、編輯現有技能、在本地或 CI 中處理失敗的 snyk-agent-scan 執行，或解除因代理而受阻的 PR...

將每個實作決策建立在官方文件之上。當你需要權威且附有來源引用的程式碼，避免使用過時模式時使用。當你使用任何重視正確性的框架或函式庫進行開發時使用。

遇到任何錯誤、測試失敗或異常行為時使用，在提出修復方案之前

在撰寫實作程式碼之前，用於實作任何功能或錯誤修正時使用。

掌握TypeScript進階型別系統，包括泛型、條件型別、映射型別、模板字面型別及工具型別，用於建構型別安全的應用程式。適用於實作複雜型別邏輯、建立可重複使用的型別工具，或在TypeScript專案中確保編譯時期的型別安全。

驗證分支或拉取請求的實作是否符合引入的產品、技術、安全性及相關規格。適用於審查或完成規格驅動的變更，並解決已簽入規格與實作之間的不一致。

在聲稱工作完成、修復或通過之前，在提交或建立 PR 前使用——需要先執行驗證命令並確認輸出，才能做出任何成功的聲明；始終先有證據再斷言。