[MegaRedHand]

🗒️ Description / Motivation

lambdaclass/actions v1 has moved on since our pin (2127455, Sep 1). It now ships three more reviewers (DeepSeek, Gemini, Grok), a /review command that triggers every reviewer a repo calls, and a Claude reviewer that is a single Messages API call instead of a Claude Code agent run. This PR brings us up to date and adds the new reviewers.

What Changed

.github/workflows/ai-review.yml only:

Change	Detail
Pin bump	Kimi, Codex, Claude: 2127455 → ad22254 (what v1 points at today), still SHA-pinned as in #713
New reviewers	ai-review-deepseek.yml, ai-review-gemini.yml, ai-review-grok.yml
Comment gate	Each job starts on a comment only when it begins with its own command (/kimi, /codex, /claude, /deepseek, /gemini, /grok) or /review. Before, every PR comment spawned one run per reviewer that then skipped inside the called workflow
permissions:	contents: read + pull-requests: write, which is all the called workflows declare; the repo default grants write to everything

Correctness / Behavior Guarantees

How a review triggers:

pull_request: opened / ready_for_review
  └─ not a draft                      (this workflow)
       └─ head repo == this repo      (called workflow)
            └─ all 6 reviewers run

issue_comment: created
  └─ starts with /review or /<name>   (this workflow)
       └─ on a PR, author is OWNER / MEMBER / COLLABORATOR   (called workflow)
            └─ /review → all 6, /<name> → that one

Behavior changes reviewers should know about:

• Missing secrets. DeepSeek, Gemini and Grok need DEEPSEEK_API_KEY, GEMINI_API_KEY and XAI_API_KEY, which this repo does not have yet. Until they are added, each of those reviewers posts a "secret is not set" comment and fails its check on every PR.
• A review that does not happen now fails its check (upstream change): an empty response or provider outage is red rather than green with a comment.
• Claude reviewer is now one API call over the diff (no checkout, no tools), defaulting to claude-opus-5-5 at effort: high. We passed none of the removed inputs (max_turns, allowed_tools), so no with: changes are needed.
• Default models moved upstream: Kimi kimi-k3.1-pro, Codex gpt-6.1-sol.

Tests Added / Run

• actionlint -ignore SC2086 -ignore 'specifying action "\$/' .github/workflows/ai-review.yml (same flags as pr_lint_gha.yaml): clean
• gh actions-lock --verify (same as verify-lockfile.yml): all 13 workflows valid; reusable workflows are not tracked in actions.lock, so it needs no update

Related Issues / PRs

• Related to ci: pin GitHub action versions #713 (action pinning), ci: skip AI review on draft PRs #305 (skip drafts), ci: use lambdaclass/actions reusable workflows for AI review #69 (adopt lambdaclass/actions)

✅ Verification Checklist

• Ran make fmt: n/a, no Rust changes
• Ran make lint: n/a, no Rust changes
• Ran make test: n/a, no Rust changes

[github-actions]

🤖 Gemini Code Review

⚠️ Review failed: GEMINI_API_KEY secret is not set

---

Automated review by Gemini

[github-actions]

🤖 Grok Code Review

⚠️ Review failed: XAI_API_KEY secret is not set

---

Automated review by Grok (xAI)

[github-actions]

🤖 DeepSeek Code Review

⚠️ Review failed: DEEPSEEK_API_KEY secret is not set

---

Automated review by DeepSeek

[github-actions]

🤖 Claude Code Review

Review: PR 763 — Add DeepSeek, Gemini, and Grok AI reviewers

This PR only changes CI. No Rust or consensus code is touched, so the consensus-specific checklist doesn't apply. The changes are an improvement overall: comment-based triggers are now filtered at the caller level instead of running every job on every comment. A few things to tighten:

Security / correctness

1. No PR guard on issue_comment (all six if: blocks). issue_comment also fires for plain issues. A /review on a regular issue would launch six jobs that run with secrets. The old code had the same gap, but /review makes it easier to hit. Add this to each comment branch:

   (github.event_name == 'issue_comment' && github.event.issue.pull_request &&
    (startsWith(...) || startsWith(...)))

