finn-review

name	finn-review
description	Review open PRs against their linked Linear issues and required GitHub checks, then post a three-group verdict with Finn-loop labels. Use when asked to run Finn-loop's reviewer or review its PR queue. Designed for /loop; never merges or pushes code.

Finn-loop reviewer

One pass = one PR reviewed. Under /loop, each iteration runs this skill once.

1. Find a PR needing review

gh pr list --state open --json number,title,labels,isDraft,headRefOid,updatedAt,url

Skip drafts. For each PR, find the latest comment whose first line is Finn-loop review of COMMIT_SHA.

Skip a PR when that recorded SHA equals its current headRefOid and it already has loop-approved, loop-changes-requested, or needs-human-review. Review it again when new commits landed after the recorded SHA. If nothing needs review, say so and end the pass.

2. Read the contract and code

• Parse the linked issue identifier from Closes TEAM-NNN in the PR body and fetch the full Linear issue, including comments and relations. No linked issue is a must-fix finding.
• Read the full diff and every changed file in context.
• Review only against the linked issue: acceptance-criteria gaps, defects, broken data flow, unnecessary scope expansion, security problems, missing loading/error states, and code future agents will struggle to modify.
• Do not suggest unrelated improvements unless they are severe.

Every must-fix code finding starts with one of:

• [AC-N] — the PR does not satisfy that acceptance criterion
• [DEFECT] — the implementation is broken while staying inside scope
• [SECURITY] — a severe security issue blocks shipping
• [CI] — a required GitHub check failed

Non-goals are binding. If fixing a finding would require behavior excluded by an NG-N, do not prescribe code. Record [SCOPE-CONFLICT AC-N ↔ NG-N] with the exact contradiction and mark the PR for human escalation.

3. Check merge evidence

Inspect the current PR head, mergeability, and required checks:

gh pr view NUMBER --json headRefOid,mergeable,mergeStateStatus
gh pr checks NUMBER --required --json bucket,name,state,link

• If required checks are pending or mergeability is still unknown, report that the PR is waiting and end without posting a verdict or changing labels. A later loop pass will retry it.
• Failed required checks are [CI] must-fix findings.
• A merge conflict is a [DEFECT] must-fix finding.
• If the repository has no required checks, mark the PR for human escalation; do not apply loop-approved. Finn-loop does not treat missing CI as green.

Review the exact headRefOid used for this evidence. Re-fetch it immediately before posting. If it changed, discard the review and start again on a future pass.

4. Post one verdict

Post one comment in this structure:

Finn-loop review of COMMIT_SHA

CI: required checks passed | failed | not configured
Mergeability: clean | conflicting

## Review

Summary: one or two plain-language sentences on what this PR does.

## 1. Must fix before merge

None.

## 2. Should fix soon

None.

## 3. Safe to merge

Yes — automated review evidence is complete. A human still makes the merge decision.

Then set labels based on the verdict, checking existing labels before removing them so an absent label does not fail the command:

• No must-fix and no new escalation: add loop-approved; remove loop-changes-requested. Preserve a pre-existing needs-human-review label because it may represent a separate high-risk human gate.
• Must-fix present: add loop-changes-requested; remove loop-approved.
• Scope conflict or no required CI: add needs-human-review; remove both loop-approved and loop-changes-requested; set "Safe to merge" to No — human decision required.

The escalation path deliberately leaves the automated repair queue. A human must resolve the reason, change the issue or repository configuration as needed, and remove needs-human-review before Finn-loop reviews that unchanged commit again.

5. Hard limits

• Never merge or enable auto-merge.
• Never push commits to the PR branch.
• Never approve or request changes through a formal GitHub review. Use one comment plus labels because the loop may run on the PR author's token and GitHub rejects self-reviews.
• loop-approved is evidence for a human, not merge authorization.