| name | swift-pr-review |
| description | Use for an adversarial review of a Swift diff or pull request. Review only the supplied change and its necessary context; do not modify code or turn style preferences into blockers. |
Swift pull-request review
Review from a fresh context and try to falsify the change. Findings must be actionable and evidenced.
Workflow
- Establish the exact base/head, diff, repository instructions, changed targets, and claimed behavior. Inspect relevant callers, tests, and boundary definitions.
- Route only relevant domain skills. Check behavior first, then ownership/lifetime, isolation/Sendable, protocol/security boundaries, API resilience, performance evidence, and maintainability.
- Look for concrete failures: wrong state transitions, races, use-after-close, leaks, malformed-input acceptance, cancellation holes, compatibility breaks, test gaps, or claims unsupported by measurements.
- Run the strongest practical focused checks and distinguish code defects from environment or unavailable-platform failures.
- Report findings ordered by severity with file/line, failure scenario, why the current code fails, and a minimal fix direction. Do not report hypothetical concerns without a credible path.
Read references/review-rubric.md for severity and evidence rules.
Guardrails
- Never approve because tests are green if the tests do not exercise the claimed invariant.
- Never request broad rewrites for a local issue.
- Do not edit the branch during review unless the user explicitly changes the task to review-and-fix.
Completion contract
State verdict, validated blockers, checks and scope, residual risks, and explicitly say when no blocker was found.
