When to use
- •User asks to open a PR / create PR / “make a PR for this”
- •Or invoke with
/create-pr
Branch naming
- •Pattern:
bd-<bead-id>-<short-description> - •Example:
bd-tfo-webapp-98w-user-model
Workflow
- •
Branch validation (FIRST):
- •Run
git branch --show-current - •If on
mainormaster: STOP- •"Cannot create PR from main. Use
/commitfirst to set up a feature branch."
- •"Cannot create PR from main. Use
- •Validate branch name matches
bd-<bead-id>-*pattern (warn if not) - •Verify commits exist ahead of main:
git rev-list --count main..HEAD- •If 0 commits: STOP, nothing to PR
- •Run
- •
Gather context:
- •Current branch + target branch
- •Commits included (
git log --oneline <target>..HEAD) - •High-level diff (
git diff <target>...HEAD --stat)
- •
Produce PR content (Markdown):
- •Title (Conventional-ish, human readable)
- •Summary (3–6 bullets)
- •Changes (bullets grouped by area)
- •Testing (commands + results)
- •UI notes (if applicable)
- •Beads references:
Refs: BD-<id>list - •Risks/rollout notes (only if meaningful)
- •
If user wants to actually open the PR:
- •Prefer
gh pr createif available - •Otherwise output the exact title/body ready to paste
- •Prefer
Output style
- •Be concise. Engineer-readable. No fluff.
Notes
- •If the PR mixes concerns, stop and propose splitting.