pr-contribution-handler

PR Contribution Handler

Use this skill when the user provides a GitHub PR number, URL, branch, or list of PRs and asks to handle contributor work end-to-end.

The goal is not just "make CI green." The goal is to leave the PR in the most idiomatic, maintainable, rules-correct shape reasonable for its scope.

Maintainer Quality Bar — READ FIRST (non-negotiable, overrides "just merge it")

This skill lands contributor work, but only after it meets the maintainer's bar — and the bar is "is this PR the best it can be, behaviorally AND architecturally?" not "does CI pass?" The maintainer must be able to be confident in the review itself before anything merges. Apply every rule below to every PR.

1. You may — and should — improve the author's PR. "We can make changes to the author PR; we just need to ensure it's the best it can be." When a PR is correct but not idiomatic/clean/complete, fix it on the contributor's branch (push when maintainerCanModify=true; verify the fork remote points at the right contributor before pushing) rather than merging as-is or leaving a nit. Bring it to the shape a principal engineer would merge. If review finds only a couple small, local, low-risk changes between the PR and mergeability, do those fixups yourself instead of making the contributor chase another review round.

2. CI/Tilt green is necessary, NOT sufficient. Green CI proves it compiles and existing tests pass. It does not prove correctness, no-regression, or performance. Never present "CI green" as evidence a PR is ready. For every PR you must additionally:

   • Trace the changed logic by hand, end to end, for the target case AND 2–3 sibling cases in the class AND the obvious edge cases (multiplayer, zero/empty, interaction with existing effects). Confirm it actually produces the rules-correct result — not merely that it "conforms to CLAUDE.md."
   • Verify the tests DISCRIMINATE. For every assertion, ask: would this fail if the fix were reverted? An assertion that passes both before and after the fix is coverage theater. A bug-fix PR must have at least one runtime test that drives the engine through the real pipeline (apply() / scenario runner) and would fail without the change. Name any behavior with no discriminating test as a gap, and add the missing test before enqueue.
   • Read the parse-diff sticky comment (engine/parser-surface PRs). CI posts a sticky comment (marker <!-- coverage-parse-diff -->) with the card-level parse changes this PR introduces — it exists for the reviewing LLM and is required evidence, not optional context. Fetch its full body and confront the card diff against the PR's claimed scope: unexplained gained/lost/changed cards are findings (scope contamination or unintended parser blast radius). The pr_review.py packet's parse_diff field carries presence/state/updated_at; compare updated_at against the head's push time to confirm the diff reflects the current head. If the comment is absent but engine source changed, treat it as missing evidence and check whether CI ran for the current head before reviewing.