Menu
Create a GitHub pull request using gh CLI, following the repository's own PR template and language conventions
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 using gh CLI, following the repository's own PR template and language conventions |
| disable-model-invocation | true |
gh CLI を使ってプルリクエストを作成する汎用スキル。言語・セクション構成・セクション見出し・特殊コメント（Copilot 指示など）は、すべてリポジトリ側の PR テンプレートと慣習に従う。スキル自身は書き方を固定しない。
PR 作成の前に以下を確認する。
PR テンプレートの実在と中身:
cat .github/pull_request_template.md 2>/dev/null || \
cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || \
ls .github/PULL_REQUEST_TEMPLATE/ 2>/dev/null
テンプレートがあるなら、そのセクション構成・見出しをそのまま使う。コメント (<!-- ... -->) の指示も保持する。
テンプレートがないなら、gh pr list --state all --limit 5 --json title,body で直近の PR を見て慣習的なフォーマットを推定する。
どちらも見つからなければ下記の最小構成で作る:
## Summary
<!-- この PR で何を変えたかを 1〜3 文で -->
## Test Plan
- [ ] <確認した動作 1>
- [ ] <確認した動作 2>
これを既定とし、リポジトリの特性に応じて ## Notes や ## Screenshots を追加してよい。
言語の選択（以下の優先順）:
CLAUDE.md / AGENTS.md / CONTRIBUTING.md に言語指定があれば従うtype(scope): プレフィックスは英語のまま残してよい（例: fix(auth): ログインリダイレクトを修正）。ブランチ・コミット・差分の把握:
git branch --show-current
git log <base>..HEAD --oneline
git diff <base>...HEAD --stat
<base> は通常 main（gh repo view --json defaultBranchRef --jq .defaultBranchRef.name で確認可能）。
ブランチを push（upstream 未設定の場合）:
git push -u origin <branch>
PR 本文を用意:
cp .github/pull_request_template.md /tmp/pr-body.md してから編集する。cp は最初の 1 回のみ。/tmp/pr-body.md を編集後に上書きしないこと。PR 作成:
gh pr create --draft \
--title "type(scope): 簡潔なタイトル" \
--body-file /tmp/pr-body.md \
--base <base>
--body でもよいが、改行・コードブロックを含むならファイル経由が安全。--draft) で作成する。完成したら gh pr ready <N> で切り替える。確認:
gh pr view <N> --json title,body,isDraft,url
type(scope): subject) を既定とする。絵文字なし。type: feat / fix / docs / chore / refactor / style / test / perf / build / citype(scope): は英語のまま。テンプレ内 HTML コメントは次の 2 種に分けて扱う。
Type 1: bot 制御コメント（絶対に削除・改変しない）
bot やレビュアーへの指示、自動補完用マーカー、保持指示が書かれているもの。例:
<!-- GitHub Copilot コードレビューへの指示: ... --> — Copilot へのレビュー指示<!-- pr_agent:summary --> / <!-- pr_agent:walkthrough --> — pr_agent の自動補完マーカー<!-- copilot:summary --> — Copilot 自動補完マーカー<!-- Please do NOT remove this template. --> — 明示的な保持指示<!-- Dependabot ... --> — bot 用設定これらがセクション内の唯一の内容である場合、コメントだけ残して人間は書き足さない（上の「全セクションを埋める」はこの種のコメントで既に埋まっていると判断してよい）。
Type 2: 自由記述ガイドコメント（人間が記述したら削除してよい）
セクションの書き方を読み手に教えるためのガイド文。例:
<!-- なぜを端的に説明してください --><!-- 何を見てほしくてレビュー依頼しているか --><!-- Briefly explain what changed and why. --><!-- How was this verified? -->これらは人間が本文を書いたら削除する。残すと PR 表示で本文の上下に冗長なコメントが並んで読みにくくなる（HTML コメントは GitHub UI 上では非表示だが、PR 編集画面・差分には残る）。
判別基準: bot 名や保持指示が含まれていれば Type 1、書き方の説明・例示・問いかけのみなら Type 2。迷ったら Type 1 として保持する（誤削除より誤保持のほうが安全）。
gh pr list --author "@me" # 自分が開いた PR
gh pr status # 現ブランチに紐づく PR 状態
gh pr view <N> # PR の詳細
gh pr view <N> --json title,body # タイトル・本文を JSON で取得
gh pr edit <N> --title "..." --body-file ... # 後から編集
gh pr edit <N> --add-reviewer user1,user2 # レビュアー追加
gh pr ready <N> # Draft → Ready
gh pr checks <N> # チェック状況
gh pr merge <N> --squash # マージ (必要なら --auto)
cat してから埋める。<!-- Copilot ... --> を含むコメントは bot 制御なので保持する。--body でヒアドキュメント・改行を直接渡す → シェルエスケープで壊れることがある。複雑な本文は --body-file で。--draft。Generic thinking protocol for deriving optimal solutions through iterative self-checking. Invoke BEFORE searching within the given problem space whenever the user asks for advice, judgment, evaluation, or choice. Reframes the problem, generates options, evaluates trade-offs, runs a self-answer check (does this answer the user's actual question at the right granularity, reach upstream, match expectations, offer non-obvious value?), and loops back to upstream tracing or same-level reframing if the check fails — until convergence. Applies across any domain — technical, process, organizational, decision-making, career. Triggers when the user uses evaluation or reconsideration language ("which is best", "root cause", "is this really needed", "sustainable long-term", "ほんとうに", "そもそも", "最善は", "根本は", "筋が良い"), when validating the soundness of someone's proposal from multiple perspectives, when the problem spans multiple layers (tech / process / org / regulation / UX / cost), or when clear trade-offs exist.
Review the local diff with flat-perspective sub-agents, fix findings in a loop, then create a PR via the create-pr skill once the review is clean
計画や設計について、ユーザーを徹底的に問い詰めて一緒に詰める。実装・着手の前に計画をストレステストしたいとき、または「詰めて」「グリルして」「問い詰めて」「ツッコんで」「設計レビューして」「ほんとうにこれでいい?」などのトリガー表現が出たときに必ず使う。
.claude/rules/ 配下のルールファイル (*.md) を新規作成・編集するときに、適切なメカニズム選択と paths スコープを保証する。ルールを書く前・書いた後に必ず適用する。
Orchestrate Epic issue as team leader. Delegate sub-issues to member agents in isolated worktrees. Members run in background and communicate via SendMessage.
Fetch a GitHub issue with its sub-issues, walk up to the parent Epic, list sibling issues under that Epic, fetch the body of each sibling issue, attach the implementing PR for each closed sibling with body and diff summary, gather related code, and present as a Japanese summary so the reader can grasp the whole task context including the actual contents of siblings and their PRs