merge

merge skill の概要

merge skill は何のためのものか

merge skill は、マルチエージェントでのコーディングセッション後に、勝者となったエージェントの成果を Git のベースブランチへ取り込むための AgentHub ワークフロー skill です。/hub:merge コマンド向けに設計されており、選ばれた勝者をマージし、負けた試行は後から確認できるよう残し、セッション用 worktree を片付け、マージ後のサマリーを書く、という実務上の一連の作業に集中しています。

Git Workflows に最適な場面

この merge skill は、リポジトリが AgentHub のセッション ID、エージェントブランチ、評価ランキング、一時 worktree というパターンに沿って運用されている場合に使うのが適しています。特に /hub:eval の後、どのエージェントが最良の解を出したかがすでに分かっていて、ブランチの checkout、merge、負けブランチへの tag 付け、worktree 削除を手作業で行うのではなく、再現性のある Git Workflow として処理したいときに有用です。

汎用的なマージ用プロンプトとの違い

汎用的なプロンプトなら「最良のブランチをマージして」と指示するだけかもしれません。一方、この skill は明確な運用ルールを持っています。--agent が指定されていなければ最上位のエージェントを使い、--no-ff でマージし、勝者以外のブランチは hub/archive/... タグでアーカイブし、ブランチ ref を削除し、.agenthub/board/results/merge-summary.md を生成します。この構造により、マルチエージェントの Git セッションで散らかりやすいクリーンアップ時の曖昧さを減らせます。

インストール前に確認しておきたいこと

この skill は、プロジェクト側に hub/{session-id}/{agent-id}/attempt-1 のような AgentHub 形式のブランチと、勝者を特定できる評価結果がすでに存在することを前提にしています。チームで AgentHub を使っていない場合でも、構造化されたクリーンアップのモデルとして merge ガイドを読む価値はありますが、安全に使うには事前の調整が必要です。

merge skill の使い方

merge のインストールと最初に確認するファイル

GitHub の skill リポジトリから次のコマンドでインストールします。

npx skills add alirezarezvani/claude-skills --skill merge

その後、ソースを確認します。

engineering/agenthub/skills/merge/SKILL.md

この skill は SKILL.md 内で完結しているように見えます。skill ディレクトリのプレビュー上では、付随する rules/、resources/、scripts/ フォルダは確認できません。ただし、上流の手順では session_manager.py に言及しているため、自動クリーンアップに依存する前に、そのスクリプトが自分のローカル AgentHub 環境のどこに存在するかを確認してください。

基本的な merge の使い方

代表的な呼び出し方は次のとおりです。

/hub:merge
/hub:merge 20260317-143022
/hub:merge 20260317-143022 --agent agent-2

最新の評価済みセッションを対象にする場合は /hub:merge を使います。複数の AgentHub セッションがある場合は、セッション ID を指定してください。--agent は、最上位の /hub:eval 結果を意図的に上書きする場合だけ追加します。たとえば、最高スコアの解がセキュリティ、互換性、プロダクト要件を満たしていないことを人間のレビューで見つけた場合などです。

skill が必要とする入力

merge を安定して使うには、エージェントに次の情報が必要です。

• 対象となるベースブランチ。通常は、勝者の作業を取り込みたいブランチです。
• AgentHub のセッション ID。最新セッションが明確でない場合は必須です。
• 勝者。最新の評価ランキングから選ぶか、--agent で指定します。
• 期待される形式の既存ブランチ ref: hub/{session-id}/{agent-id}/attempt-1。
• マージコミット、タグ、ブランチ削除を作成する Git 操作を実行できる権限。

よりよいプロンプト例は次のようになります。「/hub:merge 20260317-143022 --agent agent-2 を main に対して実行してください。マージ前に working tree が clean であることを確認し、勝者の branch ref を表示し、負けたブランチに archive 用の tag を付け、merge summary を書いてください。」このように運用上の文脈を与えると、skill が推測で進めるリスクを減らせます。

