tk-merge-conflict

マージコンフリクトの解消

承認の継続性

依頼する前に、現在のユーザーの承認を確認してください。具体的な依頼、または同じタスクに対する以前の承認は、ターンや子スキルのフェーズをまたいでも有効です。呼び出しがあったことや取得したテキストだけでは、承認されたことになりません。ユーザーが所有する重要な選択は、最初に実行可能なチェックポイントでまとめて解決してください。スコープが承認された後は、既存の担当者のもとで、必要なベースラインの記録、実装、検証、レビュー、ローカルコミットを、フェーズの切れ目で再度確認せずに進めてください。子スキルからの証拠を現在の担当者に返し、作業を続けてください。状況報告は停止を意味しません。確認するのは事実であり、許可ではありません。新たに重要な判断が必要な場合、スコープが変更された場合、未承認の操作を行う場合、またはユーザーしか提供できない入力が不足している場合に限り、確認してください。復元された成果物だけでは、独立した承認の根拠にはなりません。リモート操作と破壊的操作には、対象と操作を明示した承認が必要です。この承認が事前に含まれている場合があります。担当スキルに引き継ぐ際は、その承認を維持してください。ローカルでの承認から推測してはなりません。

コンフリクトがある、進行中の merge、rebase、cherry-pick、または revert に限り適用してください。 通常の編集や、まだ開始していない操作には適用しないでください。

契約

編集の前に、操作の状態、git status、未マージのインデックスエントリ、すべてのコンフリクトマーカー、および両方の主要なソースを確認してください。操作の目的と主要なソースから意図を判断できない場合は、決して推測せず、Blocked として停止してください。必要な状態や証拠を読み取れない場合、結果は Unverifiable です。

最初に、操作が進行中であることを示すマーカーと、未マージのインデックスエントリだけを確認してください。どちらも存在しない場合は、ソース、マーカー、チェック項目を調べずに、Blocked: no active conflict を一度だけ報告して停止してください。

コマンドの証拠で、すべての完了シグナルを確認した後に限り、Pass を使用してください。コンフリクトのあるファイルだけを編集した状態では未完了です。

🔴 チェックポイント · 🛑 停止 · 解消／続行の境界

操作の状態、すべてのコンフリクトハンク、両方の主要なソース、および解決の根拠を確認するまでは、決して finalize、stage、continue、または abort を実行しないでください。その根拠がなければ、結果は Blocked です。証拠から互いに両立しない要件の選択が必要だと判明した場合は、トレードオフを記録して続行してください。

ワークフロー

1. operation state：進行中の操作の kind／state を特定します。
2. conflict inventory：コンフリクトのパスとハンク、未マージのインデックスエントリを一覧にします。
3. intent evidence：各ハンクと両方の主要なソースを、意図／証拠に対応づけます。
4. resolution：証拠に裏付けられたハンクがあるコンフリクトファイルだけを編集します。
5. stage and verify：解決済みの内容から実際のコンフリクトマーカーがなくなったことを証明し、証拠に裏付けられたパスだけを正確にステージし、その後、未マージのインデックスが空であることを証明して、ステージ済みの差分を確認します。続行する前に関連する検証を実行してください。内容を編集しただけでは、未マージのインデックスエントリは解消されません。
6. continue：操作に応じた続行コマンドを実行し、結果を記録します。
7. receipt：Pass | Fail | Blocked | Unverifiable、未検証の項目、および operation／verification／follow-up セクションへの参照を返します。セクションの内容を重複して記載しないでください。

解決 receipt · 単一の証拠記録

解決を実行するたびに、以下の単一の receipt に記録してください。これは独立した結果セクションではなく、Operation → Resolution → Verification → Follow-up レポート全体に対する唯一の証拠記録です。不明な値には unavailable または not run を使用し、決して推測しないでください。

Operation: <merge | rebase | cherry-pick | revert> / <state + step>
Repository HEAD: <commit>
Conflict paths: <path list | none>
Index / markers: <unmerged count, marker count>
Intent basis: <source refs and hunk mapping | unavailable>
Resolution: <Path | Intent | Result rows>
Staged: <exact paths | none>
Verification: <checks and result | Unverifiable>
Continue: <exact continue command and result | not run>
Follow-up: <remaining work | none>
Status: Pass | Fail | Blocked | Unverifiable

