name: create-pr description: A skill for driving GitHub pull request creation. Handles change review, required checks, commit, push, and PR creation in one flow, and expects fresh verification evidence from code-change-verification when repository code changed. allowed-tools:

• Bash
• Read
• Grep
• Glob user-invocable: true

Create PR

Handle the full sequence needed to create a GitHub pull request, from reviewing changes through creating the PR.

When the repository uses code-change-verification, treat that skill as the upstream verification gate for runtime, test, build, or UI-related changes.

Relationship To code-change-verification

• Use code-change-verification before this skill when repository code, tests, build behavior, or visible UI changed.
• The expected input from that skill is: commands run, pass/fail outcomes, skipped checks with reasons, environment blockers, and manual verification evidence.
• Do not create a PR based on stale or assumed verification state.

Repository Defaults

• Commit messages must be written in English unless the user explicitly asks for another language.
• Pull request titles must be written in Japanese unless the user explicitly asks for another language.
• Pull request bodies must follow .github/pull_request_template.md when that file exists.
• When filling a template, replace placeholder guidance with concrete content and remove prompts that are no longer useful.

Workflow

1. Confirm scope

Start by checking the scope of the changes.

git status
git diff

If the change set is too broad, includes unintended diffs, or has unresolved conflicts, clean that up first.

2. Run required checks

Before committing, determine and run the checks required by this repository. Typical examples are format, lint, typecheck, and test.

• If there are project-specific steps, follow those first
• If this repository uses code-change-verification, prefer that skill's final pass and reuse its fresh verification summary here instead of inventing a new checklist ad hoc
• If any check fails, fix it before moving on
• Tell the user what you ran and what the outcome was
• If required verification has not been run yet for a code change, stop and run code-change-verification before committing or opening the PR

3. Stage and commit intentionally

Stage changes in a way that keeps the scope clear. Prefer explicit paths, and confirm the intended commit scope before proceeding when the change set is broad.

git add path/to/file1 path/to/file2
git commit -m "type(scope): short summary"

Choose the commit message using this priority order.

1. Explicit user instruction
2. Existing repository convention
3. Conventional Commits if there is no explicit convention

Even when following repository convention or Conventional Commits, write the final commit message in English unless the user explicitly asks for another language.

4. Push the branch

Check the current working branch name, then push that branch explicitly.

git branch --show-current
git push -u origin <branch-name>

Avoid ambiguous forms such as git push; always include the branch name.

5. Create the pull request

Before creating the PR, confirm the following.

• Whether the user specified a base branch
• Whether the repository has project-specific workflow rules
• Otherwise, what the repository default branch is
• If .github/pull_request_template.md exists, read it and follow it section by section in the body

Do not hardcode the base branch. If the user did not specify one, use the repository default branch. Only ask when the default branch cannot be determined, and explain why.

Unless the user explicitly requests otherwise, write the PR title in Japanese and keep it concise and descriptive.

Do not embed a long PR body directly in CLI arguments; pass it through a temporary file.

cat <<'EOF' > /tmp/pr_body.md
<pull request body>
EOF

gh pr create --base <base-branch> --title "<pr-title>" --body-file /tmp/pr_body.md

Add --draft when needed. If there is no explicit instruction, decide whether draft is appropriate based on the readiness of the change.

After creation, return the PR URL, and include the title, base branch, and check results if useful.

PR body guidance

If .github/pull_request_template.md exists, follow that template instead of inventing a new structure. Make sure the body includes the fresh verification summary from code-change-verification when applicable.

If there is no template, the body should include at least the following.

• What changed
• Why it changed
• How it was verified, using the fresh summary from code-change-verification when applicable
• Any extra context reviewers should pay attention to

Important notes

1. Do not skip the preparation steps
2. Do not ignore failing checks and continue to commit or PR creation
3. Always keep track of the staged scope and commit scope
4. Do not choose the base branch from a fixed value; follow user instruction or repository workflow
5. Prefer --body-file when passing the PR body
6. If something is unclear, ask the user and include the reasoning
7. When code changed, do not proceed on stale verification. Reuse the latest code-change-verification output or rerun it

Error handling

• If a command fails, explain the cause and the next step concisely
• Use a sufficient timeout for long-running checks
• Use a body file so content containing characters such as [] does not break
• Before pushing or creating the PR, confirm that no unresolved problems remain
• If verification evidence is missing for a code change, the next step is to run code-change-verification, not to continue with the PR