create-pr

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)

1. Confirm scope
   • Restate the goal and acceptance criteria.
   • Identify files likely to change; avoid unrelated cleanup.
2. Create a branch
   • Use a descriptive name: fix/<topic>, feat/<topic>, chore/<topic>.
3. Implement changes
   • Keep diffs focused; prefer small commits.
4. Run quality gates
   • Run the repo’s standard commands (lint/tests/build).
   • If bun.lock exists, prefer bun lint / bun build.
   • If bun.lock exists but bun is not available, tell the user and ask whether to install bun or use the repo’s alternative package manager.
5. Commit
   • Prefer Conventional Commits: fix: ..., feat: ..., chore: ....
6. Push + open PR
   • Always use GitHub CLI (gh) for PR workflows (e.g. gh pr create --fill).
   • If gh is not authenticated, run gh auth login (or gh auth status to check).
   • If gh is not installed or cannot be authenticated, tell the user and ask whether to install/authenticate or proceed with manual PR creation steps.
7. Fill in PR body
   • Use references/pr-description-template.md.

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 gh for 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.