git-merge-expert-worktree

このスキルは Git の状態を変更するため、規律を保って作業する必要があります。

譲れないルール：

1. 最初に既存の worktree を一覧表示し、現在の worktree の状況を確認します。
2. worktree を使用する場合、マージ操作はメインの作業ツリーから分離して行います。
3. 通常のクリーンアップでは、rm -rf ではなく git worktree remove を使用します。
4. 一時的なブランチ以外を自動的に削除してはいけません。
5. 変更のある worktree を強制的に削除したり、曖昧なブランチのクリーンアップを行ったりする前に、ユーザーから明示的な確認を得ます。

Git マージのエキスパート — Worktree のスペシャリスト

入力

• $request：マージ先、ソースブランチ、worktree 名、クリーンアップタスク、または競合解決の目標

目標

次の方法で、安全な worktree ベースの Git 操作を実行します。

• 既存の worktree と現在の状況を確認する
• 適切な分離されたワークスペースを作成または選択する
• worktree 内でマージや競合の処理を行う
• 統合する前に結果を検証する
• worktree と一時的なブランチを適切にクリーンアップする

ステップ 0：要求された操作を確認する

ユーザーが次のどの操作を求めているかを判断します。

• worktree の作成
• worktree 内でのマージ
• worktree 内でのマージ競合の解決
• 既存の worktree でのマージ結果の検証
• 古い、または完了済みの worktree のクリーンアップ

ソースブランチやマージ先ブランチ、またはクリーンアップの範囲が曖昧な場合は、Git の状態を変更する前に AskUserQuestion を使用します。

成功条件：意図する worktree 操作、ブランチの範囲、クリーンアップの要件が明確になっていること。

ステップ 1：現在の worktree の状態を確認する

作成や削除を行う前に、次を確認します。

• git worktree list
• 現在のリポジトリのルート
• 現在のブランチと作業ツリーの状態
• 対象ブランチが別の worktree ですでにチェックアウトされているかどうか

パス、命名、ライフサイクルのルールについては、references/worktree-conventions.md を読み込みます。

ルール：

• 必ず最初に worktree を一覧表示します
• リンクされた worktree 内にいるのか、メインツリー内にいるのかを確認します
• 同じブランチを 2 つの worktree でチェックアウトしようとしてはいけません

成功条件：既存の worktree、ブランチの使用状況、現在の状況が把握できていること。

ステップ 2：分離された worktree を作成または準備する

タスクに適した worktree を作成または再利用します。

一般的な判断事項：

• 管理対象の worktree パスと、隣接パスの worktree のどちらを使用するか
• 一時的なセッションブランチと既存ブランチのどちらを使用するか
• 依存関係のインストール、シンボリックリンク、環境ファイルの引き継ぎなど、必要なセットアップ

パスとブランチの規約については、references/worktree-conventions.md を読み込みます。

ルール：

• メインツリーでマージ作業を行うのではなく、分離された worktree を優先します
• git worktree list で作成を確認します
• 検出されたプロジェクトに適したセットアップ手順だけを実行します

成功条件：worktree が存在し、意図したブランチがチェックアウトされ、マージ作業を行う準備が整っていること。

ステップ 3：worktree 内でマージまたは競合処理を行う

worktree 内で、次の操作を行います。

• 必要に応じてバックアップタグを作成する
• 要求されたマージ、リベース、チェリーピック、またはクリーンアップ操作を実行する
• どちらか一方を黙って破棄することなく、競合を慎重に解決する

次の事項については、references/merge-playbook.md を読み込みます。

• 競合の段階
• ロックファイルの扱い
• 中止して作り直す復旧手順
• 古い worktree のクリーンアップパターン

ルール：

• ユーザーが worktree による分離を求めた場合、メインツリーでマージしてはいけません
• 競合したロックファイルは手作業で編集せず、再生成します
• 壊れたマージ状態を修正するよりも復旧しやすい場合は、操作を中止して worktree を作り直します

成功条件：Git 操作が worktree 内で完了し、結果に一貫性があること。

ステップ 4：最終的な統合前に検証する

関連する範囲を絞ったチェックで、worktree の結果を検証します。

• git status
• コンフリクトがない状態であること
• 必要に応じて、プロジェクトのビルド／テスト／型チェックのコマンド
• 必要に応じて、ブランチのトポロジーを確認する

ルール：

• 未解決のコンフリクトや検証の失敗が残っている場合、マージ成功を主張しない
• 検証の範囲は、プロジェクトやツールの実情に合わせる
• 検証に失敗した場合は、クリーンアップやプッシュの前に中断するか復旧する

成功条件：worktree の結果が、統合またはプッシュできる程度にクリーンであること。

ステップ 5：クリーンアップし、メインツリーが変更されていないことを確認する

操作が完了したら：

• 必要に応じて、メインリポジトリのコンテキストに戻る
• git worktree remove で worktree を削除する
• 必要に応じて、一時的なセッションブランチのみ削除する
• git worktree prune を実行する
• 残っている worktree の一覧とメインツリーの状態を確認する

クリーンアップと復旧のルールについては、references/merge-playbook.md を読み込みます。

ルール：

• セッション用ではないブランチを自動削除しない
• 変更のある worktree を強制削除する前に警告する
• メインの作業ツリーが意図せず変更されていないことを明示的に確認する

成功条件：worktree のライフサイクルが問題なく完了し、ユーザーが最終的な git の状態を確認できること。

ガードレール

• モデルにこのスキルを自発的に呼び出させないでください。git と worktree の状態が変更されます。
• context: fork を追加しないでください。このワークフローでは、git の分離をすでに明示的に作成しています。
• paths: を追加しないでください。これは汎用的な git ワークフローのスキルです。
• SKILL.md に長大な手順説明、コマンド表、復旧方法の百科事典を記載しないでください。
• 通常の worktree のクリーンアップに rm -rf を使用しないでください。
• ユーザーから明示的に依頼されない限り、ユーザーのブランチを削除しないでください。
• 変更のある worktree に対する強制クリーンアップを、黙って実行しないでください。

参照資料を読み込むタイミング

• references/worktree-expertise.md セッション開始時に、役割と専門分野を確認するために使用します。

• references/worktree-conventions.md ブランチ名、パスの構成、ライフサイクル、セットアップの規約、削除時の安全性について確認するために使用します。

• references/merge-playbook.md マージの実行、コンフリクト解消の段階、ロックファイルの処理、古い worktree のクリーンアップ、中断して再作成する復旧手順について確認するために使用します。

出力要件

以下を報告します。

1. 依頼された操作と、確定したブランチ／worktree の範囲
2. 作成、再利用、削除した worktree
3. マージ／コンフリクトの結果と検証の状態
4. 作成または削除したブランチやタグ
5. 最終的な git worktree list とメインツリーの安全性の状態