with one click
pm-pr-workflow
Branch protection and PR creation workflow
Menu
Branch protection and PR creation workflow
Standard for authoring product PRDs in docs/prd/: state the problem, users, requirements, and success; assign PRD-{AREA}-{NN} IDs; link down to specs.
Standard for authoring engineering behavior-contract specs in docs/specs/: scope subsystems, assign stable IDs, structure docs, manage lifecycle.
Complete circuit breaker enforcement patterns with examples and remediation
Pause session and save current work state for later resume
Load context from paused session
Pause session and save current work state for later resume
| name | pm-pr-workflow |
| version | 1.0.0 |
| description | Branch protection and PR creation workflow |
| when_to_use | PR creation, branch operations, git push to main |
| category | pm-workflow |
| tags | ["git","pr","branch-protection","pm-required"] |
| effort | medium |
CRITICAL: PM must enforce branch protection for main branch.
When users request main branch operations:
| User Request | PM Action |
|---|---|
| "commit to main" | "Creating feature branch workflow instead" |
| "push to main" | "Branch protection requires PR workflow" |
| "merge to main" | "Creating PR for review" |
Error Prevention: PM proactively guides users to feature branch + PR workflow (don't wait for git errors).
The PR workflow is the framework default for landing work on main. Enforce these rules:
For substantive work (feature / fix / refactor), create or reference a GitHub issue before creating the branch. The issue captures intent + acceptance criteria. Delegate issue creation to the ticketing_agent / Version Control agent. The branch name should reference the issue (feat/<issue>-<slug>, fix/<issue>-<slug>), and the functional commit body should include Closes #N.
PRs MUST be merged using the squash-merge strategy (one clean commit on main per PR). Delete the feature branch immediately after the squash-merge. Do not use merge commits or rebase-merge for these PRs.
Trivial work (docs / chore / typo) may skip the issue, but still REQUIRES a branch + PR + squash-merge. Never commit trivial work directly to main.
Direct commits to main are permitted ONLY for release tooling: make release-* version bumps and chore: update uv.lock commits. Nothing else may bypass the PR workflow.
Default: Main-based PRs (unless user explicitly requests stacked)
Always delegate to version-control agent with strategy parameters.
When creating PRs, delegate to version-control agent with:
Task:
agent: "version-control"
task: "Create PR for {feature}"
context: |
Work completed: {summary}
Files changed: {file_list}
Tests: {test_status}
QA verification: {qa_evidence}
acceptance_criteria:
- Create feature branch from main
- Push all commits to feature branch
- Create PR with proper description
- Link ticket if applicable
- Request reviews if needed
# Feature branch → PR → Main
feature/user-auth → PR #123 → main
# Stacked feature development
feature/auth-base → PR #123 → main
feature/oauth (based on auth-base) → PR #124 → feature/auth-base
feature/session (based on oauth) → PR #125 → feature/oauth
# Hotfix branch → PR → Main
fix/login-error → PR #126 → main
Before any main branch operation:
All file tracking should happen on feature branches before PR creation:
This ensures all work is tracked before entering PR workflow.