Feature: pre-PR branch freshness check before CI submission
Problem
When a feature branch is behind the base branch, CI can fail for reasons unrelated to the branch's changes — for example, a schema check or integration test failing because the base branch made a breaking change that the stale feature branch hasn't picked up yet. This wastes a CI cycle (10-15 min) and requires investigation to realize the fix is just merging the base branch.
Suggestion
Add an optional branch freshness check to Claude Code's workflow, particularly useful before creating or pushing to a PR:
- Detect staleness:
git fetch origin <base> && git rev-list --count HEAD..origin/<base> - Alert the user interactively: "Your branch is N revisions behind <base>. Get latest before continuing?"
- User chooses: "Get latest revisions (N behind <base>)" or "Skip — continue with current branch"
- If syncing: run the merge, verify no conflicts, then continue
For repos with generated schemas (GraphQL, OpenAPI, protobuf), a schema regeneration check after the merge would catch drift before CI does.
Context
We hit this in practice: a PR's CI failed on a schema validation step because the base branch had made a breaking change after our feature branch was cut. The feature branch had zero schema changes — merging the base branch fixed it immediately. A 2-second check would have saved a 15-minute CI round trip.
Current workaround
We added this as a custom /pre-pr command skill that runs the check and asks the user before proceeding. Works well but would be more useful as a built-in behavior or a recommended pattern in Claude Code's PR workflow.