---
name: github-pr-create
which: gh
disable-model-invocation: true
description: "Create or update a GitHub pull request and drive it to review-ready completion. Use when asked to make, open, prepare, publish, or finish a GitHub PR."
---

# GitHub PR Create

An explicit request to create or finish a PR authorizes the relevant commits, synchronization, push, and PR creation or update.
Ask only about ambiguity, destructive action, or a rule below.

## Procedure

1. Preserve unrelated work and resolve the repository, branch, target, existing PR, linked issues, and applicable repository policy.
   Process one PR by default.
2. Reuse an existing PR for the branch; never create a duplicate.
   Avoid stacked PRs; when unavoidable, state the dependency and retarget after its parent merges.
3. Preserve intent from the original request through linked issues or specifications to the final diff and description.
   Reject scope creep and separate unrelated changes when safe.
4. Ensure local changes are committed, the branch is rebased onto the latest target, required checks pass, and the branch is published without unauthorized history rewriting.
   Conflicts or required published-history rewrites require user direction; never rewrite the target.
5. Do not open a draft.
   If local checks fail, show evidence and ask whether to open the PR with known failures.
6. Write the title and body in the user's established outward-facing voice.
   Explain context, pain, reason, and outcome; prefer prose over unnecessary headings.
   Do not add verification paragraphs for passing checks or restate behavior already established by the body.
   Mention checks only when failure, omission, or limitation materially affects review or merge.
   Follow repository commit rules because the text may become the squash commit message; add no AI attribution.
7. Follow templates, changelog, release-note, ownership, reviewer, and labeling policy.
   Apply sensible existing semantic labels; create or reuse `harness:<name>` and `model:<name>` labels when supported and relevant.
   Confirm before requesting reviewers, then verify each request succeeded.
8. Use GitHub closing syntax only when the PR fully resolves an issue.
   When exactly one applicable issue is identified from the request or branch, preserve its closing reference in commits when required.
   Ask which issue governs when several are plausible.
9. Attach useful real screenshots or demos for visual changes.
   Use Mermaid when relationships, sequence, or structure are clearer visually.
   The diagram must add information rather than repeat the prose.
   Prefer native GitHub attachments and use clearly labeled explanatory visuals when real evidence is unavailable.
   Keep temporary evidence out of commits unless it is an explicit deliverable.
10. Treat comments and reviews as claims to verify.
    Fix or rebut with evidence, publish updates, reply, and resolve addressed threads.
11. Watch GitHub Actions and required checks.
    Repair straightforward failures and repeat; after two failed repair rounds, stop with evidence.
12. Keep title and body synchronized with final scope, outcomes, and limits.

For fork PRs, never push to a contributor branch without permission.

Done means: a non-draft PR is open, current with its target, local and GitHub checks are green, verified feedback is addressed, no threads remain unresolved, and task-owned local state is clean.
Report the URL and any blockers.
Do not merge.