| name | swe:pr-risk-review |
| description | Reviews open or draft pull requests for engineering risk before merge, focusing on missing validation, hidden coupling, rollout and rollback gaps, migrations, feature flags, and other agent-safe next actions. Use when a user says `review this PR for risk`, `pre-merge review`, `is this PR safe to merge`, or asks for a risk-focused PR review. Do NOT use for post-merge production monitoring, broad code smell review, or commit-scoped bug hunting. |
| compatibility | Requires access to PR metadata, diffs, and preferably CI or validation signals. Works best with local checkout access, GitHub PR context, and the repository's own test or release workflow. |
| metadata | {"short-description":"Review open PRs for merge risk"} |
SWE PR Risk Review
What This Skill Does
Use this skill to review an open or draft pull request before merge and decide
where the engineering risk is concentrated.
The expected outcome is a concise risk report that tells the user:
- what the PR changes
- what makes it risky or low-risk
- what validation is missing or weak
- what rollout, rollback, or migration gaps still need attention
- what the smallest safe next action is
This skill is deliberately narrower than post-merge monitoring and bug hunting.
It is about merge readiness, not production impact and not retrospective defect
mining.
When To Use
Use this skill when the user wants to:
- review a PR before merge
- decide whether a change is safe to merge
- identify missing tests, checks, or rollout planning on an open PR
- assess whether migrations, flags, or interface changes need extra caution
- get agent-safe follow-up actions without doing the merge
Do Not Use
Do not use this skill for:
- post-merge production monitoring
- scanning recent commits for regressions after the fact
- a broad code style or architecture review with no PR scope
- general project planning or roadmap feedback
- security-specific review when the user explicitly asked for a security audit
Inputs To Confirm
Confirm or infer:
- the PR number, branch, or diff scope
- the repository or service in scope
- whether CI or local validation data is available
- whether the user wants report-only output or a concrete follow-up plan
- any no-touch areas, rollout constraints, or deadlines
If the request is vague, ask for the PR link or number and the intended review
focus before proceeding.
Tooling Stance
This skill is tool agnostic.
Use the strongest available evidence from:
- PR metadata and diffs
- CI status or failing checks
- local test or typecheck commands
- migration or rollout notes
- feature-flag or config changes
- release or rollback documentation
Prefer the repository's own validation commands and only broaden if the local
signals are insufficient.
Instructions
Step 1: Define The PR Scope
Capture the PR number or link, title, merge target, and changed files.
If the user gave only a branch name or short description, resolve it to the
specific PR before reviewing risk.
Step 2: Map The Risk Surfaces
Inspect the diff and identify the concrete surfaces likely affected:
- APIs, handlers, jobs, or CLI entry points
- shared libraries or serialization boundaries
- schema or migration changes
- feature-flagged paths
- rollout, rollback, or compatibility-sensitive surfaces
Keep the mapping short and concrete. Do not widen the scope beyond what the PR
actually touches.
Step 3: Check Validation Quality
Assess what evidence exists for the change being safe:
- tests added or updated
- existing tests that cover the changed paths
- CI status and failing checks
- local validation commands that apply to the touched surface
- missing validation for risky branches, edge cases, or migrations
Treat missing validation as a real risk signal when the PR changes behavior.
Step 4: Check Rollout And Compatibility Risk
Look specifically for:
- backward-incompatible API or data changes
- migrations that need ordering, backfills, or cleanup
- feature flags without a clear default or rollback path
- interface changes that require coordinated updates
- config changes that can fail in partially deployed states
- hidden coupling across packages, services, or consumers
If the PR depends on an assumption outside the diff, say so explicitly.
Step 5: Separate Strong From Weak Signals
Only report a finding when the evidence supports it.
Bucket observations into:
- strong risk: concrete gap, inconsistent update, or clear missing safeguard
- moderate risk: plausible issue with visible local impact
- weak signal: suspicious but not enough to justify a concrete recommendation
Do not inflate weak signals into firm findings.
Step 6: Propose The Smallest Safe Next Action
For each strong or moderate finding, recommend one small next action such as:
- add a targeted test
- document the rollout or rollback assumption
- split the change into safer phases
- add a guard or compatibility shim
- verify the migration order
- add a feature-flag default or fallback
Keep recommendations tightly scoped and reviewable.
Output Requirements
Provide a report with these sections:
- Scope reviewed
- Ranked risk findings
- Weak-signal observations skipped
- Recommended next actions
For each finding, include:
- PR number, title, and link if available
- relevant files or surfaces
- concrete risk evidence
- why this is a merge risk
- smallest safe next action
- suggested validation
- confidence level
For each weak-signal observation, include:
- what looked risky
- why the evidence was insufficient
- explicit no-action decision
Quality Bar
- Stay pre-merge and do not drift into post-merge impact analysis
- Use concrete PR and diff evidence rather than generic review language
- Treat missing validation and rollout gaps as first-class risk signals
- Keep the output short, prioritized, and directly actionable
- Prefer the smallest safe follow-up over broad redesign advice
