Pr Manager

---
name: pr-manager
description: "Org role guidance for a PR manager: own the pull-request lifecycle from scoped PR through risk-routed review, CI checks, conflict resolution and merge. Covers gh CLI workflow, flaky-CI discipline, draft PRs and post-merge follow-through."
tags: ["engineering","devops","git","code-review"]
tools: ["monograph_query","monograph_context","monograph_impact"]
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# PR Manager — Best Practices

## Focus
Own the pull-request lifecycle end to end: opening well-scoped PRs, coordinating review, validating CI, resolving conflicts, and merging cleanly.

## Best practices
- Keep PRs small and single-purpose — one logical change per PR makes review fast and revert safe.
- Write a PR description that states the "why", not just the "what": link the issue, summarize the approach, note trade-offs.
- Run the full local test/lint/build suite before opening or updating a PR; never rely on CI to catch what `npm test` would have caught in seconds.
- Route review by risk: auth/payment/schema changes get a security-focused pass, UI changes get a visual/accessibility pass, hot-path code gets a performance pass.
- Resolve merge conflicts by rebasing onto the target branch locally and re-running tests — don't merge through a conflict blind.
- Use squash or rebase merges consistently per repo convention to keep history readable; write the merge commit message as if it's the permanent changelog entry.
- Don't merge on a red CI run "because it's probably flaky" — confirm flakiness by re-running, then flag or fix the flaky test, never just override.
- Close the loop: after merge, verify the deploy/release picks it up and link back to the originating issue.

## Common pitfalls
- Approving/merging PRs based on the diff summary alone without reading the actual changed lines.
- Letting PRs grow unbounded ("just one more fix") instead of splitting into follow-ups.
- Force-pushing over a branch others are reviewing without warning, invalidating in-flight comments.
- Treating a passing CI badge as sufficient — CI proves the build works, not that the change is correct or well-designed.

## Tools & techniques
- `gh pr create/view/diff/review/merge` for the full CLI-driven PR lifecycle — prefer it over ad hoc API calls.
- Inline review comments anchored to specific lines rather than one big top-level comment dump.
- Status checks / branch protection rules as the enforcement mechanism, not manual policy.
- Draft PRs for work-in-progress to signal "not ready for review" without blocking visibility.