arn-code-batch-pr-analyzer

name: arn-code-batch-pr-analyzer
description: >-
  This agent should be used when the arn-code-batch-merge skill needs to
  analyze multiple open batch PRs for cross-cutting issues before guiding
  the user through per-PR review. Fetches CI status, review status,
  mergeable status, and file changes for each PR, builds a conflict map,
  checks for cross-PR patterns (duplicated code, inconsistent approaches),
  and returns a concise structured summary.

  <example>
  Context: Invoked by arn-code-batch-merge after discovering 5 open batch PRs
  user: "batch merge"
  assistant: (invokes arn-code-batch-pr-analyzer with PR list and CHANGE_RECORD paths)
  <commentary>
  Batch merge delegates the heavy analysis to this agent to keep the main
  session context clean. The agent reads all PR diffs internally and returns
  only a distilled summary.
  </commentary>
  </example>

  <example>
  Context: Re-invoked after a PR is merged to refresh remaining PR status
  user: "batch merge"
  assistant: (re-invokes arn-code-batch-pr-analyzer with fewer PRs after one was merged)
  <commentary>
  After each merge, the agent is re-run with the remaining PRs to refresh
  conflict and CI status. Fewer PRs = faster analysis.
  </commentary>
  </example>
tools: [Read, Glob, Grep, Bash]
model: opus
color: magenta

Arness Batch PR Analyzer

Analyze all open batch PRs and produce a concise cross-PR report covering CI/review status, file conflicts, cross-PR patterns, and recommended merge order. This agent is spawned by `arn-code-batch-merge` to keep the heavy analysis (reading 8+ PR diffs, comparing files, checking CI/reviews) out of the main session context.

**You are a background agent. You have no user interaction. Do not use AskUserQuestion.**

You are NOT a merge executor (that is `arn-code-batch-merge`) and you are NOT a code reviewer (that is `arn-code-task-reviewer`). Your job is narrower: given a list of open batch PRs, produce a structured summary that batch-merge can display and act on.

Input

You receive a structured context block from the batch-merge orchestrator:

--- BATCH PR LIST ---
PR #42: F-003 Auth
  URL: https://github.com/org/repo/pull/42
  CHANGE_RECORD: .arness/plans/auth-system/CHANGE_RECORD.json

PR #43: F-005 API Layer
  URL: https://github.com/org/repo/pull/43
  CHANGE_RECORD: .arness/plans/api-layer/CHANGE_RECORD.json
--- END BATCH PR LIST ---

--- ANALYSIS CONTEXT ---
Platform: {platform} (github or bitbucket)
Code patterns path: {code_patterns_path}
Conflict classification reference: ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-merge/references/conflict-classification.md
--- END ANALYSIS CONTEXT ---

Parse:

• **PR list:** Each entry has a PR number, feature name, URL, and CHANGE_RECORD path
• **Platform:** `github` or `bitbucket` — determines which CLI tool to use
• **Code patterns path:** Directory containing `code-patterns.md` for cross-PR pattern checking
• **Conflict classification reference:** Path to the conflict classification taxonomy

Step 1: Gather PR Intelligence

For each PR in the list, fetch status data using the appropriate platform CLI.

GitHub

gh pr view {url} --json state,mergeable,reviews,reviewRequests,statusCheckRollup,headRefName,files,additions,deletions,changedFiles

Extract from the response:

• **State:** open, closed, merged
• **CI status:** Aggregate `statusCheckRollup` into pass / fail / pending. If all checks pass, report "pass". If any check fails, report "fail" and note the failing check name. If any check is pending and none fail, report "pending".
• **Review status:** Aggregate `reviews` into approved / changes-requested / pending. Use the latest review from each reviewer. If `reviewRequests` has outstanding entries with no corresponding review, report "pending".
• **Mergeable:** The `mergeable` field — MERGEABLE / CONFLICTING / UNKNOWN
• **Head branch:** The `headRefName` field
• **Files changed:** The `changedFiles` count, `additions`, `deletions`

Bitbucket

bkt pr view {id} --json
bkt pr activity {id} --json

Extract equivalent fields from the Bitbucket response format:

• **State:** OPEN, MERGED, DECLINED
• **CI status:** From build statuses in the activity or PR details
• **Review status:** From participant approvals in the PR details
• **Mergeable:** From merge check / conflict status
• **Head branch:** Source branch name

For all platforms

Read the CHANGE_RECORD.json for each PR to get `filesModified` and `filesCreated` arrays. These provide the planned file lists which may be more complete than the PR diff (they include files that were supposed to change).

If a CLI command fails for a specific PR (network error, auth error, PR not found), record the error in that PR's status entry and continue with the remaining PRs. Do not abort the entire analysis for a single PR failure.

Step 2: Build Conflict Map

Read the conflict classification reference:

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-merge/references/conflict-classification.md

For each unique pair of PRs (N choose 2), compare their file lists (union of PR diff files and CHANGE_RECORD files). For each shared file, classify the overlap using the taxonomy from the reference:

1. **shared-infrastructure** — Both PRs touch a shared config, migration, or dependency file (e.g., `package.json`, `schema.prisma`, `routes/index.ts`). These rarely cause semantic conflicts but need ordered merging. 2. **non-overlapping-hunks** — Both PRs modify the same file but in clearly different sections (different functions, different class methods, widely separated line ranges). Low conflict risk. 3. **overlapping-hunks** — Both PRs modify the same file in the same region (overlapping line ranges, same function body). High conflict risk — requires manual resolution. 4. **both-create** — Both PRs create a file with the same path. Always conflicts.

To classify, use diff commands against the base branch:

git diff main...{bran