From code-review
當使用者想對 GitHub Pull Request 進行 code review 時使用。 提供行級 review comments，含嚴重度 badge 與 merge-result 分析。 觸發條件：任何提及審查、檢視、看 PR 的請求—— 中文（審查/看一下/幫我看/CR）或英文（review/check/code review）， 搭配 PR 識別（#123、PR 456、pr789、GitHub PR URL）， 或在 PR 語境下的泛用請求。 不確定是否該觸發時，傾向觸發。
npx claudepluginhub goodjack/claude-marketplace --plugin code-reviewThis skill is limited to using the following tools:
使用 gh CLI 和 Git 進行完整審查。Review 基於 merge result（目標 branch + PR 變更）。
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes competition with Porter's Five Forces, Blue Ocean Strategy, and positioning maps to identify differentiation opportunities and market positioning for startups and pitches.
使用 gh CLI 和 Git 進行完整審查。Review 基於 merge result（目標 branch + PR 變更）。
使用 TaskCreate 建立審查任務（每個階段一個）：
PR 編號： $ARGUMENTS
若未提供 PR 編號，執行 gh pr list 顯示開啟中的 PR 列表，讓使用者選擇。
git fetch
git status
git branch --show-current
若有未提交的變更，執行 git stash。
記錄當前分支名稱。
WHY merge result? 在 merge result 上 review 能揭示整合問題（衝突、不相容的變更），僅在 PR branch 上 review 會漏掉這些。
取得 PR 資訊：
gh pr view <number> --json baseRefName,baseRefOid,headRefName,headRefOid,mergeable
記錄以下欄位：
headRefOid（階段 4 作為 commit_id）baseRefNamemergeableWHY 記錄 headRefOid? GitHub API 需要 PR head 的 commit SHA 作為
commit_id來錨定 review comments。用baseRefOid會導致 HTTP 422。
若 mergeable 為 null：等待 5 秒後重新執行，仍為 null 則視為 false。
mergeable 為 true：
# 使用 Detached HEAD，避免建立本地分支導致污染與撞名
git fetch origin pull/<number>/merge
git checkout --detach FETCH_HEAD
mergeable 為 false：
gh pr checkout <number>
# 發佈警告
gh pr review <number> --comment -b "$(cat <<'EOF'
⚠️ 此 PR 有 merge conflict，review 基於 PR branch。
EOF
)"
查看變更差異：
git diff origin/<baseRefName>...HEAD
使用 Read 工具讀取所有修改檔案，並行調用一次讀取。
盡可能使用工具獲取型別資訊、引用關係和函數簽名。
若專案有 AGENTS.md 或 CLAUDE.md，先讀取並提取專案特有規範，作為審查依據。
重點關注：
準備具體的改進建議。分析完成後如有疑問，使用 AskUserQuestion 工具。
WHY 行號取自 PR head 而非 merge result? 雖然你在 merge result 分支上工作，但 GitHub 期望的行號來自 PR head（
origin/<headRefName>）。這個不匹配是發佈 line comment 時 422 錯誤的最主要原因。
使用 git grep 在 PR head 搜尋程式碼行以取得準確行號：
git grep -nF -C 3 "exact code line" origin/<headRefName> -- path/to/file
處理多處匹配時：增加上下文行數、使用更精確的搜尋字串、使用完整的函數簽名。
若 git grep 找不到，使用 GitHub API patch：
gh api repos/OWNER/REPO/pulls/NUMBER/files | jq -r '.[N].patch'
行號解析邏輯：
@@ 標頭格式：@@ -老檔案 +新檔案 @@+行號 是來源 branch 的實際行號+ 前綴的行：行號 +1- 前綴的行：不增加行號發佈批次 review：
gh api repos/OWNER/REPO/pulls/NUMBER/reviews --input - <<'EOF'
{
"event": "COMMENT",
"commit_id": "階段 2 記錄的 headRefOid",
"body": "共發現 N 個回饋：\n\n**嚴重問題** (X)\n- EMOJI 標題1\n\n**需要改進** (Y)\n- EMOJI 標題2",
"comments": [
{
"path": "file.py",
"line": 10,
"side": "RIGHT",
"body": "\nEMOJI **標題**\n\n說明\n\n建議"
}
]
}
EOF
Badge URL 依三種等級使用下面三個 URL
關鍵技術細節：
commit_id 使用階段 2 的 headRefOid（不是 baseRefOid）'EOF' 形式\" 或 \`），以使特殊字元在 GitHub 正確顯示僅在 line comment 無法表達時，用獨立的 gh pr review --comment 發佈，不要併入批次 review 的 body 欄位：
gh pr review <NUMBER> --comment -b "$(cat <<'EOF'
審查內容
EOF
)"
提供審查摘要：
git checkout <階段 1 記錄的原始分支>
若階段 1 有執行 stash：
git stash pop