Added claude auto reviewer

[mattezra]

No description provided.

[github-actions]

Claude Auto Review — review of the reviewer 🙂

Nice, small, self-contained workflow. The security hygiene is good — pinned action SHAs with version comments, minimal permissions (contents: read, pull-requests: write), concurrency cancellation, a 15-minute timeout, a draft-PR skip, and an explicit --allowedTools allowlist that keeps Claude on a short leash. Using the pull_request event (not pull_request_target) is also the right call: fork PRs won't get ANTHROPIC_API_KEY, which is the safer trade-off even though it means external-contributor PRs go un-reviewed.

A few suggestions, left inline:

1. fetch-depth: 1 — fine if Claude sticks to gh pr diff, but any git-based fallback (git log, git diff master..HEAD) will fail. Worth either accepting that constraint explicitly or bumping to fetch-depth: 0.
2. No bot/doc filter — every Dependabot bump and README typo will trigger a paid Claude review. Adding paths-ignore and user.type != 'Bot' would cut noise and cost.
3. Bash(gh pr comment:*) / gh pr view:* allowlist breadth — these globs let Claude operate on any PR in the repo, not just the current one. Combined with untrusted diff content in the prompt context, that's a (small) prompt-injection surface. Either drop the bash entries in favor of the MCP inline-comment tool, or scope them more tightly.

No blocking issues. The workflow as-written will work; the suggestions are about cost control and tightening the trust boundary.

[github-actions]

Claude Auto-Reviewer workflow — review

Nice, focused change. The workflow follows current best practices for this kind of action and the security posture is reasonable. Detailed notes left inline; summary here:

What's good

• SHA-pinned actions (actions/checkout and claude-code-action) — protects against tag-retargeting supply-chain attacks.
• pull_request event (not pull_request_target) — correct choice; secrets aren't exposed to untrusted fork code.
• Least-privilege permissions (contents: read, pull-requests: write) — no broader scope than needed.
• Concurrency group with cancel-in-progress — avoids redundant reviews when a PR is force-pushed mid-review.
• timeout-minutes: 15 — bounded blast radius if the action hangs.
• draft == false and bot filter — skips work that isn't ready for review.

Things to consider (see inline comments)

1. Fork PRs will silently no-op — secrets aren't available on pull_request from forks. Acceptable, but worth documenting.
2. Bash(gh pr comment:*) is broader than the intent — combined with prompt-injection from PR contents, a crafted diff could try to redirect comments to a different PR/repo within the token's scope. Tightening the pattern to embed the current PR number, plus a one-line prompt instruction pinning the target PR, is cheap defense in depth.
3. Add workflow_dispatch: so reviews can be retriggered manually after errors or cancellations.

Minor / optional

• fetch-depth: 1 is fine here since git isn't in --allowedTools — the reviewer relies on gh pr diff (API-based) for diff context. Leave as-is.
• paths-ignore currently skips **/*.md and docs/**. Mixed PRs (code + markdown) will still trigger and the model will see everything, which is probably what you want.
• Consider adding WebFetch to --allowedTools if you'd like the reviewer to be able to look up linked docs/issues mentioned in PR descriptions; skip if you'd rather keep the egress surface small.

No blocking issues from me.

[shrunyan]

I do not want documentation ignored. We want to maintain a high caliber of quality and that means ensuring spelling and grammatical errors are corrected.