# Pr

> Only use when the user explicitly invokes /pr (or $pr in Codex). Never auto-invoke. フィーチャーブランチの作成からステージング・コミット・push・Pull Request 作成までの一連の Git 操作を、ブランチ運用ルール（develop 優先・保護ブランチへの直接コミット禁止）を遵守しながら安全に実行する。

- Skill: `efoo-team/pr` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add efoo-team/pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/efoo-team/pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: efoo-team (https://skillmd.com/u/efoo-team)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/efoo-team/pr

---


# Feature Branch Deploy（pr）

フィーチャーブランチの作成から Pull Request 作成までの一連の Git 操作を、AI が誤操作しないことを最優先に実行するスキル。

## 明示起動限定

このスキルはブランチ作成・push・PR 作成という不可逆かつ外部（リモート・GitHub）に影響する副作用を実行する。ユーザーが明示的に `/pr`（Codex では `$pr`）を起動した場合のみ実行する。会話の流れから自動発動してはならない。

## 重要事項（ブランチ運用の絶対ルール）

理由: develop が存在するリポジトリでは develop が統合ブランチであり、main / master へ直接向けるとレビュー・リリース手順を飛ばした変更が本番系に到達しうるため。

- `develop` が存在する場合、PR のマージ先は必ず `develop`。存在しない場合のみ `main` または `master` を使用
- `develop` / `main` / `master` への直接コミットは禁止。コミットは必ず作成したフィーチャーブランチで行う
- 違反する状態（例: develop があるのに `base=main` が指定されている）を検出した場合は、処理を続行せず即時停止してユーザーに確認する

## 前提: プロジェクト規約への準拠

実行前に、リポジトリの規約ファイル（`CLAUDE.md` / `AGENTS.md` 等）を必ず確認する。記載されたブランチ運用ルール・使用言語・報告規則・ツール利用方針を遵守し、本スキルの指示と矛盾する場合は規約ファイルを優先する。規約ファイルにベースブランチの言及や運用ルールがなく判断できない場合は、直ちに操作を中止し、ユーザーに確認を求める義務を負う。

## 追加指示・引数の扱い

`argument-hint` の引数（`[branch-name] [commit-title] [base-branch]`）または追加指示がある場合は、本スキル内の自動判定より優先して適用する。ただし「重要事項」に反する指定は受け付けず、直ちに停止して確認を求める。引数が空の場合は下記の自動判定ルールで標準フローを進める。

## 実行フロー

1. **ベースブランチの決定**
   - `develop` → `main` → `master` の順で存在を確認
   - develop が存在する場合、必ず develop を使用

2. **ベースブランチへ切り替え・最新化**

   ```bash
   git checkout <base-branch>
   git pull origin <base-branch>
   ```

3. **フィーチャーブランチの作成**

   ```bash
   git checkout -b <feature-branch>
   ```

4. **変更確認とステージング**

   ```bash
   git status
   # 重要: 関係のない変更が含まれていないか必ず確認する
   # git add . より git add <specific-files> の個別ファイル指定を強く推奨
   git add <specific-files>
   ```

5. **コミット**

   comprehensive（包括的）なコミットメッセージを書く。1 行タイトルだけでなく本文（body）を含め、Why → What → How の文脈を含める。ただし固定テンプレートにはせず、シニアエンジニアが書く洗練されたコミットとして、状況に応じて最適な構成・表現を選ぶ。将来のリリースノート生成に貢献する品質を目指す。

   ```bash
   git commit -m "$(cat <<'EOF'
   <commit-title>

   <comprehensiveな本文>
   EOF
   )"
   ```

### 副作用実行前の確認（push / PR 作成の直前・必須）

push と PR 作成はリモートおよび GitHub に影響する不可逆操作である。実行の直前に、必ず以下をすべて確認する。

- 現在のブランチがフィーチャーブランチであり、`develop` / `main` / `master` でないこと
- ベースブランチが「重要事項」のルールに適合していること（develop があれば必ず develop）
- ステージ・コミット内容に無関係な差分が含まれていないこと
- 規約ファイル（CLAUDE.md / AGENTS.md 等）のブランチ運用ルールに反していないこと

いずれか 1 つでも満たされない、または規約ファイルにベースブランチの記載がなく判断できない場合は、push / PR を実行せず即時停止してユーザーに確認する。

6. **リモートへプッシュ**

   ```bash
   git push -u origin <feature-branch>
   ```

   push が non-fast-forward で拒否された場合は、`--force` / `-f` を使わずに即時停止する。ユーザーに状況を提示し、`git pull --rebase` でリモートの変更を取り込んでよいか確認を得てから再 push する。

7. **Pull Request 作成**
   - PR のベースブランチは決定済みの `<base-branch>` を必ず使用する
   - 変更内容を要約した説明と Test Plan を含める
   - タイトルと本文は日本語で記述する
   - **必ず HEREDOC 形式を使用すること**（改行が `\n` リテラルになる問題を防ぐため）
   - 作成完了後、PR の URL をユーザーへ報告する

   ```bash
   gh pr create --base <base-branch> --title "PRタイトル" --body "$(cat <<'EOF'
   ここに本文を記述する。
   改行はそのまま反映される。

   ## 背景・課題
   ...
   EOF
   )"
   ```

   **絶対にやってはいけない形式:**

   ```bash
   # NG: 改行が \n リテラルになる
   gh pr create --body "背景・課題\n原因\n対策"
   ```

## PR 文章の作成: pr-body スキルの手順に従う

**PR のタイトルおよび本文の作成は必ず `pr-body` スキルの手順で行う**。自力で文章を組み立ててはならない。`pr-body` は明示起動専用でモデルからスキルとして起動できないため、ファイルを直接 Read する: `~/.agents/skills/pr-body/SKILL.md`（無ければ checkout 側 `~/ghq/github.com/efoo-team/skills/skills/pr-body/SKILL.md`）を読み込み、その実行フローに従って PR 本文を生成する。

その上で、以下の**記載内容の網羅チェック**を必ず行う。目的は、PR 本文の各セクションの中身が中途半端にならないこと（一部だけ記載して他を漏らさないこと）。

1. **同一カテゴリ内の漏れ確認**: 記載するセクションについて、同一カテゴリの全要素が揃っていることを確認する
   - API 変更: 追加・変更・削除されたエンドポイントを全て記載。1 つだけ書いて他を省略しない
   - データ構造: 関連するエンティティ・カラム変更を全て記載
   - フロントエンド変更: 影響を受けたコンポーネントを全て記載
   - 外部連携: 関わる外部サービスを全て記載
2. **削除・廃止の明記**: 何かを削除・廃止した場合、変更概要または該当セクションで必ず言及する。「追加」だけ書いて「削除」を漏らさない
3. **関連事項のセット記載**: 変更に関連する事項はセットで記載する（例: API エンドポイントを追加したなら、それを使うフロントエンド側の変更も記載する）
4. **反復チェック**: ドラフト完成後、各セクションを「このカテゴリで他に漏れている変更はないか」という視点で 2 周確認する

### 全体像の把握（直近ターンへの偏りを防ぐ）

エージェントは直近 1〜2 ターンの作業内容を「対応全体の要約」と誤認しやすい。最後のターンが細かいリファクタだった場合に、PR 全体の目的がリファクタであるかのように書いてしまう失敗が起きる。これを防ぐため、`pr-body` の手順を適用する際は必ず以下を実行する。

- 「直近の作業に説明が偏っている可能性がある。鵜呑みにしない」
- `git diff --stat` と `git diff --name-only` を自身で確認し、変更の全体像を把握する
- 会話の最後のやり取りが対応全体を代表するとは限らない
- セッション中に複数トピックを扱った場合は、どの変更がどの目的に対応するかの対応関係も示す

本ファイル内の従来記述と `pr-body` の出力ルールが矛盾する場合は、`pr-body` を優先する。

## 前提条件

- Git リポジトリであること
- GitHub CLI (`gh`) がインストール・認証済みであること
- 適切なブランチ権限があること

## 自動判定ルール

パラメータが省略された場合の自動判定ロジック。

- **ベースブランチ**: `develop` → `main` → `master` の順で存在確認し、最初に見つかったブランチを使用
- **フィーチャーブランチ名**: 変更内容から簡潔で意味のある名前を作る
- **コミットタイトル**: 変更内容に合わせて `feat:` / `fix:` / `docs:` などのプレフィックスを付与

## 例外と確認

- develop が存在するのに develop 以外をベースに指定された場合は、必ず停止して確認する
- 規約ファイルにベースブランチの記載がない場合は、操作を中止して確認する
- 上記以外は原則として自動判定で進め、ベースブランチ名・フィーチャーブランチ名・コミットタイトルの確認質問は行わない