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