Pre-PR Review

Decide whether a finished implementation is ready for pull request review. Reuse valid evidence and do only the work that closes a gap. The acceptance contract is a scoped, verified local change with no confirmed P0, P1, or P2 finding open. A reviewer's approval alone does not meet it.

Running this skill authorizes local simplification, scoped fixes, and verification. Keep the result local: no commit, push, published comment, pull request, merge, or deploy. Preserve unrelated changes.

1. Check existing evidence

Confirm the intended base branch from the task or repository configuration, asking only if it stays ambiguous, and pass that same base and the requirements to every stage. Review committed and uncommitted changes against it. No changes means no-changes; an unreadable diff is a blocker.

Start from the work folder or reports the caller names (shared/references/work-state.md). A report path or completion label is not proof; captured evidence and a recorded review are:

• Feature run: the final full-review that accepted the feature must cover the current source. A passing final review already covers deferred tasks; their missing separate reviews are not gaps.
• Validation run: validate-e2e's captured evidence supplies facts, not reviewer judgment.
• Any run: the combined review must name the intended base and the revision it reviewed, and shared/scripts/capture_check.py stale must report the required checks current.

Reuse evidence only while the source (including post-review edits), base, contract, check definitions, dependencies, and environment still match; a commit ID change alone does not invalidate it. Never repair stale evidence by editing it or copying labels.

If the records show complete combined coverage, passing required checks and affected interface flows, no open or disputed finding, no deferred P0 to P2, and a reason for each deferred P3, return ready without further work. Otherwise name the specific gaps and continue.