1natsu-pair-resolve-conflicts - SKILL.md Agent Skill

name: 1natsu-pair-resolve-conflicts description: Gitのコンフリクト解消を人間とペアで行う協調スキル。merge, rebase, cherry-pick, stash pop等でコンフリクトが発生した時、コミット履歴と変更の経緯を分析し、「なぜこう変わったか」を解説しながら1つずつ人間の承認を得て解消する。ユーザーが「コンフリクト解消しよう」「一緒にコンフリクト直そう」「conflict resolve」等と言った時、またはAIがコンフリクト状態を検知した時に使用する。コンフリクトを自動で一括解消してコミットするのではなく、必ず人間と対話しながら進めること。 license: MIT metadata: author: 1natsu version: "1.1.0"

Pair Resolve Conflicts（ペアコンフリクト解消）

コンフリクトの背景にあるコミット履歴と意図を読み解き、人間と一緒に1つずつ解消していく協調モード。

AIは変更の経緯調査・解消案の提示・解消後の整合性確認を担当し、人間は最終的な解消方針の判断と承認を担当する。AIが勝手に全コンフリクトを解消してコミットすることは絶対にしない。

対話ルール

ユーザーに選択肢を提示する場面では、プラットフォームが提供する対話型の選択UIを使うこと。

モードの開始

ユーザーからの明示的な起動

以下のようなフレーズで要求された場合、即座にモードに入る：

「コンフリクト解消しよう」「一緒にコンフリクト直そう」「pair resolve」「conflict resolve」
「マージしたらコンフリクトした」「rebase でコンフリクト出た」

AIからの提案

コンフリクト状態を検知した場合（git status で both modified / both added / deleted by us 等が見える、ユーザーがコンフリクトについて言及している等）、このモードへの移行を提案する（勝手に入らない）。

提案の例：

コンフリクトが発生しているようです。コミット履歴を確認しながら一緒に解消しませんか？

以下の選択肢を提示する：

「はい、一緒に解消しましょう」→ モードに入る
「いいえ、自分で対応する」→ モードに入らず、通常の対応に戻る

ワークフロー

Phase 0: 状況把握

モード開始時に以下を確認する：

# 現在の状態（merge中? rebase中? cherry-pick中?）
git status

# rerere が有効か確認
git config rerere.enabled

rerere（reuse recorded resolution）が有効な場合：

git rerere status で既に自動解消された箇所を確認する
rerere が適用済みのファイルがあれば「rerere が以前の解消を再適用しました」と伝え、内容を人間に確認してもらう
rerere の自動解消が正しいか怪しい場合は git rerere forget <file> で取り消すことを提案する
rerere が有効でない場合は特に言及不要（有効化の提案もしない。設定はユーザーの判断領域）

Phase 1: コンフリクト全体の俯瞰

# コンフリクトしているファイル一覧
git diff --name-only --diff-filter=U

# 操作の種類に応じた両側のコミット履歴
# merge の場合：
git log --oneline HEAD...MERGE_HEAD -- <conflicted-files>
# rebase の場合：
git log --oneline REBASE_HEAD~1..REBASE_HEAD -- <conflicted-files>

以下を人間に提示する：

操作の種類 — merge / rebase / cherry-pick / stash pop
コンフリクトファイル数と一覧 — 多い場合はカテゴリ分け（src, test, config 等）
推奨する解消順序 — 依存関係がある場合は依存元から。なければ影響が小さいものから
全体の見通し — 「N件のコンフリクトがあります。順番に見ていきましょう」

Phase 2: ファイルごとの解消ループ

各コンフリクトファイルに対して以下のサイクルを回す。

Step 1: 変更の経緯を調査する

# 両方のブランチでこのファイルに何があったかを調べる
git log --oneline --all -- <file>
git log -p MERGE_HEAD -- <file>   # 相手側の変更履歴
git log -p HEAD -- <file>         # 自分側の変更履歴

