Add Claude Code automatic PR reviews

[erikdarlingdata]

Summary

• Sets up automatic Claude code reviews on every pull request into dev, authenticating with the CLAUDE_CODE_OAUTH_TOKEN repo secret
• Adds the interactive workflow so Claude can be summoned with an @claude comment on issues and PRs; this is also the way to get reviews on fork PRs, since GitHub does not expose repo secrets to fork-triggered workflow runs
• The review prompt is tailored to this repo: T-SQL correctness, SQL Server version gating (2016 through 2025 plus Azure), CLAUDE.md style, self-containment, and blocking flags for hand-edits to the auto-generated Install-All/DarlingData.sql or version bumps outside maintainer release PRs

Closes #841

Changes

• .github/workflows/claude-code-review.yml: automatic review on pull_request into dev (opened, synchronize, ready_for_review, reopened); skips drafts and fork PRs; cancels superseded runs per PR
• .github/workflows/claude.yml: responds to @claude mentions in issue/PR comments and reviews; only users with write access to the repo can trigger it

Test Plan

• This PR triggers the new review workflow on itself (pull_request runs use the merge ref, which contains the new file), so a Claude review should appear on this PR
• The Claude Code Review run in the Actions tab completes green
• After merging to dev, the next PR into dev gets an automatic review

🤖 Generated with Claude Code

[claude]

Claude finished @erikdarlingdata's task in 1m 39s —— View job

---

Reviewing PR #842

• Gather context (PR diff, workflow YAML files, CLAUDE.md)
• Review .github/workflows/claude-code-review.yml
• Review .github/workflows/claude.yml
• Post final review

Summary

This PR only adds two GitHub Actions workflow files — no T-SQL is touched, so the repo's SQL-focused style/correctness rules (CLAUDE.md, version gating, self-containment, Install-All/DarlingData.sql, @version bumps) don't apply here.

The workflows themselves are well constructed:

• claude-code-review.yml correctly skips draft PRs and fork PRs (fork PRs can't access repo secrets, as noted in the comments), scopes permissions tightly (contents: read, pull-requests: write, id-token: write), and uses a per-PR concurrency group to cancel superseded runs.
• claude.yml correctly restricts triggering to the @claude mention pattern across issue_comment, pull_request_review_comment, issues, and pull_request_review events, and relies on the action's built-in write-access check for the commenting user rather than trying to reimplement that check in the workflow condition — this matches the recommended pattern.
• The review prompt in claude-code-review.yml is well tailored to this repo (correctness, version compatibility, self-containment, style, and the two repo-specific blocking rules).
• Confirmed this PR's own review run worked as intended — this comment is proof the workflow triggers and runs correctly on a PR into dev.

One minor, non-blocking suggestion posted as an inline comment:

• .github/workflows/claude.yml has no concurrency group (unlike the review workflow). Several rapid @claude comments on the same PR could trigger overlapping runs that push conflicting commits to the same branch. Worth adding a concurrency group keyed on issue/PR number, but not required for this PR to merge.

No blocking issues found.

Fix this →

[claude]

Minor/optional: unlike claude-code-review.yml, this workflow has no concurrency group. If a user posts several @claude comments in quick succession on the same PR/issue, multiple runs could execute concurrently and push conflicting commits to the same branch. Not a blocker, but worth considering something like:

concurrency:
  group: claude-${{ github.event.issue.number || github.event.pull_request.number }}
  cancel-in-progress: false

(cancel-in-progress: false since you likely don't want to cancel a change already in progress, just serialize new triggers.)