2. The write-access requirement is not enforced in this file. The header says "requires write access." issue_comment runs in the base repo context with access to secrets. If the reusable workflows at ad22254 don't check the commenter's permission, any GitHub user could burn six API budgets by commenting /review. Please confirm the reusable workflows check this. For defense in depth, you could also gate here:

   contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)

   Note that COLLABORATOR doesn't strictly imply write access. A proper permission check via the API (in the reusable workflow) is the stronger guard.

3. Top-level permissions cap the called workflows. contents: read and pull-requests: write now act as a ceiling. If any reusable workflow at ad22254 declares a broader permission, that job fails at startup. Examples would be issues: write (e.g., for reactions on the triggering comment), checks: write, or id-token: write. Please verify against the pinned SHA.

Behavior / noise

4. Prefix matching is loose. startsWith(body, '/review') also matches /reviewed, /reviewers, and similar. The same applies to /claude…, /gemini…, etc. This is minor, but consider matching '/review ' plus an exact body == '/review' check, or accept the looseness knowingly.

5. Fork PRs will produce six failing checks. On a pull_request event from a fork, secrets are empty. Per the header, a missing secret means the reviewer "comments and fails its check." Every external contribution would therefore get six red checks. Consider adding this to the pull_request branch:

   github.event.pull_request.head.repo.full_name == github.repository

6. No concurrency group. Repeated /review comments or rapid re-opens will stack duplicate runs and comments. Something like this would dedupe them, either at workflow level or per job:

   concurrency:
     group: ai-review-${{ github.event.pull_request.number || github.event.issue.number }}-${{ github.event.comment.body }}
     cancel-in-progress: true

7. Cost. Six LLM reviews now run on every non-draft PR open or ready event. Consider running only a subset automatically and leaving the rest on-demand.

Nits

• Pinning to a full SHA with a # v1 comment is good practice. Please confirm ad22254d… actually corresponds to the v1 tag so the comment doesn't drift.
• The six near-identical if: blocks are unavoidable, since uses: can't take expressions, so a matrix won't work here. The duplication is acceptable.
• Reading the prompt from the base branch is the right call, because it prevents prompt injection via the PR itself.

---

Automated review by Claude · claude-opus-5-5 · custom prompt

[github-actions]

🤖 Codex Code Review

No actionable findings in the provided diff. This PR only changes the AI review workflow; it does not touch Rust or consensus logic.

The reusable workflows are pinned to a commit, but network restrictions prevented inspecting that commit. Their authorization checks, secret handling, and execution behavior remain unverified.

---

Automated review by OpenAI Codex · gpt-6.1-sol · custom prompt

[github-actions]

🤖 Kimi Code Review

• .github/workflows/ai-review.yml:32-80 — fork PRs will predictably fail these checks. Every non-draft pull_request triggers all six reviewers, but GitHub does not provide repository secrets to workflows triggered by fork PRs. Since the header states that a missing secret makes the reviewer comment and fail, external contributions can receive up to six failing checks. Prefer skipping unavailable reviewers with a successful/neutral result, or restrict automatic reviews to same-repository PRs and retain an authorized manual trigger. Also ensure all three new secrets are configured before rollout.

• .github/workflows/ai-review.yml:34-80 — the issue_comment conditions do not verify that the comment belongs to a PR. A /review comment on an ordinary issue will start all six jobs. Add github.event.issue.pull_request to the issue_comment branch so jobs only run for PR comments.

• Same conditions — write-access enforcement is only implicit. Any user can create an issue_comment event; the caller workflow itself does not enforce the documented “requires write access” rule. If every pinned reusable workflow performs that check before consuming secrets, this is fine, but it should be verified for the three new reviewers as well. Otherwise, untrusted commenters could repeatedly trigger paid API requests.

The full-commit SHA pinning and narrowly scoped token permissions are good security practices.

---

Automated review by Kimi (Moonshot AI) · kimi-k3.1-pro · custom prompt