mcpField
P
pr-branch-naming

pr-branch-naming

github.com/thedesignproject開発97143 回インストール9 週間前に更新
リポジトリ

pr-branch-naming について

pr-branch-namingは、変更内容から規約に沿ったブランチ名と対応するPRタイトルを作る開発スキルです。明示的な確認と事前条件の検査を経て、ブランチのチェックアウトやドラフトPR作成も支援します。

主な機能

  1. 01変更タイプとスコープの選定
  2. 02規約に沿ったブランチ名の生成
  3. 03対応するPRタイトルの生成
  4. 04任意のチェックアウトとドラフトPR作成
  5. 05GitとGitHub CLIの事前条件確認

活用シーン

  1. 01説明された機能や修正のブランチ命名
  2. 02対応するPRタイトルの準備
  3. 03操作前のブランチと認証状態の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/thedesignproject/agent-skills --skill pr-branch-naming

インストール後、Claude Code で/pr-branch-namingを入力して読み込まれたか確認します。

詳細

PR とブランチの命名

機能の説明から、規約に沿ったブランチ名と対応する PR タイトルを生成します。その後、ブランチのチェックアウトや PR の作成を任意で行います。ただし、ユーザーが明示的に確認した場合に限ります。

ステップ 1：機能の説明を取得する

ユーザーの入力は $ARGUMENTS にあります。次のいずれかです。

  1. 説明がある — そのまま使用します
  2. 空である — git status と直近のコミット（git log -n 5 --oneline）から作業内容を推測します。推測できた場合は、確認のためユーザーに提示します。推測できない場合は、次のように尋ねます。「このブランチの対象となる機能や変更は何ですか？」

説明をでっち上げてはいけません。手がかりがない場合は、尋ねてください。

ステップ 2：タイプとスコープを選ぶ

タイプ（いずれか 1 つ）
タイプ用途
feat新機能または新しい UI の作業
fix既存機能のバグ修正
docsドキュメントのみの変更
refactor動作を変更しないコードの再構成
perfパフォーマンスの改善
choreツール、設定、依存関係の更新
experimentalそのままリリースすることを意図しないプロトタイプ、スパイク、または探索的な作業

説明に最も合うタイプを選びます。デザイナーが作成した作業でよく使われるタイプは feat と experimental です。

スコープ

影響を受ける製品の領域を表します。短く、小文字で、可能であれば 1 語にします。例：playground、dashboard、auth、onboarding、billing。

説明からスコープを推測します。本当に曖昧な場合に限り、1 回だけ尋ねます。「製品のどの部分に関わる変更ですか？ dashboard、auth などですか？」 ユーザーに何度も質問しないでください。

ステップ 3：ブランチのプレフィックスを選ぶ

プレフィックス用途
feature/新機能または UI の作業（feat に対応）
bugfix/既存機能の修正（fix に対応）
hotfix/緊急の本番環境向け修正
docs/ドキュメントの変更（docs に対応）
experimental/プロトタイプや探索的な作業（experimental に対応）

プレフィックスはタイプと一致させます。feat には feature/、fix には bugfix/ を使うなど、対応するものを使用してください。

ステップ 4：名前を生成する

ブランチ名

形式：<prefix>/<kebab-description>

ルール：

  • 小文字のみ
  • 単語はハイフンで区切る（アンダースコアとスペースは使わない）
  • 末尾にハイフンを付けない
  • 簡潔にする — 説明部分は 3～6 語を目安にする
  • 冗長な語（the、a、for、to、make）は省く

例： feature/patient-based-messaging

PR タイトル

形式：<type>(<scope>): <short description>

ルール：

  • 説明は平易な言葉で、文頭のみ大文字にし、末尾にピリオドを付けない
  • 簡潔にする — 1 行に収める
  • ブランチの内容を反映しつつ、人間のレビュー担当者にとって自然な表現にする

例： feat(playground): v1 prototype — patient-based messaging flow

ステップ 5：結果を提示する

次の形式で、両方の名前と 1 行の理由を提示します。

Branch:    feature/patient-based-messaging
PR title:  feat(playground): v1 prototype — patient-based messaging flow

Type: feat (new UI work) · Scope: playground · Prefix: feature/

ステップ 6：適用するかどうかを確認する

ユーザーに次のどれを行うか尋ねます。

  1. ブランチをチェックアウトする — git checkout -b <branch> を実行
  2. ドラフト PR を作成する — gh pr create --draft --title "<title>" --body "<one-line description>" を実行
  3. 両方
  4. どちらもしない — ユーザー自身で名前をコピーする

いずれかのコマンドを実行する前に、前提条件を確認します。満たされない場合は、明確なメッセージを伝えて停止してください。

  • git checkout -b の場合： まず git status を実行します。作業ツリーに変更がある場合は、その状況を伝え、続行するか、スタッシュするか、中止するかを尋ねます。同じ名前のブランチがすでに存在する場合は、数字のサフィックス（-2）を付けるよう提案します。
  • gh pr create の場合： まず gh auth status を実行します。認証されていない場合は、ユーザーに gh auth login を実行するよう伝え、停止します。ベースブランチより先にコミットがないブランチから PR を作成してはいけません — git log <base>..HEAD --oneline で確認し、空の場合は警告します。

このスキルの一環として、破壊的な git 操作（reset --hard、branch -D、push --force）を実行してはいけません。

注意事項

  • このスキルを実行したとき、ユーザーがすでにデフォルト以外のブランチにいる場合は、新しいブランチを main／master から切るか、現在のブランチから切るかを確認してください。
  • 複数の変更（例：「ログインのバグを修正して、新しいダッシュボードウィジェットを追加する」）が説明されている場合は、1つにまとめるのではなく、ブランチとPRを2つに分けることを提案してください。
  • PRタイトルの説明には、例のように補足を加えるために em ダッシュ（—）を使えます。使いすぎないでください。

コメント

Markdown 対応