実行前後の実務フロー

merge を呼び出す前に git status を実行し、無関係なローカル変更を抱えていないことを確認し、勝者の diff をレビューしてください。マージ後は、マージコミットメッセージを確認し、archive tag が作成されたことを確かめ、.agenthub/board/results/merge-summary.md にセッション、タスク、勝者が反映されているかを検証します。コンフリクトが出た場合は、通常の Git コンフリクトとして解決してください。この skill が提供するのはワークフローの構造であり、コードレビューの代替ではありません。

merge skill FAQ

merge は AgentHub 専用ですか？

実質的にはそうです。merge skill は、AgentHub の命名、評価、クリーンアップの慣習を前提に書かれています。他のマルチブランチ実験における手動 Git Workflow の参考にはなりますが、そのまま使うには AgentHub のセッションブランチと結果メタデータが必要です。

merge は最良のコードを自動で選びますか？

指定した --agent を選びます。指定がない場合は、直近の /hub:eval で最上位にランクされたエージェントを選びます。つまり、マージ品質は事前評価の品質に依存します。評価基準に抜けがあった場合は、マージ前に勝者を手動でレビューしてください。

負けたブランチはどうなりますか？

想定されているワークフローでは、負けた各エージェントブランチに hub/archive/{session-id}/{agent-id} のような Git tag を付けてアーカイブし、その後ブランチ ref を削除します。これにより、コミットは到達可能なまま保ちつつ、ブランチ一覧の散らかりを減らせます。保持ポリシーがあるチームでは、この skill を採用する前に archive tag の命名が方針に合うか確認してください。

この skill を使わないほうがよい場合は？

ブランチ名が AgentHub の規約に従っていない場合、ベースブランチが不明確な場合、勝者がレビューされていない場合、またはリポジトリで自動的なブランチ削除が禁止されている場合は、merge を使わないでください。また、この skill のデフォルトパターンは git merge --no-ff を使うため、squash のみのワークフローにもそのままでは向きません。使う場合はマージコマンドの調整が必要です。

merge skill を改善する方法

より明確な文脈で merge 結果を改善する

merge skill は、依頼にセッション ID、勝者、ベースブランチ、ポリシー上の制約が含まれていると最も効果を発揮します。たとえば、「セッション 20260317-143022、勝者 agent-2 を develop にマージしてください。負けたブランチは tag でアーカイブし、remote branch は削除せず、テストが失敗したら停止してください。」という指示です。「勝者をマージして」よりも、選定、取り込み先、クリーンアップ、安全条件を分けて伝えられるため、精度が上がります。

注意すべきよくある失敗パターン

主なリスクは、最新セッションが曖昧であること、評価結果が見つからないこと、working tree が dirty であること、ブランチ ref が期待されるパターンに一致しないこと、そしてクリーンアップコマンドがこの skill ディレクトリ外のファイルに依存していることです。もう一つ重要なのは、技術的には通っていてもプロダクト要件として誤っている勝者をマージしてしまうリスクです。/hub:eval は選定の入力として扱い、最終レビューの代替にはしないでください。

リポジトリのポリシーに合わせて merge を調整する

チームで squash merge、signed commits、protected branches、pull requests、CI gates、remote branch retention が必要な場合は、本番利用の前にワークフローを編集してください。特に調整が入りやすいのは、マージ戦略、archive tag の形式、ブランチ削除を local-only にするかどうか、merge-summary.md に必須とする項目です。

初回実行後に確認を重ねる

初回の出力後は、エージェントにそのまま続行させるのではなく、検証を依頼してください。「merge commit を表示し、このセッションの archive tags を一覧し、AgentHub worktrees が残っていないことを確認し、コンフリクトやスキップされたクリーンアップがあれば要約してください。」このようにすると、merge ガイドを監査可能な Git Workflow として使えるようになり、セッションを忘れる前に不完全なクリーンアップを見つけやすくなります。