ci: add claude PR review workflow using differential-review skill

[ziggie1984]

Summary

• Adds claude-review.yml workflow triggered by @claude review comments on PRs
• Uses the differential-review skill from lightninglabs/agent-skills, cloned at runtime
• Pins to anthropics/claude-code-action#963 fix commit to correctly handle fork PRs (the current @v1 fails with fatal: couldn't find remote ref on fork branches)
• Excludes @claude review from claude.yml to prevent both workflows firing on the same comment
• Includes workflow_dispatch for testing the workflow on this branch before merging

Test plan

• Manually trigger via Actions → Claude PR Review → Run workflow on this branch with a PR number
• Verify agent-skills clones correctly and differential-review skill is loaded
• Comment @claude review on a fork PR and confirm it doesn't hit the branch fetch error
• Remove workflow_dispatch block before final merge

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[saubyk]

Just one clarification

[saubyk]

Clarification: Does Claude need 'write' permission to post review comments on the issue or pr?

[ellemouton]

yes it is needed

[ziggie1984]

yes because we want to post comments on the PR

[lightninglabs-deploy]

@ziggie1984, remember to re-request review from reviewers when ready

[ziggie1984]

New CI: Claude PR Review Workflow

This PR adds a new claude-review.yml workflow that is separate and independent from the existing claude.yml action already in the repo — it does not interfere with it in any way.

Why a separate workflow?

The existing claude-code-action has a known limitation: it does not support PRs whose head branch lives in a fork. Since most contributor PRs come from forks, the action simply cannot check out and review them.

This new workflow works around that by using gh pr checkout (fork-safe) to explicitly check out the PR branch before invoking Claude, making it work for both fork and non-fork PRs.

How it is triggered

The workflow activates on any of the following:

• A comment containing @claude review is posted on a PR (issue comment or review comment)
• Manually via workflow_dispatch by providing a PR number

It then runs our own /code-review slash command via claude -p and posts the findings back as a PR comment.

[erickcestari]

@claude are you being able to fetch the fork branch? Also review this change to check.

[claude]

Claude Code is working…

I'll analyze this and get back to you.

View job run

[ziggie1984]

After looking into the security implications of running the Claude workflow in CI, we've identified a few concerns worth noting:

The current setup checks out untrusted fork code in the same job that holds the CLAUDE_CODE_OAUTH_TOKEN. This creates a potential attack vector where a malicious PR could include
tampered .claude/settings.json or CLAUDE.md files with hooks that exfiltrate the secret before Claude even processes the comment. Additionally, prompt injection via code comments is a
residual risk that is difficult to fully eliminate in a workflow-based approach.

Possible mitigations include adding an author_association guard, a precheck on modified Claude config files, or a full split-job architecture — but each comes with its own tradeoffs.

For now we have decided to run Claude reviews locally rather than through CI. This avoids the problem entirely — no secrets are exposed, no untrusted code runs in a shared environment,
and a human remains in the loop before anything gets posted. We can revisit automated CI integration once a more secure architecture is in place.