Publish one completed change as a clear, accurate, ready-for-review GitHub pull request.

A direct request to create, open, or publish the PR authorizes the ordinary commit, push, and PR creation needed for that exact change. If a matching open PR already exists, this includes updating its title and body to reflect the completed change and marking it ready for review. It does not authorize force-pushing, merging, issue edits, labels, reviewers, assignees, or unrelated local changes.

Leave the published PR open for review. Merging requires a separate explicit user instruction after publication and delivery of the PR URL, even if the original request bundled creation and merging. Do not merge, enable auto-merge, or enqueue a merge during this workflow.

If the intended change set is empty, mixed with changes of uncertain ownership, or incomplete, stop before committing or pushing and explain the exact blocker.

Before publication, confirm that the requested scope is complete, the base and head are correct, the full PR diff is coherent, and no known blocker is hidden.

Run repository-required formatting, lint, type, test, build, or validation commands at their required stage: before committing, after committing, after pushing, or after PR creation. Require checks that can run before publication to pass before creating or marking the PR ready. Checks that require a push or PR run after that prerequisite exists; report them as pending until results are available. If the repository specifies no checks for this change, use the smallest deterministic checks that exercise the changed behavior, with on the intended diff as the minimum repository check.

Reuse recorded verification results when they can be tied to the code being published and the relevant dependencies, configuration, and environment still match. Run only missing or invalidated checks unless repository rules require a fresh run at the current stage; opening a PR is not itself a reason to repeat successful verification.

Record the exact commands and outcomes, distinguishing passed, failed, skipped, and unable-to-run checks. Confirm required coverage actually ran; a successful command that excluded it does not satisfy the publication check. A known required-check failure or unavailable required check blocks creating or marking the PR ready at that stage. Report the failure or gap; if a PR already exists, include its URL and leave it open. Never claim a test, review, or user journey that was not run. Preserve valid failing regressions; do not weaken tests, bypass the failing path, or reclassify required checks merely to publish. Resolve in-scope defects when authorized, or report the precise blocker.

If in-scope local changes remain, run checks required before committing, stage only the intended changes, inspect the staged diff, and create one clear commit for that completed work. Preserve existing commits unless the user explicitly requests a history change. Update the recorded head commit, recompute the complete base-to-head diff, and run checks required after committing. A commit with unchanged tested file contents does not invalidate evidence unless the check depends on Git metadata. If hooks change files, or verification depended on worktree changes absent from the commit, rerun the affected checks against the final revision.

Derive the title and body from the source issue or specification when available, the complete committed diff, the commit list, and the final verification results. Do not rely on conversation memory alone.

Follow the applicable repository template or the user's requested format. Preserve required sections and answer them accurately; omit optional sections that add no information. Do not mark template checkboxes complete without supporting evidence.

When no template governs, choose the structure the change warrants. A simple PR may need only a short explanation of the problem and resulting behavior, followed by verification commands and outcomes. Add implementation decisions, review pointers, compatibility risks, or non-goals only when they help assess the change. Avoid duplicate summaries, empty headings, and boilerplate such as a mandatory "None identified" risk section.

Keep every claim traceable to repository evidence. Do not invent scope, files, tests, risks, follow-up work, or success. Remove secrets, absolute local paths, private command output, and internal agent artifacts. Use repository-relative paths and concise result summaries.

Add only when the PR fully completes that same-repository issue. Use a non-closing reference when the issue is only context or the work is partial. Do not infer issue numbers from branch names alone.

Write the reviewed Markdown to a temporary file outside the repository, or stream it through standard input when supported. Pass it with ; do not interpolate multiline Markdown into a shell argument.

Require and successful authentication for the active account on the resolved host using .

Compare the remote head branch with the recorded head commit. Push only if that commit is not already the remote branch tip, using the resolved source ref and destination branch explicitly, without force. Confirm the source ref still identifies the recorded commit before pushing; if it moved, inspect and verify the new state first. Preserve existing upstream tracking configuration; publishing a PR does not require changing it.

For an existing matching PR, use with its URL and explicit title and arguments only when updates are needed. Preserve accurate human-authored context. Once the applicable checks pass, use with its URL if it is a draft. Do not call for an existing open PR.

Otherwise create the PR with explicit arguments, including the resolved host in the repository identifier:

gh pr create \
  --repo HOST/OWNER/REPO \
  --base BASE_BRANCH \
  --head HEAD_BRANCH \
  --title "TITLE" \
  --body-file PR_BODY_FILE

For a fork, qualify the head as . Never pass ; this skill creates a real PR that is immediately ready for human and automated review.

If creation fails or returns unclear output, query GitHub for the exact head and base before retrying. Never blindly repeat a create operation. If the push succeeded but PR creation did not, preserve the pushed branch and report the partial state and exact error.

Read the created or reused PR back by URL with and verify:

Inspect checks that require publication now that the PR exists. Return the PR URL and number, base and head, published commit, verification commands and outcomes, and any pending or failed checks or other disclosed limitation, then stop with the PR open for review. Do not manually close its source issue.