O

finishing-a-development-branch

作成者 obra

実装が完了しテストが通った後の Git 開発ブランチをきれいに終わらせるための構造化ワークフローを提供し、ローカルマージ、push と PR、ブランチを残す/破棄する、といった選択をガイドします。

スター0
お気に入り0
コメント0
追加日2026年3月27日
カテゴリーGit Workflows
インストールコマンド
npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch
概要

概要

このスキルでできること

finishing-a-development-branch スキルは、実装が完了しテストスイートが通った Git の開発ブランチを、安全かつ確実に終わらせるためのサポートを行います。ローカルでマージするか、push して Pull Request を開くか、そのままブランチを残しておくか、完全に破棄するかを、分かりやすく再現性のあるワークフローで順番に案内します。

このスキルの核となる考え方はとてもシンプルです。

テスト確認 → ベースブランチの特定 → 選択肢の提示 → 選択の実行 → 後片付け

その場しのぎの Git コマンドや、うっかり重要な確認を飛ばしてしまう代わりに、finishing-a-development-branch は機能ブランチやバグ修正ブランチの「締め」のための一貫したチェックリストをエージェントに提供します。

finishing-a-development-branch は誰のためのスキルか

  • Git ブランチで開発しており、「ブランチを終わらせる」定型のフローを整えたい開発者
  • merge や PR 作成の前に、テスト成功が必須になっているチーム
  • エージェントにより安全に Git ワークフローを扱わせたい obra/superpowers スキルセットのユーザー
  • 「このブランチはもう merge して良いのか?どう統合すべきか?」と日常的に悩みがちな人

すでに自動テストが整備されており、mainmaster といった標準的なベースブランチを持つリポジトリに特にフィットします。

このスキルが解決する課題

  • merge や Pull Request 作成前にテストを実行し忘れる
  • 機能ブランチがどのブランチから派生したのか分からなくなる
  • ローカルで merge するか、PR を使うか、作業を破棄するかの判断が毎回バラバラ
  • いつまでも処理されないブランチがリポジトリに溜まり、整理されない

テストを先に必ず通すという前提のもとで、明示的な少数の選択肢だけを提示することで、finishing-a-development-branch はミスを減らし、Git ワークフローを予測しやすくします。

このスキルが適している場面

finishing-a-development-branch は次のような状況で使うと効果的です。

  • 機能追加や修正がひととおり実装し終わっている
  • すべてのテストが通る想定であり、テスト失敗時には統合をブロックしたい
  • このブランチをどう統合するか(merge/PR/保持/破棄)をそろそろ決めたい

逆に、次のようなケースでは 向いていません

  • まだブランチ上で積極的にコーディングや試行錯誤をしている
  • 実行可能なテストが存在せず、意味のあるテストスイートを走らせられない
  • シンプルな「機能ブランチ → ベースブランチ」以上に複雑な、マルチブランチのリリース管理が必要

主にコードの執筆やレビューに助けが欲しい場合は、実装やコードレビューに特化した別スキルと組み合わせて使うことを検討してください。finishing-a-development-branch は、あくまで最終的な統合ステップに焦点を当てています。

使い方

インストールとセットアップ

1. スキルをインストールする

Skills CLI を使って、obra/superpowers リポジトリから finishing-a-development-branch をインストールします。

npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch

これでスキルがエージェント環境で利用可能になり、現在のリポジトリに対してガイド付きの Git ワークフローを適用できるようになります。

2. リポジトリの前提条件を確認する

スキルを意図通り動作させるには、プロジェクトが次の条件を満たしている必要があります。

  • Git リポジトリであり、mainmaster など明確なベースブランチがあること
  • 実行可能なテストスイートがあること(たとえば次のようなコマンドで実行できる):
    • npm test
    • cargo test
    • pytest
    • go test ./...

具体的なコマンドはスタックに依存しますが、統合前に実行可能な 何らかの テストコマンドが存在することが前提です。

3. スキルを使うことを宣言する

仕上げプロセスを開始するときは、あなた(またはエージェント)が明示的に次のように宣言することを、このスキルは想定しています。

"I'm using the finishing-a-development-branch skill to complete this work."

これによって、ワークフローがチームメンバーにとって透明になり、構造化されたプロセスが適用されていることを共有できます。

ガイド付きワークフローのステップ

ステップ 1: テストを確認する

統合方針を決める前に、スキルはプロジェクトのテストスイートを実行するか、実行するよう促します。典型的なコマンドは以下のとおりです。

npm test
# or
cargo test
# or
pytest
# or
go test ./...
  • テストが失敗した場合: スキルは失敗件数と内容を報告し、その時点で処理を停止します。テストが通るまでは、merge や PR 作成に進まないことを明示します。
  • テストが成功した場合: 次のステップへ進みます。

この厳格な「まずテスト」というゲートにより、壊れたコードが merge されたり Pull Request として出てしまうことを防ぎます。

ステップ 2: ベースブランチを特定する

次に、finishing-a-development-branch は、あなたの開発ブランチがどのブランチから派生したかを、次のような Git コマンドを使って特定します。

git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null

ベースブランジを自動で特定できない場合は、次のような確認質問にフォールバックします。

"This branch split from main - is that correct?"

正しいベースブランチを確認することは重要です。これにより、どのブランチに対して作業内容を merge すべきか、または Pull Request のターゲットをどこにするかが決まります。

ステップ 3: 統合の選択肢を提示する

テストが通り、ベースブランチが分かったら、スキルは次の 4 つのシンプルな選択肢を提示します。

Implementation complete. What would you like to do?

