風險驅動程式碼審查 Skill(Codex)

唯讀審查 PR、提交、分支或工作區差異,追蹤調用方、核對需求並給出有證據的發現。預設採用深入的 Solo 審查。

Tink1.1.02026年11月9日MIT
取得 Skill

使用需求

面向具備倉庫及檔案存取能力的 Codex 類智能體。說明文件不提供瀏覽器、測試工具、憑證、專案數據或修改外部系統的權限;其他宿主可能需要適配。

  • 明確的基準線、目標及當前差異
  • 倉庫規則、可用需求、測試及相關失敗證據
  • 僅選擇獨立多智能體覆蓋時,才需要宿主支援子智能體

快速開始

  1. 下載後先檢查包內說明,再將 ZIP 解壓至暫存目錄。
  2. 安裝合集時,將六個 Skill 資料夾及同級 shared 資料夾複製到專案的 .agents/skills/ 或個人的 ~/.agents/skills/。保持相對目錄結構,不要把合集外層目錄當成一個 Skill 安裝。
  3. 安裝單獨 ZIP 時,將其中的同名資料夾放入所選 Skills 目錄,並保留其內部 shared 資源。覆蓋前備份同名 Skill,避免重複安裝。
  4. 在 Codex 中使用準確的 $code-review-multiagent 呼叫;未被發現時可重啟宿主。任務需要流程交接時,另行安裝相應配套 Skill。

適用場景

  • 對照需求及直接調用方審查待合入改動
  • 涉及安全、數據、介面契約或測試等可獨立調查面的複雜改動

使用步驟

  1. 呼叫 $code-review-multiagent,明確基準線、目標及需求來源。
  2. 追蹤被修改公共符號的直接調用方,檢查適用風險,也檢查需求要求但差異中完全缺失的行為。
  3. 預設 Solo;僅在複雜度確有需要且宿主支援時,分配 2–4 個獨立審查面。
  4. 驗證並合併同根因發現,報告等級、觸發條件、位置、影響、證據和最小修復方向。

交付內容

  • 按優先級排列的 P0–P3 發現,或限定範圍的「未發現可證明的缺陷」結論
  • 分別給出規範、需求和執行時驗收狀態及驗證缺口

局限

  • 不自動修復,也不把純風格偏好列為缺陷。
  • 沒有差異時不能聲稱審查了候選實現。
  • 靜態審查和測試通過不能證明瀏覽器可用性或已部署;執行時證據缺失需明確保留。

示例提示詞,非實際執行案例

使用 $code-review-multiagent,對照 main 分支和已批准的存取控制需求,審查當前工作區差異。保持唯讀,追蹤直接調用方及被拒請求的副作用;區分已證實問題和缺失的執行時證據。

本指南說明包內工作流程,不代表已驗證跨模型可靠性,也不是實際驗收執行報告。

工程規範與需求符合性

沿實際呼叫端和使用者路徑審查最新差異,分別回報工程規範與需求符合性的發現和證據缺口。ZIP 內新增 Fowler 程式碼異味參考,用於判斷具體的維護成本和正確性問題。

Skill 內部
SKILL.md
---
name: code-review-multiagent
license: MIT
description: >-
  Review a PR, commit, branch, or working-tree diff read-only. Trace callers, check engineering standards and requirements separately, and report evidence-based severity. Use one reviewer by default and split independent complex surfaces when needed.
---

# Code Review Against Standards and Requirements

Trace requirements, actual callers, and concrete failure conditions. Keep review read-only. Authorized reads and checks without side effects are allowed. External cost, sending, or other writes require applicable authorization.

## Set the scope

- Use the specified baseline and paths first. Use the task starting point for “this change” when established. Ask only for missing scope when unrelated changes cannot be separated.
- Confirm the reference resolves and the diff is nonempty. For commits use git diff base...tip and record the commit list. For the working tree use git diff base with path limits. Use git diff --cached for staged changes. Read in-scope untracked files separately.
- Use the user's explicit requirements and specified spec, then associated issues or existing specs. A chat requirement is valid. If there is no spec, mark that gap and finish the standards review. An agent's own plan is not user approval.
包含檔案 · 10
code-review-multiagent/LICENSE
code-review-multiagent/MANIFEST.json
code-review-multiagent/README.md
code-review-multiagent/SKILL.md
code-review-multiagent/agents/face-reviewer.md
code-review-multiagent/agents/finding-challenger.md
code-review-multiagent/agents/openai.yaml
code-review-multiagent/references/code-smells.md
…