Git PR

Git PR

Publish a coherent pull request through Git and the official gh CLI. Reuse the existing git-commit skill for staging and commit boundaries instead of reproducing its rules here.

Enforce the review gate

Never push or mutate a pull request before completing all of these steps:

1. Prepare the exact final pull request.
2. Show the user the repository, base branch, head branch, draft status, title, complete body, labels, reviewers, assignees, milestone, linked issues, local commits, and planned push remote.
3. Ask the user to approve that exact preview.
4. Wait for an explicit approval in a later user response.

Treat the initial request to create or submit a PR only as authorization to prepare the preview. Do not treat it as approval of content or metadata the user has not seen. Do not bypass the gate when the user says "submit directly."

Bind approval to the displayed revision. If the diff, commit set, title, body, base, head, draft status, remote, labels, reviewers, assignees, milestone, or linked issues change after approval, show the revised complete preview and obtain approval again.

Before approval, do not run git push, gh pr create, gh pr edit, gh pr ready, gh pr comment, or any equivalent API mutation. Local read-only inspection and local commits requested through git-commit are allowed. Tell the user if local commits are created while preparing the PR.

Prepare the branch and evidence

1. Read the applicable repository instructions, including AGENTS.md and routed rule files.
2. Resolve the repository, default branch, current branch, remotes, and viewer permission dynamically.
3. Inspect worktree status, staged changes, commits, and base...HEAD. Never publish directly from the default branch.
4. If required changes are uncommitted, invoke or follow git-commit to create coherent local commits. Never include unrelated user changes or secrets.
5. Confirm that code changes have synchronized both required project design and development-plan documentation.
6. Use fresh verification evidence for the final commit set. Never claim a test, build, benchmark, or visual check that did not complete successfully against the reviewed revision.
7. Read .github/PULL_REQUEST_TEMPLATE.md, pull-request templates, semantic-title workflows, repository rules, and current checks. Treat them as authoritative and do not hardcode main or a status-check name.
8. Check whether the head branch already has an open PR. Prepare an update to that PR instead of creating a duplicate.
9. Identify related issues. Use Closes #N only when merge fully resolves the issue; otherwise use Refs #N.

Draft the PR

Use English for the published title, template headings, and prose by default. Translate a Chinese request into natural technical English while preserving code, commands, logs, identifiers, and quoted errors verbatim. Use Chinese only when the user explicitly requests a Chinese PR.

Follow the repository PR template. Remove inapplicable optional sections instead of filling the body with empty headings or N/A. Ensure the body communicates:

• The outcome and scope.
• Root cause or design rationale when relevant.
• The concrete changes and removal of replaced paths.
• Verification commands and truthful results.
• Product-design and development-plan documentation updates.
• Performance impact and overdesign review conclusions when meaningful.
• Known risks, limitations, migrations, or follow-up work.

Never add agent attribution to the title, body, or commits: no "Generated with" line, Co-Authored-By trailer, or other credit for Claude, Codex, or any AI agent, even if the host environment suggests one.

Generate a title that satisfies the repository's current semantic-title rules. Prefer Conventional Commits form:

<type>[optional scope]: <imperative description>

Do not use vague titles such as update, fix bug, or [codex] ... when semantic titles are enforced.