From code-review
CI/CD 環境專用的 GitHub PR Code Review，對 PR 進行自動化審查並發佈行級 review comments。
npx claudepluginhub goodjack/claude-marketplace --plugin code-reviewThis skill is limited to using the following tools:
GitHub Actions 專用的非互動式 PR 審查。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.
GitHub Actions 專用的非互動式 PR 審查。Review 基於 merge result（目標 branch + PR 變更）。
PR 編號： $ARGUMENTS
WHY merge result? 在 merge result 上 review 能揭示整合問題（衝突、不相容的變更），僅在 PR branch 上 review 會漏掉這些。
取得 PR 資訊：
gh pr view <number> --json baseRefName,baseRefOid,headRefName,headRefOid,mergeable
記錄以下欄位：
headRefOid（階段 3 作為 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，先讀取並提取專案特有規範，作為審查依據。
重點關注：
準備具體的改進建議。
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": "階段 1 記錄的 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 使用階段 1 的 headRefOid（不是 baseRefOid）'EOF' 形式\" 或 \`），以使特殊字元在 GitHub 正確顯示僅在 line comment 無法表達時，用獨立的 gh pr review --comment 發佈，不要併入批次 review 的 body 欄位：
gh pr review <NUMBER> --comment -b "$(cat <<'EOF'
審查內容
EOF
)"
提供審查摘要：