コンフリクトの各ハンクについて、なぜこう変わったかを突き止める。コミットメッセージ、PR の文脈、周辺コードの変更から意図を読み取る。

Step 2: コンフリクトの内容と解消案を提示する

ファイルごと（またはハンクごと — 複雑さに応じてAIが判断）に以下を提示する：

## <ファイルパス>（N箇所のコンフリクト）

### ハンク 1（L42-L58）

**ours（現在のブランチ）の変更：**
- コミット abc1234「feat: ユーザー認証にJWT追加」で認証ロジックを変更
- 意図：セッションベースからJWTベースに移行するため

**theirs（マージ元ブランチ）の変更：**
- コミット def5678「fix: セッションタイムアウトの修正」でタイムアウト処理を修正
- 意図：セッション切れ時のエラーハンドリング改善

**解消案：**
JWT移行が進んでいるため、ours側のJWTロジックをベースにしつつ、
theirs側のエラーハンドリングの考え方（タイムアウト時のグレースフル処理）を
JWT版に移植するのが妥当です。

具体的には：
- L42-50: ours を採用（JWT認証ロジック）
- L51-58: 両方を統合（JWTの期限切れハンドリングにtheirsのグレースフル処理を組み込む）

粒度の判断基準：

ファイル単位で提示 — コンフリクトが1-2箇所で文脈が明確な場合、または機械的に片側を採用すれば済む場合
ハンク単位で提示 — コンフリクトが3箇所以上ある場合、両側の変更を統合する必要がある場合、ビジネスロジックに関わる判断が必要な場合

Step 3: 人間の承認を待つ

解消案を提示したら、以下の選択肢を提示する：

この案で進める — AIが提示した解消案を適用
修正して進める — 人間が方針を指示し、AIがそれに従って修正
自分で直す — 人間がIDEで直接編集し、完了を報告
スキップ — このファイルは後で戻ってくる

人間が承認するまで、次のファイルに進まない。

Step 4: 解消を適用する

承認された解消案をファイルに適用する（コンフリクトマーカーを除去して解消後のコードに書き換える）。

この時点ではまだ git add しない。 ステージングは全ファイルの解消が終わってからまとめて行う。解消済みファイルとして記録し、次のファイルへ進む。

Phase 3: 全体確認とステージング

全ファイルの解消が終わったら：

# 未解消のコンフリクトが残っていないか確認
git diff --name-only --diff-filter=U

# 解消結果の全体像を確認（まだステージング前）
git diff

以下を人間に提示する：

解消サマリー — 各ファイルでどう解消したかの一覧
全体の差分確認 — 人間がIDEのDiffビューで全体を通して確認できるよう促す。この段階で「やっぱりこのファイルの解消を変えたい」という手戻りにも対応する
ステージングの確認 — 「全ファイルをステージングしてよいですか？」と確認し、承認されたらまとめてステージングする：

git add <resolved-file-1> <resolved-file-2> ...

次のアクション — 操作の種類に応じた選択肢を提示する：
- git commit でマージコミットを作成（merge の場合）
- git rebase --continue で rebase を続行（rebase の場合）
- git cherry-pick --continue（cherry-pick の場合）
- コミット前にビルド/テストを実行して確認
- コミットせずに終了（人間が後で手動でコミット）

AIが勝手にコミット/continue を実行しない。 人間が明示的に指示した場合のみ実行する。

核心ルール

解消案は提案であり、決定ではない — 最終判断は常に人間が行う。AIは「こうすべき」ではなく「こうする理由はこれです」と経緯を説明する
コミット履歴を根拠にする — 「こちらが新しいから」ではなく「このコミットでこの意図で変更されたから」と具体的に示す
人間の承認なしに次に進まない — 1ファイル（または1ハンク）ずつ確実に合意を取る
自動コミットしない — 全コンフリクト解消後も、コミット/continue の実行は人間の明示的な指示を待つ
わからない時は正直に言う — コミット履歴からも意図が読み取れない場合は「この変更の意図が履歴から判断できません。どちらの変更を優先すべきか教えてください」と聞く