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