Menu
Use when assessing the risk profile of a PR — what could break, how blast-radius reaches users, and whether the change is safely revertible — independent of whether merge means immediate deploy. Use when the repository has no equivalent skill of its own.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when ingesting, refreshing, listing, searching, or deleting a local corpus with Blackbird code search and `gh blackbird search --fileset`.
Use when reaching for `gh blackbird` (Blackbird code search) for cross-repo lexical, symbol, or semantic search on GitHub — finding callers, ownership, or how systems work without cloning.
Use when creating a GitHub pull request, or when updating an existing PR's title or body so it matches what the code actually does.
Use when authoring or substantially editing a design doc, architecture doc, or subsystem explanation — the "here's what's there and why" companion to an ADR's terse decision record.
Use when creating a repo-tracked multi-agent planning PR for a large project, especially when phases, living docs, parallel agent prompts, and cross-PR coordination are needed.
Use when about to call a library, crate, or framework API you haven't verified, when a dependency's behavior is surprising, when training-data memory might be stale, or when investigating how a dependency actually behaves.
| name | pr-risk-check |
| description | Use when assessing the risk profile of a PR — what could break, how blast-radius reaches users, and whether the change is safely revertible — independent of whether merge means immediate deploy. Use when the repository has no equivalent skill of its own. |
Hunt the diff for changes whose failure mode is "page someone / roll back / restore from backup." Correctness review and risk review are different lenses — passing tests don't tell you whether the change is safe to land.
The PR is the unit. "Risk of merging" is the same question whether merge ships immediately (web service auto-deploy), behind a release train (desktop app, mobile, on-prem), or behind a flag. Time-to-users changes how urgently a risk matters, not whether it exists.
If the repository has its own risk-review, deploy-risk, release-readiness, or change-review skill, that wins. Use this skill when nothing more specific applies.
Skip for: docs-only changes, test-only changes, internal tooling that can't reach users, prototypes behind unreleased flags.
This skill makes you a careful reviewer, not a gatekeeper. Default to advisory: surface findings so the author can decide. Promote something to a true blocker only when you can prove the failure mode — not when you can imagine one.
The cost of a false-positive blocker (slowed delivery, eroded trust in review) is real. So is the cost of a missed real risk. Calibrate by showing your work, not by raising the loudness.
Read the diff with these categories in mind. For each hit, write a concrete note: what could break, how it would manifest, what would catch it, and whether the change is safely revertible.
Default tone is advisory. Group findings by severity, and let the evidence — not the label — do the work.
For each item: one-line description, one-line "how it fails in prod" with file:line evidence, one-line suggested mitigation. No essays. If a finding requires deeper research to substantiate, do that research before posting — read the surrounding code, check related modules, search for prior incidents or ADRs, run the migration plan, look at the deploy pipeline config. Show that work in the finding.
If the diff is genuinely low-risk, say so plainly — "no deploy-risk findings; data path unchanged, behind existing flag" beats a manufactured concern. Do not pad the list.
