メニュー
Update an existing GitHub pull request after adding commits by revising title/body, preserving template format, and pushing pending branch changes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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
Create a GitHub pull request with context-aware description
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 コマンドで起動する。
| name | update-pr |
| description | Update an existing GitHub pull request after adding commits by revising title/body, preserving template format, and pushing pending branch changes. |
| 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 view *), Bash(gh pr edit *), 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'
Update the existing pull request for the current branch. 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) — the commits added since the last PR revision are the main material for the update, so focus there.
Missing PR check: Run gh pr view --json number,url,title,body,baseRefName,headRefName,isDraft. If it fails, there is nothing to update — report that no open PR exists for this branch and that /create-pr would create one, then stop. (This is a terminal condition, not a blocking question.)
Uncommitted changes: Don't block. Update the PR from the pushed/committed state and note in your reply that any uncommitted changes were left out.
PR template:
Read it before writing title/body.template_language from headings/instructions/checklists (ignore code, URLs, HTML comments).<!-- -->).Compose updated PR content:
template_language first whenever it can be detected.template_language is detected, use: explicit user request > latest substantive user message > English./update-pr), code blocks, file paths, and URLs when inferring language.type(scope) tokens standard (feat, fix, etc.); localize only the description text.No approval gate: Do not ask the user to confirm the title/body — proceed directly to push and update (mirrors create-pr, which creates without confirmation). Report the final title/body in your reply after the update lands.
Push and update:
Check for an upstream with git rev-parse --abbrev-ref --symbolic-full-name @{upstream}.
If it fails (no upstream), push unconditionally with git push -u origin HEAD.
If an upstream exists, push only when git log @{upstream}..HEAD shows unpushed commits.
Update 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 edit --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.