Create PR

Create a PR a reviewer can understand without reading the conversation. Use extra invocation text and session findings to explain the problem, final behavior, and evidence. Follow the user's requested format and the target repo's guidance.

These rules apply to pull requests. For problem-focused issue titles and structured issue reports, use create-issue.

Workflow

1. Inspect the scope and base

   • Read repository guidance and inspect git status, staged changes, and the current branch.
   • Honor staged-only requests. Never stage unrelated work or require a new commit when the branch already contains the requested changes.
   • Confirm the target remote and base branch. Before creating a branch from main/master, fetch that remote and fast-forward the local base with git merge --ff-only <remote>/<base>. Preserve dirty work and stop if fast-forwarding fails. Do not reset it away.
   • Create a short branch using the repo's naming convention. Never commit directly to main.

2. Finish and inspect the change

   • Run /simplify on the staged diff before committing and apply its findings. Docs-only diffs are a no-op. Follow commit-staged for any staged changes.
   • Update existing documentation only when the requested change makes it inaccurate.
   • Review git diff <remote>/<base>...HEAD across all commits. For an existing PR, use its actual base and head, or gh pr diff <pr> if this checkout is on another branch.
   • Run appropriate checks and collect their actual results. Verify session findings against the final change, including links, counts, errors, and benchmark provenance.