PR Workflow Pattern

Every repository I set up gets two commands from the start:

bun run pr — Runs all checks: formatting, linting, type checking, building, and tests. This is what CI runs on every pull request. If it passes locally, it passes in CI.

bun run pr:fix — Applies automatic fixes: formats code, applies safe linter fixes, then runs the checks. Use this before committing.

The pattern keeps configuration centralized and makes onboarding trivial — new contributors just run bun run pr:fix and they're good.

I pair this with a GitHub Action that runs bun run pr on every push. Simple, predictable, and removes the "works on my machine" problem.

When I use it

• On every new repository from day one.
• In teams where consistency and predictable CI outcomes matter.
• In projects with mixed experience levels where onboarding speed is important.

When I avoid it

• Tiny throwaway prototypes that are intentionally short-lived.
• Repositories where checks are still in flux and not worth standardizing yet.
• Codebases with tooling that cannot be invoked reliably from one command entrypoint.

One real example

This pattern is used in my project setups with centralized scripts so contributors know exactly what to run locally before opening a PR.

{
  "scripts": {
    "pr": "bun run format:check && bun run lint && bun run typecheck && bun run build && bun run test",
    "pr:fix": "bun run format && bun run lint:fix && bun run pr"
  }
}