1. Merge back to <base-branch> locally
2. Push and create a Pull Request
3. Keep the branch as-is (I'll handle it later)
4. Discard this work

Which option?

選択肢はあえて短くストレートにまとめられており、余計な説明なしで素早く選べるようになっています。

代表的な使い分け:

  • Option 1 – 小規模な個人プロジェクトや、メンテナが自分だけのときなど、素早くローカルで merge したい場合。
  • Option 2 – チーム開発で、コードレビューや CI、承認フローを GitHub などのホスティングサービス上で回したい場合。
  • Option 3 – まだ統合方法を決めたくないが、テストは通っていてブランチの状態を確認しておきたい場合。
  • Option 4 – 試験的なブランチだった、あるいはアプローチが不要になったため、ブランチをきれいに削除したい場合。

ステップ 4: 選択したオプションを実行する

あなたの選択に応じて、スキルは対応する Git 操作と、必要な後片付けを実行します。SKILL.md では一部の詳細コマンドが省略されていますが、意図としては次のような動きです。

  • ローカル merge の場合: ベースブランチにチェックアウトし、開発ブランチを merge し、必要に応じて完了したブランチを削除します。
  • push + PR の場合: ブランチをリモートに push し、特定したベースブランチに向けた Pull Request を作成するよう案内します。
  • keep as-is の場合: 現在のブランチはそのままにし、統合は後であなたが行うことを明確にします。
  • discard の場合: 本当に不要であることを確認した上で、ブランチを安全に破棄・削除します。

このステップ全体を通じて、スキルは予測可能性と安全性を重視します。テストが失敗したまま merge しない、誤ったベースブランチに merge しない、作業内容を誤って失うことを避ける、といった点です。

実践的な使いこなしのヒント

自分の開発フローに組み込む

  • 「機能ができた」と思ったタイミングで finishing-a-development-branch を実行しましょう。
  • テストゲートを、merge と PR のどちらに進むかを決める最終品質チェックとして使います。
  • チーム開発では、基本的に Option 2 を選んでレビューや CI パイプラインを確実に回す運用にすると良いでしょう。

チームのルールと組み合わせる

チームに特定のブランチ運用・レビュー方針(例: 必ずまず develop に PR を出す、ブランチは自動削除しない、など)がある場合は、そのルールに合わせてオプションの使い方を調整してください。スキルの枠組みがあることで、こうしたポリシーもブレずに運用しやすくなります。

他の superpowers スキルとの併用

obra/superpowers スイートの中で、finishing-a-development-branch は実装・リファクタリング・テスト支援系のスキルと補完し合うよう設計されています。そうしたスキルでブランチ上の変更を進め、統合の準備が整った段階でこのスキルを呼び出す、という使い方が効果的です。

FAQ

finishing-a-development-branch スキルはいつ実行すればよいですか?

変更の実装が終わり、テストが通る見込みがあり、このブランチをどう統合するか(merge/PR/保持/破棄)を決める準備ができたタイミングで finishing-a-development-branch を実行してください。ブランチのライフサイクルにおける「最後のステップ」として使うものであり、日々の細かな開発作業を支援するためのツールではありません。

テストが失敗した場合はどうなりますか?

テストが失敗した場合、スキルは失敗内容を報告し、その時点で処理を停止します。merge や Pull Request の作成には進みません。ブランチ上で失敗しているテストを修正し、再度テストを実行してから、あらためて finishing-a-development-branch を呼び出すことを想定しています。

自動テストがないプロジェクトでも使えますか?

このスキルは「まずテストで確認する」という前提で設計されています。テストのないプロジェクトにも概念的には流用できますが、その場合、最も重要な安全装置のひとつを無効化することになります。npm testcargo testpytestgo test ./... などのコマンドを実行できるリポジトリで使うのが理想的です。

どのブランチに merge するかはどのように決まりますか?

finishing-a-development-branch は、Git の merge-base を使い、mainmaster など一般的なブランチ名に対してベースブランチを推定します。それでも曖昧な場合は、どのブランチをベースとすべきかをあなたに確認します。これにより、merge や Pull Request が常に正しいターゲットブランチに向かうようにします。

Pull Request は自動で作成されますか?

このスキルの仕様上、Option 2 を選んだ場合は「push して Pull Request を作成する」動作が想定されています。具体的な挙動は、あなたのエージェント環境と Git ホスティングプラットフォームとの連携状況によって異なりますが、少なくともブランチを push し、検出したベースブランチに向けた PR を開くよう案内します。

ブランチは自動で削除されますか?

SKILL の説明では、選択肢の提示と、それに応じたワークフロー(後片付けを含む)の実行に焦点が当てられています。具体的にいつブランチを削除するかは、環境側のクリーンアップ処理の解釈に依存する場合があります。Option 4(discard this work)は破壊的な操作になり得るので、本当にそのブランチが不要だと確信できる場合にのみ選択してください。

finishing-a-development-branch は複雑なリリースフローにも向いていますか?

このスキルは、単一のベースブランチに merge していくシンプルな機能ブランチ/修正ブランチを対象としています。複数の長期運用ブランチやホットフィックスフロー、入り組んだデプロイパイプラインを運用している場合でも、ブランチ単位では finishing-a-development-branch を活用できますが、より広いリリース戦略については、別途プロセスやツールを組み合わせる必要があるかもしれません。

finishing-a-development-branch のインストール方法をもう一度教えてください

obra/superpowers リポジトリを指定して Skills CLI を実行します。

npx skills add https://github.com/obra/superpowers --skill finishing-a-development-branch

インストール後は、このスキルのワークフローに従って、テストを実行し、ベースブランチを確認し、オプションを選択し、統合とクリーンアップをスキルに任せてください。

評価とレビュー

まだ評価がありません
レビューを投稿
このスキルの評価やコメントを投稿するにはサインインしてください。
G
0/10000
新着レビュー
保存中...