Automate PR reviews with Grok 4.5

[bholmesdev]

Description

Adds Grok 4.5 High reviews for opened, reopened, ready-for-review, and manually requested same-repository pull requests. The Oz agent runs read-only, emits structured feedback, and a separate publication job validates diff locations and the PR head before posting a non-blocking review.

No related issue.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Documentation update

Testing

• Existing tests pass
• Added new tests for changes
• Tested manually (describe below)

Manual Testing Details:

• Parsed workflow as YAML.
• Verified GitHub Actions structure and whitespace.
• Confirmed grok-4-5-high is available through Oz.
• Ran iterative reviews through the local Grok CLI using the common review-pr skill.

Checklist

• I discussed this change in a GitHub issue before submitting this PR
• I have run the relevant formatter and validation checks

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hubble-md-web	Ready	Preview, Comment	Jul 12, 2026 1:23am

[github-actions]

Overview

Adds a two-job GitHub Actions workflow that runs a read-only Oz/Grok review agent on same-repository PRs, packages a structured review.json, then validates comment locations and the PR head SHA in a separate trusted job before publishing via the Reviews API.

The split between untrusted agent work and trusted publication is sound: restricted permissions, persist-credentials: false, same-repo/draft/dependabot filters, concurrency cancellation, artifact handoff, and publish-time schema/diff validation are all in good shape for a V0.

Concerns

• Publish payload omits commit_id, so there is a small TOCTOU window between the head-SHA check and POST .../reviews where a new push could make GitHub attach the review to a different commit than the one whose diff was validated.
• Each synchronize posts a new review without dismissing prior bot reviews, so REQUEST_CHANGES/APPROVE history can accumulate noise.
• Only dependabot[bot] is excluded; other automation actors may still trigger paid review runs.

None of these block correctness of the core happy path for V0.

Verdict

Found: 0 critical, 1 important, 2 suggestions

Approve with nits