Review an incoming issue

This skill ends in a recommendation for the maintainer:

• Assign: the issue is valid, an external PR suits it, and a sound PR exists. Assign the author, which clears the gate, then review the code.
• Decline: close the open contribution, or leave a closed one closed, and explain why on the issue once authorized.
• Maintainer decision needed: only when investigation leaves a concrete choice that materially changes supported behavior or ongoing support scope. State the affected scenario, competing outcomes, why protocol/docs/history/prior decisions do not settle it, and a recommendation. Ordinary reviewer uncertainty or implementation preferences do not qualify. The unresolved choice alone is not a reason to decline or formally request changes.

Assignment commits us to reviewing the PR, not to merging it. A gate closure is administrative, so a closed PR gets the same bar as an open one.

How the gate works

require-issue-link.yml checks every external PR:

• It needs Fixes/Closes/Resolves #N. PRs without a valid link are closed.
• A linked PR stays open with a failing check until its author is assigned to that issue. Issues labeled prs welcome waive assignment but still need the link.
• Assigning the author (gh issue edit N --add-assignee <login>) re-runs the check and reopens a gate-closed PR. If that run fails, the gate misbehaved: investigate the run rather than re-assigning.
• Maintainer PRs are exempt, and so are authors with the trusted-contributor label. Reopening a PR by hand or removing missing-issue-link applies a sticky bypass-issue-check, so prefer assignment.
• marvin-triage-issue, marvin-dedupe-issues, auto-close-duplicates, and auto-close-needs-mre have usually commented already. Read them as leads.