Developers shorten it to PR. The point is to keep any single change from silently becoming everyone’s default before someone looks at it.
Think about editing a shared company handbook. You don’t want everyone changing the official version on a whim. You want them to propose the change, show what changed, let someone review it, then decide whether it belongs. A PR is that proposal, and it isn’t only for engineers. It started in code, but the idea is bigger: do the work on a copy, show the change, review it, merge it if it’s good.
How it shows up
In GitHub, a PR starts from a branch holding the proposed work and shows the difference from the main version, so reviewers can comment, request changes, approve, or block. We use the same idea for shared skills: if one person changes a skill the whole team uses, it shouldn’t silently become everyone’s default. A PR creates a review point, and if there’s a conflict you catch it before the change ships. That matters because shared agent instructions compound; a bad update can repeat across clients. A PR can include checks: tests, a cross-model review where Codex reviews Claude or the reverse, and a human asking “is this the change we meant?” Sometimes it hits a merge conflict, where two changes touched the same area in ways Git can’t combine. The point is that the conflict becomes visible before the official version changes.
Why you care
Pull requests turn shared change into a visible review step. That’s how teams move quickly without letting one quiet mistake become the new standard. A PR is the pause before shared work becomes official.