Create a PR and close linked issues. State-driven routing from uncommitted changes to PR creation.
状態検知からPR作成・Issue連携・レビュー待機・人間へのマージ引き継ぎまでを扱うワークフロー。
標準ルート: implementation -> github-pr-workflow -> 実際のレビューシグナル待ち -> github-pr-review-response -> 人間のマージ判断/引き継ぎ。
Pull Request (PR): GitHub上でレビューする変更提案。
先に状態を検知してください。PRは必ず feature branch から作成してください。複数行本文は --body-file を使ってください。
以下の状況で活用してください：
Closes #N や Refs #N で Issue 連携しながらPRを作成するときgh pr create 前にブランチ状態と認証状態を確認するときスコープ: このスキルは状態検知からPR作成・Issue連携・低消費なレビュー待機への受け渡し、および残PRブランチ向けの確認済みマージ後同期までを扱います。詳細なレビュー対応とマージ判断そのものはスコープ外です。
github-pr-review-response - 実際のレビューシグナル到着後のコメント分類・修正・返信・再レビュー依頼git-commit-practices - コミット形式と原子的コミット（Step 1から委譲）git-initial-setup - ブランチ保護の初期設定github-issue-intake - Issue作成とトリアージgh) — gh auth status で事前確認次の一手をひと目で決めるためのテーブルです。
| 現在の状態 | 次のアクション | 理由 |
|---|---|---|
| main にいる | 先に feature branch を作る | default branch にレビュー前の作業を置かないため |
| 未コミット変更あり | PR前にコミットする | 追跡可能な状態を保つため |
| ローカルコミットのみ | 先に push する | gh pr create にはリモートブランチが必要なため |
| PR未作成 | PRを作成する | レビューフローとIssue連携を開くため |
| PR既存 | 状態を報告して止まる | 重複PRを防ぐため |
自動化がやり過ぎないよう、マージ境界を明示します。
| フェーズ | エージェントの責務 | 人間の責務 |
|---|---|---|
| PR前 | 状態検知、ブランチ作成、検証済み変更の準備 | 提案可能な状態か判断する |
| PR作成 | PR作成、Issue連携、検証根拠の要約 | 誰にレビューを依頼するか、いつ出すか決める |
| レビュー待機 | PR URL を1回記録し、ポーリングを止めて実際のレビューシグナルを待つ | シグナル前に優先順位を変えるか判断する |
| レビュー対応 | レビューシグナル到着時に github-pr-review-response へ委譲する | 返信内容を確認し、承認で十分か判断する |
| マージ判断 | 準備完了状況を要約するだけ | GitHub上でマージするか、いつするか決める |
| マージ後 | マージ確認後にローカル同期を補助する | 実際にマージされたことを確認する |
| 並行PRの後処理 | origin/main を残PRブランチへ取り込み、再検証・再レビュー要否を要約する | マージ順序の判断やプロダクト優先度の見直しを行う |
このスキルが自動化する範囲・しない範囲を説明するときに使います。
Values: ニュートラル / 余白の設計
現在のgit状態を確認し、適切なアクションを取ります。
# 1. 現在のブランチを確認
BRANCH=$(git branch --show-current)
# 2. 未コミットの変更を確認
git status --short
# 3. 未pushのコミットを確認
git log "origin/${BRANCH}..HEAD" --oneline 2>/dev/null
# 4. 既存PRの確認
gh pr list --head "$BRANCH" --state open
# PowerShell版
$Branch = git branch --show-current
git status --short
git log "origin/$Branch..HEAD" --oneline 2>$null
gh pr list --head $Branch --state open
| 状態 | アクション |
|------|-----------|
| mainブランチにいる | feature branch を作成（Step 2） |
| 未コミットの変更あり | git-commit-practices に委譲してコミット後、戻る |
| コミット済・未push | git push -u origin BRANCH してから Step 3 へ |
| push済・PR未作成 | Step 3（PR作成）へ進む |
| PR既存 | PRステータスとURLを報告 |
重要: 未コミットの変更がある場合は
git-commit-practicesワークフローに委譲してください（先にコミット、その後戻る）。mainにいる場合は、コミット前に必ず feature branch を作成してください。
「プルリクして」「PR作成して」等のPR関連リクエスト時に使用します。Why: 状態検知を先に行うと、誤った分岐や重複PR作成を防げます。
Values: 基礎と型 / 継続は力
最新のmainからブランチを作成します。追跡性のためにIssue番号付きの説明的プレフィックス（feature/、fix/、docs/）を使用します。
# ブランチ作成前に認証確認（push失敗を防ぐ）
gh auth status
git switch main
git pull --ff-only
git switch -c feature/issue-123
git push -u origin feature/issue-123
新しい作業を開始するとき、または Step 1 で main にいることが検知された場合に使用します。Why: 先にブランチを切ると、その後のコミット履歴がきれいに保てます。
Values: 基礎と型
日本語の本文でPRを作成します。Closes でマージ時にIssueを自動クローズします。
インライン本文（1行本文のみ）:
gh pr create \
--title "feat: 支払い画面にフィルタを追加" \
--body "注文履歴画面に検索フィルタを追加。Closes #123. Refs #130."
ファイル経由の本文（複数行Markdown・コードフェンス・バッククォートを含む本文の標準既定）:
# 一意な一時ファイルを作り、クォート付きHEREDOCで書き出す
# なぜ: mktemp で衝突を避け、trap で失敗時も確実に削除できる
BODY_FILE="$(mktemp "${TMPDIR:-/tmp}/pr_body.XXXXXX")" || {
echo "PR本文用の一時ファイル作成に失敗しました" >&2
exit 1
}
cleanup() {
[ -n "$BODY_FILE" ] && rm -f "$BODY_FILE"
}
trap cleanup EXIT
cat > "$BODY_FILE" <<'EOF'
## 概要
注文履歴画面に検索フィルタを追加し、本文内の `int(order_id)` 例もそのまま残す。
## 理由
サポートから検索要求が多く、対応工数を削減するため。
## テスト
ローカルで動作確認済み。
## 関連
Closes #123
Refs #130
EOF
gh pr create --title "feat: 支払い画面にフィルタを追加" --body-file "$BODY_FILE"
複数段落の本文、シェル例、バッククォートを含むMarkdownでは、このパターンを既定にしてください。PowerShell/Bash両対応の再利用テンプレは docs/patterns/environment-portability.md（テンプレート2）を参照します。
✅ 良い例: 本文ファイルを生成して確認してから gh pr create --body-file を実行する。
❌ 悪い例: バッククォート入りの複数行Markdownを --body に直接貼り付けてクォート崩れに賭ける。
Why: ファイル経由の方が再現性・レビュー性・シェル安全性が高いからです。
| キーワード | 効果 |
|-----------|------|
| Closes #N | マージ時にIssue #N を自動クローズ |
| Refs #N | Issue #N へのリンク（クローズしない） |
ブランチがpush済みでPRが未作成の場合に使用します。
Values: 成長の複利 / ニュートラル
✅ 良い例: PRを1回作成し、URLを記録して待機モードへ受け渡す。 ❌ 悪い例: 状態変化がないのにPR作成や確認コマンドを何度も繰り返す。 Why: きれいな受け渡しの方が追跡性を保ち、重複作業を防げるからです。
PRを開いたら、能動的なポーリングを止めます。具体的なシグナルが来たときだけ github-pr-review-response へ、シグナルごとに1回だけ受け渡します。
# PR URL を1回だけ記録し、その後はループ確認を止める
gh pr view --json url,updatedAt --jq '{url: .url, updatedAt: .updatedAt}'
# 自然な作業区切りでのみ、まとめて1回確認
gh pr status
| シグナル | 待機継続？ | 次のアクション | 避けること |
|---|---|---|---|
| 新しいレビューが送信された | いいえ | github-pr-review-response を開き、コメントを1回確認 | シグナル前の再確認 |
| 自分に review request が来た | いいえ | github-pr-review-response を開き、コメントを1回確認 | シグナル前の再確認 |
| ユーザーが新規レビュー活動を共有した | いいえ | 1回だけ確認してから github-pr-review-response へ委譲 | シグナル前の再確認 |
| PRは開いているが変化なし | はい | 待機を継続 | 「念のためもう1回」の確認 |
| CI ステータスだけ変わった | 通常ははい | レビュー作業が止まる可能性がある場合だけ1回確認 | CIノイズをレビュー入力扱いすること |
| PRがクローズ/マージ済み | 終了 | 待機を終えて次の確定状態へ進む | レビュー確認を続ける |
待機ルール:
github-pr-review-response で再レビュー依頼を出した後は、新しいレビューシグナルまたは人間の明示的なマージ判断が来るまで、この待機モードへ戻るPR作成後、作業が「作成」から「待機」へ移るときに使います。
Values: 余白の設計 / 継続は力
複数のPRを並行で進めていて、そのうち1本がマージされたら、残っているPRブランチすべてへ最新の origin/main を取り込み、レビュー継続前に差分を揃えます。
# 作業ツリーがクリーンであることを確認し、残PRブランチへ移動
git status --short
git fetch origin
git switch feature/issue-124-followup
# マージ済み main の履歴を取り込む
git merge origin/main
# conflict があれば解消してから再検証
npm test # またはこのリポジトリ相当の検証
npm run lint # またはこのリポジトリ相当の検証
# 同期または conflict 解消コミットを push
git push origin HEAD
並行PRの post-merge チェックリスト:
origin/main を取り込む。✅ 良い例: 同じworkflowや近いファイルを触る sibling PR があるなら、1本マージごとに同期を必須フォローアップとして扱う。 ❌ 悪い例: 残PRを古いまま放置し、次のマージ直前になってから conflict に気づく。 Why: 早期同期の方がレビュー状態を正確に保てて、並行PR間の隠れたドリフトを防げるからです。
並行しているPRのうち1本がマージされ、まだレビュー継続中のブランチが残っているときに使います。
Values: 基礎と型 / 継続は力
feat:, fix: 等）Closes #N で Issue を自動クローズする--body-file を既定にする（Windows では必須寄り）mktemp + trap とクォート付きHEREDOC（<<'EOF'）を使うgh auth status で認証を事前確認するorigin/main と同期してからレビュー継続へ戻すgit fetch origin で最新状態を取得し、次の作業ブランチは必ず最新 origin/main から新規作成するgh pr create 前）main ではない）gh auth status が対象アカウントで成功する.github/workflows/* を変更する場合、トークンに workflow scope があるgh pr list --head BRANCH --state open）skills/**/SKILL.md を変更した場合、PR作成前に uv run python skills/skill/_eval/scripts/validate_skill.py skills/<skill_id>/SKILL.md を実行しているPR本文が英語になる 修正: テンプレ見出しを日本語で統一（概要/理由/テスト/関連）。
Issueリンクの忘れ
修正: ## 関連 セクションに Closes #N を必ず含める。
mainブランチから直接PRを作る 修正: Step 1 の状態検知で feature branch 作成に誘導。
数分おきにレビューを確認し続ける 修正: イベント駆動の待機に切り替え、計画した区切りでのみまとめ確認する。
バッククォートや $() を含む本文が壊れる
修正: クォート付きHEREDOCで本文ファイルを生成し、--body-file で渡す。
兄弟PRがマージされたのに残ブランチを同期しない
修正: 各残PRブランチへ origin/main を取り込み、再検証後に必要なら再レビューを依頼する。
feature branch から別のPRブランチを切る（依存した積み上げPR）
修正: 依存ブランチを増やさず、ベースPRのマージ後に git fetch origin で最新状態を取得し、origin/main から新規ブランチを作る。
Actions実行時に workflow ... not found on the default branch が出る
workflow_dispatch は default branch 上に存在する workflow を対象にする。.github/workflows/* を含む push が権限エラーで拒否される
workflow scope が不足している。gh auth refresh -h github.com -s workflow で再認証する。別PRのマージ後、残PRが conflict 状態になった
git fetch origin 後に対象ブランチへ切り替え、origin/main をマージして conflict を解消し、再検証してから push する。gh auth status で認証を確認git-commit-practices でコミットgh pr create で PR 作成（日本語本文 + Closes #N）github-pr-review-response へ委譲し、修正・返信・再レビュー依頼を行うorigin/main を取り込み、再検証して必要なら再レビュー依頼--body-file を使っている## 概要
（何を変更したか）
## 理由
（なぜこの変更が必要か）
## テスト
（どう検証したか）
## 関連
Closes #N
Q: PR本文は英語でも良い？ A: チームポリシーとして日本語で統一しています。
Q: レビューやマージはこのスキルで扱う？
A: PR作成、シグナル駆動のレビュー待機、残PRブランチ向けの確認済みマージ後同期まで扱います。標準ルートは implementation -> github-pr-workflow -> レビューシグナル待ち -> github-pr-review-response -> 人間のマージ判断/引き継ぎ です。
Q: gh が未インストールの場合は？
A: gh auth status でエラーになります。GitHub CLI をインストールしてください。
npx skills add RyoMurakami1983/github-pr-workflow下载完整 Skill 目录，包含 SKILL.md 及所有相关文件
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer