| name | create-pr |
| description | Create a high-quality pull request: branch, focused changes, lint/build, conventional commit, and a clear PR description with validation steps. Use when the user asks to open or prepare a PR. |
Create a PR
Goal
Produce a PR that’s easy to review and safe to merge:
- small, scoped changes
- green checks (lint/tests/build as appropriate)
- clear description + validation steps
Workflow (checklist)
- Confirm scope
- Restate the goal and acceptance criteria.
- Identify files likely to change; avoid unrelated cleanup.
- Create a branch
- Use a descriptive name:
fix/<topic>,feat/<topic>,chore/<topic>.
- Use a descriptive name:
- Implement changes
- Keep diffs focused; prefer small commits.
- Run quality gates
- Run the repo’s standard commands (lint/tests/build).
- If
bun.lockexists, preferbun lint/bun build. - If
bun.lockexists butbunis not available, tell the user and ask whether to installbunor use the repo’s alternative package manager.
- Commit
- Prefer Conventional Commits:
fix: ...,feat: ...,chore: ....
- Prefer Conventional Commits:
- Push + open PR
- Always use GitHub CLI (
gh) for PR workflows (e.g.gh pr create --fill). - If
ghis not authenticated, rungh auth login(orgh auth statusto check). - If
ghis not installed or cannot be authenticated, tell the user and ask whether to install/authenticate or proceed with manual PR creation steps.
- Always use GitHub CLI (
- Fill in PR body
- Use
references/pr-description-template.md.
- Use
Notes
- Don't force-push unless you're sure it's safe for collaborators.
- If the PR changes UX, include screenshots or a short GIF.
- Prefer
ghfor create/view/checks (e.g.gh pr view,gh pr checks).
Deliverable
Provide:
- Branch name and PR URL (or the exact steps to open it manually).
- PR title/body (using
references/pr-description-template.md). - Commits included and verification commands run.
- Screenshots/GIFs if UX changed.