Menu
Create a GitHub pull request with context-aware description
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | create-pr |
| description | Create a GitHub pull request with context-aware description |
| effort | low |
| allowed-tools | Bash(git status *), Bash(git diff *), Bash(git log *), Bash(git rev-parse *), Bash(git push *), Bash(git ls-files *), Bash(gh repo view *), Bash(gh pr create *), Bash(echo *), Read, Glob, Grep, AskUserQuestion |
!git rev-parse --abbrev-ref HEAD
!git status --short
!git ls-files ':(top,icase).github/pull_request_template.md' ':(top,icase).github/pull_request_template/*.md' ':(top,icase)pull_request_template.md'
Create a pull request. Follow this flow:
Gather context: Get the default branch locally via git rev-parse --abbrev-ref origin/HEAD (strip the origin/ prefix); only if that fails (origin/HEAD unset) fall back to gh repo view --json defaultBranchRef -q .defaultBranchRef.name. Then read the commits with full messages via git log <base>..HEAD (bodies included — the commit skill records the why there) plus git diff --stat <base>..HEAD for the file-level shape. Pull the full git diff <base>..HEAD only when the messages and stat don't sufficiently explain the changes (thin or missing commit bodies) — for large PRs this avoids reading the whole diff needlessly.
Uncommitted changes: Don't block. Create the PR from the commits that already exist and note in your reply that any uncommitted changes were left out. Only stop if there are no commits ahead of the base branch — there is then nothing to open a PR from.
PR template:
Read it before writing title/body.template_language from headings/instructions/checklists (ignore code, URLs, HTML comments).<!-- -->).Compose PR:
template_language first whenever it can be detected.template_language is detected, use: explicit user request > latest substantive user message > English./create-pr), code blocks, file paths, and URLs when inferring language.type(scope) tokens standard (feat, fix, etc.); localize only the description text.https://claude.ai/code/…) to the PR body.Push and create: Do not ask the user to confirm the title/body — create directly. Push before creating:
git rev-parse --abbrev-ref --symbolic-full-name @{upstream}.git push -u origin HEAD.git log @{upstream}..HEAD shows unpushed commits.Then create the PR, passing the body via a quoted heredoc into --body-file - (stdin) so backticks, $, and quotes in the body stay literal — no escaping, no temp file, and no $() subshell:
gh pr create --title "<title>" --body-file - <<'PR_BODY_EOF'
<body>
PR_BODY_EOF
Keep the title free of backticks — GitHub renders PR titles as plain text, so backticks would appear literally and would trigger shell command substitution inside the double quotes; escape any $ or " if the title contains them. Return the PR URL.
Scaffold a new project in the current directory — git init, README.md, CLAUDE.md, AGENTS.md, Claude settings.json, linter/test config, unused-code detection (knip for TypeScript), runtime pin, lockfile (npm for TypeScript, uv for Python), supply-chain hardening (SHA-pinned GitHub Actions, least-privilege GITHUB_TOKEN, Dependabot cooldown, pinned container base images), and CI (GitHub Actions + Dependabot) for the specified language (TypeScript, Go, Python), plus optional Next.js boilerplate with error boundaries, security headers, SEO, and a health endpoint. Use this skill when the user wants to initialize or bootstrap a new project from scratch, set up a fresh repo, or scaffold project boilerplate.
Stage and commit changes with conventional commits
A relentless interview to think a topic through before committing — software requirements or any general question (a decision, a concept, a plan, research). Act as a critical thinking partner: surface the real intent, challenge assumptions, weigh alternatives, name what stays uncertain. One question at a time, each with a recommended answer. Always end by writing a document capturing what was decided and what is open. Use proactively whenever the user wants to think something through, define requirements, or clear up ambiguity — triggered by "要件定義したい", "深掘りしたい", "壁打ちしたい", "一緒に考えて", "help me think this through", "grill me", or the `/deep-dive` command.
Help the reviewer understand a GitHub pull request through dialogue. Start with a short orientation to the PR's purpose and approach, then answer their questions and dig into the real code interactively so their understanding deepens. Only once understanding is solid — and only when the reviewer asks — organize their own conclusions into review notes they send themselves. Facilitator: never produce ok/ng verdicts or review comments on your own. Triggered by requests like "PRをレビューしたい", "PRを理解したい", "このPRを見たい", "help me review this PR", or the `/review-support` command.
テストコードのレビューを行う。公開契約（入出力・エラー契約・副作用保証）を起点に、テストが振る舞いの仕様として機能しているかを評価し、改善点を優先度付きで報告する。「テストをレビューして」「テストのレビューをお願い」「test review」「review the tests」などテストそのもののレビューを依頼された時、または /review-test コマンドで起動する。
Update an existing GitHub pull request after adding commits by revising title/body, preserving template format, and pushing pending branch changes.