merge-protocol

マージプロトコル

概要

開発の最終段階を調整します。完成した作業をメインラインに取り込むか、適切に破棄します。

基本原則： まず検証し、選択肢を提示して、選ばれた手順を実行し、その後に後片付けをします。

開始時に宣言： 「この作業を完了するため、merge-protocol スキルを使用します。」

最優先の指示

テストに合格しない限り、統合しないでください

例外なし。回避策なし。近道なし。

使用するタイミング

• 計画した実装作業がすべて完了し、コミット済みである
• 現在のブランチでテストスイートがすべて成功している
• （依頼された場合）レビューのフィードバックに対応済みである
• ブランチを取り込む、保留する、または破棄する準備ができている
• 委任実行またはタスクランナーの完了後
• ワークスペース分離用ブランチを後片付けする必要がある

認知上の落とし穴

合理化	実際
「1 時間前はテストが成功していたから、再実行する必要はない」	それ以降にコミットがあれば、以前の結果は無効です。今すぐ再検証してください。
「マージは機械的な作業だから、問題は起きない」	コンフリクトや統合時のリグレッションは実際に起こります。マージ後の状態をテストしてください。
「ワークツリーの削除は明日でいい」	放置されたワークツリーが積み重なると、混乱の原因になります。すぐに削除してください。
「メニューは省いて、そのままマージしよう」	必ず 4 つすべての手順を提示してください。人間がワークフローを選択します。
「破棄するのは明らかだから、確認はいらない」	作業を永久に破棄するには、明示的な入力による確認が必要です。必ず確認してください。

ワークフロー

フェーズ 1：テストスイートを検証する

何よりも先に、テストスイート全体を実行してください：

# Execute the project's test runner
npm test / cargo test / pytest / go test ./...

失敗した場合：

Suite failures detected (<N> failing). Resolution required before proceeding:

[Display failing tests]

Integration cannot continue until the suite is green.

ここで停止してください。フェーズ 2 に進んではいけません。

成功した場合： フェーズ 2 に進みます。

フェーズ 2：幹ブランチを特定する

# Determine the ancestor branch
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null

または、次のように確認します：「このブランチは main から分岐しています。間違いありませんか？」

フェーズ 3：統合方法を提示する

次の 4 つの選択肢を、そのまま提示してください：

Work is complete and verified. Select an integration path:

1. Merge into <trunk> locally
2. Push and open a Pull Request
3. Leave the branch untouched (I'll handle it myself)
4. Abandon this work entirely

Which path?

簡潔にしてください — 余計な説明は加えません。

フェーズ 4：選択された方法を実行する

方法 1：ローカルマージ

# Switch to trunk
git checkout <trunk>

# Sync with remote
git pull

# Integrate the feature branch
git merge <feature-branch>

# Validate the merged state
<test command>

# Remove the merged branch
git branch -d <feature-branch>

その後：フェーズ 5（ワークツリーの後片付け）に進みます

方法 2：プルリクエスト

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

# Open the PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
<2-3 bullets describing the changes>

## Verification Steps
- [ ] <checklist items>
EOF
)"

その後：フェーズ 5（ワークツリーの後片付け）に進みます

方法 3：保留

次のように報告します：「ブランチ は保持されています。ワークツリーは に残っています。」

ワークツリーを削除してはいけません。

方法 4：破棄

明示的な確認を求めてください：

Permanent deletion warning:
- Branch <name>
- All commits: <commit-list>
- Worktree at <path>

Type 'abandon' to proceed.

指定された文字列と完全に一致する入力を待ちます。

確認後：

git checkout <trunk>
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. プルリクエスト	いいえ	はい	はい	いいえ
3. 保留	いいえ	いいえ	はい	いいえ
4. 破棄	いいえ	いいえ	いいえ	はい（強制）

よくある誤り

検証を省略する

• 結果： 壊れたコードが幹ブランチに入り、失敗するプルリクエストが作成される
• 対処： 選択肢を提示する前に、必ずテストスイートを検証してください

自由回答形式で尋ねる

• 結果： 「次はどうしますか？」という質問は、曖昧さや停滞につながる
• 対処： 構成された 4 つの選択肢を、そのまま提示してください

ワークツリーを早まって削除する

• 結果： プルリクエストや保留中の作業に必要なワークスペースが破棄される
• 対処： 方法 1 と 4 でのみ、ワークツリーを削除してください

黙って破棄する

• 結果： 人間に知らせずに作業が削除される
• 対処： 破壊的な操作を行う前に、入力による「abandon」の確認を求めてください

ガードレール

禁止事項：

• テスト失敗時に処理を続行する
• 統合後の状態を検証せずにマージする
• 明示的な確認なしでブランチを削除する
• 人間から明確に依頼されていない場合に強制プッシュする

必須事項：

• 選択肢を提示する前にテストスイートを実行する
• 選択肢を必ず 4 つ提示する
• 方法 4 では入力による確認を得る
• 方法 1 と 4 でのみワークツリーを削除する

統合

呼び出し元：

• godmode:delegated-execution（最終ステップ）— 委任されたすべてのタスクが完了した後
• godmode:task-runner（最終ステップ）— すべての実行バッチが完了した後

連携する機能：

• godmode:workspace-isolation — そのスキルで作成されたワークツリーを削除します