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:

# 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:

# 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.