Orca Review Action

OrcaCode Review

OrcaCode Review reviews every pull request with an LLM, posts findings as inline comments, and fails a status check when serious issues are found. Model selection lives in OrcaRouter, not in the repo.

It runs as a GitHub Action: a workflow file in the repo plus one secret. Write access is all it takes, and an agent can complete the whole setup.

Severity contract: P0 critical / P1 high → ❌ block. P2 advisory → 💬 comment.

What you can do with this skill

You carry out all of these yourself — writing files, running gh, and asking the user only for the decisions that are genuinely theirs. Never tell the user to go run an installer; that is what this skill replaces.

Pick the route

Jump straight to the section the table above points at. Do not run the install flow on a repo that already has the workflow — go to Reconfigure instead.

Run this first in every route — it tells you which one applies:

git rev-parse --show-toplevel && \
  gh repo view --json nameWithOwner,visibility,defaultBranchRef 2>/dev/null; \
  ls .github/workflows/ 2>/dev/null | grep -i 'orca\|code-review'

If gh is missing or unauthenticated, everything still works — you just hand the user web URLs instead of running commands. Say so once and move on.

Install

1. Preflight

Confirm all three, and stop with a specific message if any fails:

• Inside a git work tree with a GitHub origin remote.
• No existing OrcaCode workflow (if there is one → Reconfigure).
• Record the repo's nameWithOwner, visibility, and default branch — later steps need them.

2. Ask for the key decisions

Ask these with one AskUserQuestion call. Include the fourth question only when visibility is PUBLIC — it is a spend-control decision that does not exist on a private repo, and asking it there is noise.

Q1 — "Where should review settings live?" (settings input)

• OrcaRouter dashboard (recommended) → settings: "true". Models, review mode, severity rules, and rubric change from the console with no workflow edit. Dashboard values win unless a with: input differs from its documented default.
• This workflow file → settings: "false". Skips the dashboard fetch entirely; the YAML is authoritative and nothing server-side can override it. Pick this for repos under change control.

Q2 — "Which findings should block the merge?" (block-on input)

• P0 and P1 (recommended) → "P0,P1". The default contract.
• P0 only → "P0". Blocks only critical issues; P1 still posts inline.
• Nothing — comment only → "". The check always passes. Good for a trial period.

Q3 — "What happens when a PR's diff is too large to review?" (on-oversized-diff)

• Fail the check (recommended) → "fail". A diff padded past max-diff-kb / max-diff-files cannot be used to slip past a required merge gate.
• Pass with a notice → "pass". The skip notice posts and the check stays green.

Q4 — public repos only — "Who gets an automatic review?" (auto-review-authors)

• Known contributors only (recommended) → "OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR".
• Everyone → "".

Say plainly why Q4 exists: the workflow runs on pull_request_target with your OrcaRouter secret, so on a public repo a stranger's PR can spend from your wallet. Also tell them to set a budget + alert on the key at https://www.orcarouter.ai/console/token.

Everything else keeps its default. Do not ask about judge-model, concurrency, engine-version, or precision-filter during install — see references/inputs.md if the user brings them up unprompted.

3. Write the workflow

Copy assets/workflow.yml to .github/workflows/orca-code-review.yml, then set the four values from step 2 under with:. Omit any input the user left at its default — a workflow that only lists what it overrides stays readable and lets the dashboard own the rest.

Keep the if: condition and the on: block exactly as shipped. They encode two things that are easy to break: pull_request_target is what lets a fork PR be reviewed at all, and the author-association check on issue_comment is what stops any drive-by commenter from spending your quota with /orcacode-review.

Show the user the final file before committing.

4. Have the user add the API key — with gh, themselves

The secret must be named exactly ORCAROUTER_API_KEY.

This is the one step you do not perform. Stop, hand the user this command, and wait for them to confirm they have run it:

! gh secret set ORCAROUTER_API_KEY --repo <owner/name>

gh prompts for the value on their terminal, so the key goes from their keyboard straight to GitHub. It never passes through you.

Never ask them to paste the key into the chat, read it out of a file or an env var, or pass it on a command line. A pasted key is in the transcript forever; a key in argv is visible to every process on the machine via ps. There is no version of this you can do "carefully" — the only safe handling is not handling it.

They can create or copy a key at https://www.orcarouter.ai/console/token.

Without gh, send them to https://github.com/<owner>/<name>/settings/secrets/actions/new and have them add it in the browser.

Then confirm it exists without ever seeing its value:

gh secret list --repo <owner/name> | grep ORCAROUTER_API_KEY

If it is not there yet, do not continue to the test PR — the run will fail on auth and the failure will look like a configuration bug rather than a missing key. Wait, or skip to step 8 and list it as outstanding.

5. Switch it on in the OrcaRouter console

Point the user at OrcaRouter → Apps → OrcaCode Review (https://www.orcarouter.ai/) to turn it on and choose review models. Reviews will not run until it is enabled.

There is no API for this step today, so it is the user's to do.