feat: add cross-PR conflict detection to github-code-review skill

[BingqingLyu]

Summary

• Add Section 6: Cross-PR Conflict Analysis to github-code-review skill — detects when the current PR modifies functions also changed by other open PRs
• Add Step 8b to the PR review workflow (Section 5) to integrate the conflict check into the existing review flow
• Uses codegraph (pip install codegraph-ai) for function-level conflict detection across open PRs

Motivation

Repos with many concurrent PRs often have multiple PRs modifying the same functions. Reviewing them independently wastes effort — merging one invalidates the diffs of the others. This extension gives the reviewer visibility into cross-PR dependencies so they can coordinate merge order.

Related issue: #38054

How it works

codegraph builds a code knowledge graph using tree-sitter to parse source code into function-level nodes and call edges, stored in a NeuG graph database.

For cross-PR conflict detection, the pipeline works in three steps:

1. Index: Parse each open PR's diff (gh pr diff) and resolve changed hunks to function-level granularity. For each PR, create a PR node and CHANGES edges to the Function nodes it modifies — verified against the existing code graph to distinguish modified functions from newly added ones.

2. Detect: Query the graph for functions with incoming CHANGES edges from multiple PRs:

   MATCH (pr1:PR)-[:CHANGES]->(f:Function)<-[:CHANGES]-(pr2:PR)
   WHERE pr1.id < pr2.id
   RETURN pr1.id, pr2.id, f.name, f.file_path

   Then compute connected components (union-find) to group all transitively conflicting PRs.

3. Report: For each PR in a conflict group, post a comment listing the shared functions and the other PRs that touch them.

This catches conflicts that git cannot — git only detects merge conflicts between two branches at merge time, and has no awareness of other open PRs. codegraph compares all open PRs simultaneously at the function level, surfacing semantic overlaps before any merge is attempted.

What changed

skills/github/github-code-review/SKILL.md:

• Step 8b (Section 5): cross-reference to Section 6
• Section 6: self-contained conflict detection workflow — auto-installs codegraph if not present, builds index on first run, then runs incremental update + conflict check for the current PR
• Troubleshooting table for common issues (database lock, gh auth, slow prepare)

Verification

Tested the full workflow (init → prepare → update → label --comment-only) against open PRs in this repo. Confirmed conflict detection, idempotent update, and comment posting all work correctly. Detailed analysis results will be posted as a follow-up comment.

[BingqingLyu]

Analysis results — tested on this repo (500 open PRs)

Ran codegraph pr-review prepare --limit 500 against this repo's open PRs. Results:

• 500 PRs indexed, 471 functions found to be modified by more than one PR
• 506 PRs (out of ~992 total in graph) involved in at least one function-level conflict
• 33 conflict groups detected (largest: 419 PRs — the core gateway/agent code)

Examples — functions modified by multiple PRs

Function	File	PRs	Examples
_handle_message_with_agent	gateway/run.py	15	#37275 ✅, #37291 ✅, #37406 ✅, #37440 ✅
delegate_task	tools/delegate_tool.py	12	#37398 ✅, #37442 ✅, #37443 ✅, #37445 ✅
run_doctor	hermes_cli/doctor.py	11	#37241 ✅, #37339 ✅, #37438 ✅, #37710 ✅
terminal_tool	tools/terminal_tool.py	10	#37475 ✅, #37497 ✅, #37498 ✅, #37500 ✅
generate_launchd_plist	hermes_cli/gateway.py	10	#37411 ✅, #37534 ✅, #37734 ✅, #37864 ✅

Interpretation

For example, delegate_task in tools/delegate_tool.py is modified by 12 open PRs simultaneously. If one of those PRs merges, the other 11 will likely need rebasing — and some may silently break if they depend on pre-merge assumptions about that function's behavior.

Cost efficiency

The entire pipeline (index → detect → report) is purely structural analysis — tree-sitter parsing + graph queries. No LLM calls are involved at any stage. This means cross-PR conflict detection runs at near-zero marginal cost regardless of the number of PRs analyzed, compared to LLM-based review approaches that scale linearly with token consumption.

[teknium1]

Thanks for the concrete cross-PR-review workflow and the repository-scale validation results.

Problems

• skills/github/github-code-review/SKILL.md:512 documents codegraph pr-review update --pr, but the linked upstream guide documents only prepare and label; its argument tables do not provide update, --pr, or --comment-only (upstream guide:134-152). The documented workflow cannot run as written.
• skills/github/github-code-review/SKILL.md:500-508 directly installs a package and modifies the checkout (.codegraph, .gitignore). The upstream guide instead specifies an isolated virtual environment and supports a separate --output path (upstream guide:17-23, 85-92).
• The section makes an external CLI the primary SKILL.md interaction, which conflicts with AGENTS.md:902-914.

Suggested changes

• Rework against the currently supported codegraph CLI/Python API, with a read-only analysis path and explicit approval before posting GitHub comments.
• Keep the venv, graph database, and reports outside the target checkout; do not edit .gitignore.
• Put external orchestration in a supporting script or make codegraph an explicit optional MCP prerequisite, then add the required skill test.

Automated hermes-sweeper review.

[teknium1]

Please do not install this package into the active environment. The linked codegraph guide requires an isolated virtual environment (pr-analysis.md:17-23); this skill should make that prerequisite explicit or delegate the external setup to a supporting script.

[teknium1]

This mutates the repository under review and leaves a tracked .gitignore diff. Keep graph and report state outside the checkout (the upstream guide supports --output) rather than editing project files during a review.

[teknium1]

The linked upstream guide currently documents only codegraph pr-review prepare and label; it has no update subcommand or --pr argument. Please replace this with a supported full-pipeline or Python-API flow.

[teknium1]

Upstream documents label flags only for --db, --repo, and --dry-run (pr-analysis.md:146-152); --pr and --comment-only are not documented. This command must be revised before the workflow can be used.