# Pr Safety

> Assess the risk of merging a PR: what could go wrong, regressions, blast radius, rollback difficulty. Posts assessment as a PR comment.

- Skill: `dylanpulver/pr-safety` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dylanpulver/pr-safety`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dylanpulver/pr-safety/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dylanpulver (https://skillmd.com/u/dylanpulver)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dylanpulver/pr-safety

---


# PR Merge Safety Assessment

Before merging a PR (especially to production), assess what could go wrong. This is NOT a code review — it's a risk assessment.

**Input:** "$ARGUMENTS"

## Workflow

### 1. Identify the PR

- If a PR URL or number is provided, use it
- Otherwise detect from current branch: `gh pr view --json number,url,headRefName,baseRefName,state`
- If the PR is closed or merged, stop

### 2. Understand the Change

Gather context in parallel:

```bash
# What files changed and how much
gh pr diff <number> --name-only
gh pr view <number> --json additions,deletions,changedFiles,title,body

# Full diff
gh pr diff <number>

# What checks passed/failed
gh pr checks <number>

# Git history for changed files (is this area fragile?)
gh api "repos/<owner>/<repo>/commits?path=<file>&per_page=10" \
  --jq '.[] | "\(.sha[0:7]) \(.commit.author.date[0:10]) \(.commit.message | split("\n")[0][0:80])"'
```

Read the changed files in full (not just the diff) to understand the surrounding context.

### 3. Check for Related PRs

Look for other open PRs that touch the same files or are part of the same initiative:

```bash
# Other open PRs
gh pr list --state open --json number,title,headRefName --limit 20
```

If related PRs exist, note them — merging order may matter, or they may conflict.

### 4. Assess Risk Dimensions

For each dimension, rate **LOW / MEDIUM / HIGH** with a one-line justification:

**Blast Radius**
- How many users/systems are affected?
- Is this a hot path or a rarely-hit edge case?
- Does this touch shared infrastructure (database, auth, payments, queues)?

**Regression Potential**
- Could this break existing behavior?
- Are there implicit dependencies that might not be obvious from the diff?
- Does the change modify a function signature, API contract, or data shape that others consume?
- Check the git history — has this area been fragile or frequently changed?

**Data Safety**
- Does this change database schema, migrations, or data access patterns?
- Could this cause data loss, corruption, or inconsistency?
- Are there irreversible data operations (deletes, truncates, column drops)?

**Rollback Difficulty**
- If this goes wrong, how hard is it to revert?
- Are there database migrations that can't be rolled back?
- Does this change state in external systems (Stripe, accounting platforms, third-party APIs)?
- Would reverting the code leave data in an inconsistent state?

**Dependency Risk**
- Does this add/upgrade/remove dependencies?
- Are there version conflicts or breaking changes in upgraded packages?
- Does this change environment variables or config that deploys depend on?

**Concurrency & Timing**
- Could this create race conditions under production load?
- Are there operations that assume sequential execution but might run concurrently?
- Does this interact with queues, workers, or scheduled jobs?

### 5. Check for Red Flags

Explicitly look for:
- [ ] Database migrations without a rollback path
- [ ] Removed or changed API endpoints that clients depend on
- [ ] Changes to auth/permissions logic
- [ ] Modified payment or billing code
- [ ] Hard-coded values that differ between environments
- [ ] Console.log or debug code left in
- [ ] Environment-specific config changes
- [ ] Changes to retry/timeout behavior
- [ ] Race conditions in async operations

### 6. Post the Assessment

Post the assessment as a PR comment using `gh pr comment <number> --body "..."`.

Use this format:

```
### Merge Safety Assessment

**Overall Risk: [LOW / MEDIUM / HIGH]**
[One sentence summary of the biggest concern]

#### Risk Breakdown

| Dimension | Risk | Why |
|---|---|---|
| Blast Radius | LOW | Only affects admin dashboard settings page |
| Regression | MEDIUM | Modifies shared utility used by 3 services |
| Data Safety | LOW | Read-only query changes |
| Rollback | LOW | No migrations, pure code change |
| Dependencies | LOW | No dependency changes |
| Concurrency | HIGH | New async handler doesn't lock shared resource |

#### Related PRs
- PR #465: [title] — touches same area, merge order matters
- (or "None found")

#### Red Flags
- [Any red flags found, or "None found"]

#### What Could Go Wrong
1. [Specific scenario] — [likelihood] — [impact if it happens]
2. ...

#### Recommended Before Merging
- [Specific actions: "run the sync integration tests", "verify staging handles X", etc.]
- [Or: "Safe to merge — no action needed"]

#### Safe to Merge?
[YES / YES WITH CONDITIONS / HOLD — with reasoning]

🤖 Safety assessment by Claude Code
```

**If `--no-post` was passed, display the assessment in the conversation instead of posting.**

## Rules

- Be specific, not generic. "Something might break" is useless. "The retry logic in syncWorkflow.ts:L142 now retries 5x instead of 3x, which could cause rate limiting with the upstream API" is useful.
- If the PR is trivial (typo fix, comment update, dev tooling only), say so immediately — post a short "Low risk, trivial change" comment and skip the full assessment.
- Don't fabricate risks. If the change is genuinely safe, say so.
- Always check git history for changed files — frequent recent changes signal an area in flux.
- Always check for related open PRs — merge conflicts and ordering issues are a real risk.