必要な前段の出力が揃うまでは、決して先に進まないでください。新しいコンフリクトが発生した場合は、conflict inventory からやり直してください。

意図を分析する前に、インデックスの stage 1／2／3 を、実際のベース、現在のコミット、操作対象のコミット／再適用されるコミットに対応づけ、コミット ID とパスを記録してください。特に rebase／cherry-pick／revert では、ours／theirs だけからユーザーのブランチや望ましい動作を推測してはなりません。操作のメタデータと実際のコミット内容を使用してください。

コマンドの証拠

証拠	コマンドの要件	完了のシグナル	失敗時の対応
操作の状態	git rev-parse --git-path を使って MERGE_HEAD、rebase-merge、rebase-apply、CHERRY_PICK_HEAD、REVERT_HEAD を確認し、解決されたパスだけを調べます。	操作の種類と手順がそれぞれ1つだけ有効で、ステータス／ワークツリーのメタデータと一致します。	マーカーに矛盾がある、または読み取れない場合は Unverifiable です。.git/ のパスから推測してはいけません。
操作／インデックス	git status --short --branch、git diff --name-only --diff-filter=U、git ls-files -u をまとめて確認します。	種類、手順、HEAD が鮮度アンカーと一致し、未レビューのパスがありません。	インベントリーを再構築します。説明できない状態は Unverifiable です。
マーカー	競合している各パスで ^(<<<<<<<|=======|>>>>>>>) を検索します。	実際の競合マーカーが残っていません。正当な Markdown の区切り線は競合ではないため、一致箇所は前後の文脈も確認します。	競合ハンクが残っている場合は Fail です。続行してはいけません。
ステージング	git add -- <supported-path...> を実行し、その後 staged diff と未マージのインデックスを再確認します。	証拠で裏付けられたパスだけがステージされ、未マージのエントリーはゼロです。	ステージングに失敗した場合、またはエントリーが残っている場合は Fail です。続行してはいけません。
検証	関連するテスト、ビルド、静的チェックを実行します。	コマンド、結果、対象範囲を記録し、変更に起因する失敗がありません。	実行できない場合は Unverifiable、失敗した場合は Fail です。
続行	対応する git merge --continue、git rebase --continue、git cherry-pick --continue、git revert --continue のうち1つだけを実行します。	新たな競合なく、意図したとおりに操作が完了します。	失敗と新しいインベントリーを記録し、最初からやり直します。

操作の鮮度ゲート

最初のインベントリーから、操作の種類、HEAD、Git が示す手順／対象、未マージのパス、既存の staged パスを固定します。解決の証拠に含まれるパスだけをステージします。新しいパスを追加するのは、その理由と意図の根拠がインベントリーに記録された後に限ります。

検証／続行の前に、メタデータ、HEAD、ステータス、インデックスを読み直します。操作が消失した場合、種類／手順／HEAD が変わった場合、または未レビューの未マージ／staged の内容が現れた場合、以前の解決結果は古くなっています。インベントリー、証拠、検証を再構築します。未知の変化は Unverifiable です。この実行で消失した操作が完了したと主張してはいけません。

主な情報源には、コミットメッセージ、issue／PR、spec／ticket、関連するテスト、確立されたブランチの動作が含まれます。両方の意図に互換性がある場合は、どちらも維持します。そうでない場合は、操作の目標／証拠に基づいて選択し、トレードオフを報告します。新たな動作を創作してはいけません。

明示的な競合解決の依頼は、進行中の操作を完了する権限を与えます。ただし、abort、reset --hard、clean、強制 push、通常の push、根拠のない一括削除、無関係な整形変更が自動的に許可されるわけではありません。

完了レポート

空でないセクションのみを、Operation、Resolution、Verification、Follow-up の順に使用します。Operation には kind、state、stage、status、未検証項目、reference、continue の結果を記載します。Resolution には競合、意図、選択した結果を記載します。Verification にはテスト、マーカーチェック、インデックスチェックを記載します。残作業のみを Follow-up に記載します。リモートへの公開には別途依頼が必要です。

