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)
  </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)
  </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...{branch_a} -- {file}
git diff main...{branch_b} -- {file}

Compare the hunk headers (`@@` lines) to determine overlap. If a file appears in CHANGE_RECORD but not in the actual PR diff, note it as "planned but not changed" and skip conflict classification for that file.

Only report file pairs with actual overlap. Omit pairs where the file lists are completely disjoint.