feat: advisory auto-review for showcase contribution PRs

[celesteanglm]

Why

Showcase PRs wait for a maintainer before getting any feedback, and CI only covers the mechanical half (validate-showcase.mjs). This adds a first pass so contributors hear back immediately and reviewers start from a draft instead of a blank page.

It reuses the existing review-showcase-pr rubric, so the bot applies the same criteria a maintainer would — including the recent tone work, so the output reads like a teammate rather than a linter.

Advisory only

Posts a COMMENT. It cannot approve, request changes, or merge, and a human still reviews every PR. The comment says as much and invites pushback.

How it triggers

pull_request_target on opened / synchronize / reopened, filtered to showcase/**. No label or comment gate — every showcase PR gets a review. Two filters decide whether it actually speaks:

1. structural — the PR must touch showcase/;
2. the model's own is_showcase_contribution call, which skips e.g. a maintainer editing showcase tooling.

Pipeline

Deterministic work runs first, so the model reasons over real validator output and real HTTP statuses instead of guessing.

Stage	File	Does
Gather	gather.mjs	PR metadata, head-commit file contents, validator run, URL checks, secret scan
Judge	gemini.mjs	evidence + rubric → structured JSON (gemini-2.5-pro)
Post	post.mjs	upserts one comment; inline suggestion blocks on the first pass
Orchestrate	run.mjs	wiring, short-circuits when there's nothing to review

Security

pull_request_target is needed for fork PRs to get a review at all (a fork PR on plain pull_request gets a read-only token and no secrets). Because that trigger carries secrets and write access:

• checks out the base commit, never head.sha;
• no PR file is ever executed — fetched as text, read only;
• contributor content enters the prompt as explicitly-delimited untrusted data and the model gets no tools, so the worst case for an injection attempt is a badly worded comment;
• the validator runs in a temp copy, so local dry runs can't dirty a working tree.

Running from the base branch also means a PR can't change how its own review behaves.

Correctness fixes found testing against real PRs (#97, #96, #69)

• Refuse to run without a head sha, and fail when no text file is readable — both previously degraded to a confident "validator passed" having read nothing.
• Copy the repo-root skills/ tree that some manifests reference via skills[].sourcePath (acp-earner-loop does), which otherwise produced bogus must contain SKILL.md failures. Text files only: showcase/ costs ~340ms instead of 173MB.
• Resolve github.com blob/tree and raw.githubusercontent /main/ 404s against the PR branch, separating the documented until-merge convention from an actually stale href.

Verified on those three PRs: files read, validator green, 15/7/6 URLs classified with zero false "broken".

Before this can run

1. Add secrets:
   • GEMINI_API_KEY
   • DEVREL_SKILL_TOKEN — fine-grained read-only PAT, Contents: Read on game-by-virtuals/devrel (the rubric is private). Token expiry is the likeliest future breakage.
2. Merge — pull_request_target won't run for the PR that adds it.
3. Dry-run against a real PR first (command in scripts/showcase-review/README.md).

Not covered by local testing

The Gemini call and the comment post — no API key available locally. Everything up to and including the prompt payload is verified.

🤖 Generated with Claude Code