finishing-a-development-branch

開発ブランチの完了

概要

明確な選択肢を提示し、選ばれたワークフローを実行して、開発作業の完了を支援します。

基本原則： テストを検証 → 選択肢を提示 → 選択された内容を実行 → クリーンアップ。

開始時に伝える内容： 「この作業を完了するために、finishing-a-development-branch スキルを使用します。」

プロセス

ステップ 1：テストを検証する

選択肢を提示する前に、テストが成功することを検証します：

# Run project's test suite
npm test / cargo test / pytest / go test ./...

テストが失敗した場合：

Tests failing (<N> failures). Must fix before completing:

[Show failures]

Cannot proceed with merge/PR until tests pass.

停止します。ステップ 2 に進まないでください。

テストが成功した場合： ステップ 2 に進みます。

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

# Try common base branches
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null

または、次のように尋ねます：「このブランチは main から分岐しました。これで正しいですか？」

ステップ 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?

説明を追加しないでください — 選択肢は簡潔に保ちます。

ステップ 4：選択された内容を実行する

選択肢 1：ローカルでマージする

# Switch to base branch
git checkout <base-branch>

# Pull latest
git pull

# Merge feature branch
git merge <feature-branch>

# Verify tests on merged result
<test command>

# If tests pass
git branch -d <feature-branch>

次に：作業ツリーをクリーンアップします（ステップ 5）

選択肢 2：プッシュして PR を作成する

プッシュする前に：

• PR は 1 つの関心事に絞ります。無関係な変更は別の PR に分けるか、積み重ねます。
• 正確なヘッドに対する独立したクロスプロバイダーのレビューを受けます（requesting-code-review を参照）。
• まずローカルでチェックを実行します。ブランチの準備ができたら 1 回だけプッシュし、ホストされた CI が 1 回だけ実行されるようにします。

# Push branch
git push -u origin <feature-branch>

# Create PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
<2-3 bullets of what changed>

## Test Plan
- [ ] <verification steps>

Refs #<issue>
EOF
)"

リポジトリがマージ後にデプロイされる場合は Refs #n を使用し、ライブ環境で確認した後にのみイシューをクローズします。マージ自体によって変更がライブ環境に反映される場合に限り、クローズキーワードを使用します。積み重ねられた PR の場合は、親 PR、ベースブランチ、積み重ね内での位置を明記します。

マージは別の判断です。オーナーからその PR に対する明示的な承認を得ずに、PR をマージしないでください。

次に：作業ツリーをクリーンアップします（ステップ 5）

選択肢 3：現状のまま保持する

次のように報告します：「ブランチ を保持します。作業ツリーは に残します。」

作業ツリーをクリーンアップしないでください。

選択肢 4：破棄する

まず確認します：

This will permanently delete:
- Branch <name>
- All commits: <commit-list>
- Worktree at <path>

Type 'discard' to confirm.

正確な確認を待ちます。

確認された場合：

git checkout <base-branch>
git branch -D <feature-branch>

次に：作業ツリーをクリーンアップします（ステップ 5）

ステップ 5：作業ツリーをクリーンアップする

選択肢 1、2、4 の場合：

作業ツリー内にいるか確認します：

git worktree list | grep $(git branch --show-current)

該当する場合：

git worktree remove <worktree-path>

選択肢 3 の場合： 作業ツリーを保持します。

クイックリファレンス

選択肢	マージ	プッシュ	作業ツリーを保持	ブランチをクリーンアップ
1. ローカルでマージ	✓	-	-	✓
2. PR を作成	-	✓	✓	-
3. 現状のまま保持	-	-	✓	-
4. 破棄	-	-	-	✓（強制）

よくある間違い

テスト検証を省略する

• 問題： 壊れたコードをマージしたり、失敗する PR を作成したりする
• 対処： 選択肢を提示する前に、必ずテストを検証します

自由回答式の質問

• 問題： 「次に何をすればよいですか？」→ 曖昧
• 対処： 構成された選択肢を 4 つだけ提示します

作業ツリーの自動クリーンアップ

• 問題： 必要になる可能性がある作業ツリーを削除する（選択肢 2、3）
• 対処： 選択肢 1 と 4 の場合にのみクリーンアップします

破棄の確認がない

• 問題： 作業を誤って削除する
• 対処： 入力による「discard」の確認を必須にします

注意すべき兆候

決して行わないこと：

• テストが失敗したまま進める
• 結果に対するテストを検証せずにマージする
• 確認を得ずに作業を削除する
• 明示的な依頼なしに強制プッシュする
• デプロイの手順が残っているのに、「マージ済み」を「ライブ環境に反映済み」とみなす

必ず行うこと：

• 選択肢を提示する前にテストを検証する
• 選択肢を 4 つだけ提示する
• 選択肢 4 では入力による確認を得る
• 選択肢 1 と 4 の場合にのみ作業ツリーをクリーンアップする

連携

次から呼び出されます：

• subagent-driven-development（ステップ 7）— すべてのタスク完了後
• executing-plans（ステップ 5）— すべてのバッチ完了後

連携するスキル：

• using-git-worktrees — このスキルで作成された作業ツリーをクリーンアップします

参考ファイル

クレームの解放、積み重ねられたプルリクエストの処理、またはマージ後のクリーンアップを行う場合は、クレームとクリーンアップ を読みます。