ifiokjr/dotfiles/create-pr

Create pull request

Open full pull requests (never drafts) that are ready to merge: a concise, human-readable title that doubles as the squash-commit message, and a problem-first description instead of a raw inventory of changes.

Before creating

Match the repository's conventions:

• Check for a PR template (e.g. .github/PULL_REQUEST_TEMPLATE.md) and follow it
• Follow the repo's workflow: target branch, labels, commit conventions
• Create a full PR, never a draft, unless the user explicitly asks for a draft

PR title

The PR title becomes the commit message when the PR is squash-merged, so write it as a concise conventional commit message:

• Type: fix:, docs:, feat:, refactor:, test:, ci:, build:, chore:
• Breaking change: add ! after the type (and scope if present): fix(api)!:, feat!:
• Scope: add when it adds clarity: fix(solana): ...
• One line, imperative mood, describing what the PR does
• Match the branch's intent (a feat/ branch gets a feat: title)

PR description

Lead with why, then how. Keep it concise and specific, with no filler.

1. Why the PR exists (always first)

Describe the problem that prompted the PR, not a raw inventory of what changed:

• What problem was the user facing, or what did they ask for?
• Capture any discussion that led to the PR, including the context and decisions from the conversation, using the user's own framing where possible
• If the reason is not clear from the conversation, ask the user rather than inventing one

Example: "The settings screen took several seconds to render on device, making the app feel unresponsive. This PR was created to fix that slowness."

2. Implementation (after Why)

Briefly describe how the PR solves it:

• Approach taken and why
• Key areas or files changed
• Notable trade-offs or follow-ups

3. No Testing or Validation section

Never include ## Testing or ## Validation sections. For projects with CI and workflows set up, they are redundant. The validation happens in CI; it doesn't need to be repeated in the description. Unless the user explicitly asks you to specify what was tested and how you validated the code, don't include it. Just explain what you did in Implementation.

Attribution footer

End every PR description with who created it and how:

_Created on behalf of Ifiok Jr. ([@ifiokjr](https://github.com/ifiokjr)) by <harness> using <model> at <thinking level> thinking._

Fill in your real details. Name the harness (e.g. pi, codex), the model you are running (e.g. GPT-5.5, Claude, DeepSeek), and your thinking level. Do not guess; use what you know about your own configuration.

Merging (including "auto-merge" requests)

When the user asks you to auto-merge a PR, or to "merge it once all checks are passing":

• Never use gh pr merge --auto on repos without branch protection. With no required checks, GitHub processes the auto-merge request immediately, merging the PR long before CI finishes. This shipped broken code to main once, and GitHub attributes it to the authenticated account, so there is no audit trail of agent involvement.
• Instead, poll until every check is complete and passing (run gh pr checks <number> in a loop until no pending remains), then explicitly merge only when green. If checks fail, fix the failure and push; do not merge on red.
• When submitting the merge, let the repo's capabilities decide the method, since history shape follows repo convention:
• If squash merging is supported (check gh api repos/<owner>/<repo> --jq .allow_squash_merge or the repo's (#N)-suffixed history), use gh pr merge <pr> --squash.
• Otherwise fall back to gh pr merge <pr> (or --merge), the equivalent normal merge.

Checklist

• [ ] Created as a full PR, not a draft (unless explicitly asked)
• [ ] Followed the repository's PR template and conventions
• [ ] Title is a concise, human-readable conventional commit message (with ! for breaking changes)
• [ ] Description opens with the reason the PR was created, not an inventory of changes
• [ ] Implementation details come after the why
• [ ] No Testing/Validation section (CI covers it) unless the user explicitly asked
• [ ] Attribution footer: on behalf of Ifiok Jr. (@ifiokjr), harness, model, thinking level
• [ ] No generic filler like "This PR fixes stuff"