Pull-request review
Run a bounded, evidence-based code review that separates blocking findings from optional cleanup.
Use a manual automation when each code change should receive the same review contract and retain an independent record. Keep a person responsible for deciding whether findings block the change.
Prepare the review project
Activate a source-control connector with the narrowest repository access available. Add the repository's engineering instructions and review rubric to the project. If the run needs a sandbox checkout, state the authoritative base and head refs instead of relying on an old local branch.
Define the review contract
Ask the automation to inspect the complete change and relevant surrounding code, then report:
- correctness and user-visible regressions;
- authorization, secret, and injection risks;
- data-loss and concurrency hazards;
- missing tests needed to cover changed behavior; and
- optional reuse or simplification notes separately.
Require every finding to cite a concrete file and behavior, explain impact, and avoid treating style preference as a blocker. When no main issue is found, say so directly and state any untested risk.
Keep publishing under human control
Start with Run now and paste or select the target change as run input. Review false positives and adjust the rubric. Where operation controls are available, keep comment, approval, merge, and branch-write operations ask-gated; otherwise connect a read-only account. Reading code does not authorize publishing a review or changing the repository.
Use separate runs for separate changes so evidence and outcomes stay attributable. Re-run after substantial fixes rather than assuming the previous result still applies.