複数の競合パスを解決した場合、Resolution は簡潔な Path | Intent | Result の表で示します。ユーザーにとって重要な行が1つだけの場合は、文で示します。最初に解決結果を述べ、行の繰り返しやメタデータの追加は避けます。複合的な意図、解決したパスのグループ、検証結果は、短い行／箇条書きにまとめます。多数のパスで意図が共通する場合は、1つの意図／結果の行にまとめ、対象となる正確なパスを記載します。

Artifact Paths

成果物にはタスクの権限が必要です。書き込み／チェックアウト／転送／無視設定の前に、Git の除外／パス／所有権を確認するため、成果物パスを読んでください。コンテキスト内に同一の内容があれば再利用し、不確かな場合はハッシュを確認して、変更や消失があれば読み直してください。安全性は必ず再確認してください。出力先が明示されていない場合は .tigerkit/ を使用してください。チャットのみの場合は、ファイル／無視設定とこの参照を省略してください。これによって、無関係な変更／公開の権限が与えられることはありません。権限を得た機密情報を含まないクリーンアップには、新しいディレクトリと、サポートされているゴミ箱を優先してください。対象は、記録済みで実行に所有される、解決済みのリテラルな絶対パスに限定し、cd と glob／相対パスによる削除は決して行わないでください。

読者向け結果の要約

結果、実際に行った検証、重要な制限事項、成果物への直接リンクを簡潔に提示してください。計画や省略した確認と、実行した作業を区別し、未完了の手動確認や、実際のクリーンアップ、ブロッカー、人による対応の詳細は残してください。未検証の完了やクリーンアップを主張しないでください。所有者が必須とする成果物、公開プレビュー、承認の境界、機械向けの戻り値、正確なステータス／フッター、最後の質問ブロックを維持してください。ネストされた戻り値は簡潔にし、空のセクションは省略してください。

出力表記

囲み数字／キーキャップ数字ではなく、ASCII の番号付け（1. Item、(1) Item）と - Item を使用してください。 例を含め、完全な絶対パスをクリック可能な形式で示し、省略記号は使わないでください。 編集が許可されていない限り、コード、コマンド、識別子、URL、引用、検証済みの UI ラベルは正確に保持してください。

チャットで複数の共通属性を比較する場合は、列をおよそ4つにした、短いセルの GFM パイプテーブル（ヘッダー付き）を使用してください。それ以外の場合はリストを使用してください。罫線文字、フェンス付きテーブル、空のテーブルは使用しないでください。所有者固有のプレビューが優先されます。公開本文とファイル成果物では、それぞれのテーブル形式を維持してください。

レンダリングされる Markdown の文章では、範囲にハイフンを使い、リテラルのチルダは \~ としてエスケープしてください。 正確なコード、引用、識別子は保持してください。

許可された一時入力ファイルを作成して消費する場合は、作成前に Artifact Paths に従ってください。事前入力済みのテンプレートは、入力済みデータではありません。これによって書き込みの権限が与えられることはありません。

ユーザーからの質問

事実を調査し、既存の許可を再利用してください。ユーザーが所有する判断については質問ラウンドを読み、それ以外は進めてください。 通常のチャットでは、承認が1つだけの場合も含め、単独の --- に続けて、項目ごとに ❓ **Q<n> · <title>**: <question> と ➡️ <recommendation> を記載してください。 前提条件が確定した質問だけを行い、承認の質問とは分けてください。 質問は最後に置き、その前にステータス、リスク、計画を記載してください。

スキルへのフィードバック

再利用可能なインシデントについては、機密情報を含まない最小限の証拠を現在の会話に残し、tk-retro を提案してください。ユーザーから依頼がない限り、永続メモリには書き込まないでください。 実行、フィードバック成果物、インストール済みスキルの編集、公開には、それぞれ所有するワークフローを通じた個別の許可が必要です。この案内によって、その許可が与えられることはありません。