[CI] Run Claude PR reviewer when a Contributor+ approves a PR

[mountiny]

Problem

Today, .github/workflows/claude-review.yml only runs when a PR is opened or marked ready_for_review. By the time a Contributor+ (C+) reviews the PR, additional commits may have landed since the initial Claude pass, so C+ reviewers miss out on a fresh Claude review of the latest code.

Solution

Extend the workflow to also re-run on pull_request_review (state: approved) when the approver is a member of the contributor-plus GitHub team. The existing opened / ready_for_review trigger is preserved.

Implementation outline

• Add pull_request_review: types: [submitted] to the workflow triggers.
• Gate the existing author-authorization validate job on github.event_name == 'pull_request_target'.
• Add a parallel checkCPlusApproval job that uses OS_BOTIFY_TOKEN to call gh api /orgs/Expensify/teams/contributor-plus/memberships/<reviewer> --silent (same pattern as validateActor/action.yml).
• Update the review job's needs and if so it runs when either gate passes.
• The existing concurrency group + cancel-in-progress: true already debounces rapid re-approvals.

Notes

• Re-runs on every C+ approval (intentional; concurrency group keeps cost bounded).
• No change to Claude prompts, allowed tools, or the docs review path.

Issue Owner

Current Issue Owner: @mountiny

[kacper-mikolajczak]

Hi @mountiny! Thanks for looking into that ❤️ Can we check whether it is indeed working as expected? My hypothesis:

C+ re-reviews silently skips on PRs from forks

On fork PRs, pull_request_review is treated like pull_request, not like pull_request_target:

• Secrets are not passed to the runner (docs).
• GITHUB_TOKEN is read-only and the top-level permissions: block cannot elevate it (community #26651).

Concrete impact on the new C+ approval path:

1. secrets.OS_BOTIFY_TOKEN is empty in isContributorPlus → the gh api team lookup fails → IS_CPLUS=false → review job is skipped. No error surfaced.
2. Even if that passed, secrets.ANTHROPIC_API_KEY would also be empty in the review job.
3. pull-requests: write is silently downgraded, so any inline-comment POST using github.token would 403.

[mountiny]

Thanks for raising, that is a good call out that we would probably notice soon haha. The forks make our lives much harder