1natsu-auto-resolve-conflicts — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited 1natsu-auto-resolve-conflicts (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
コミット履歴・diff・検証結果という観測事実だけを根拠に、コンフリクトを 解消 → 検証 → ステージング → コミット/--continue までAI単独で完了させる自走モード。
姉妹スキル 1natsu-pair-resolve-conflicts（人間と1ハンクずつ承認を取りながら解消する協調モード）と対をなす。本スキルは「AIが責任を持って一気にやり切る」が役割で、安全に判断できない場面では潔く pair モードへ引き渡す。
コンフリクトマーカー（<<<<<<< / ======= / >>>>>>>）を消すことはゴールではない。マーカーの除去 + 両側の機能を壊さない整合したコードの統合 が揃って初めて「解消」と呼ぶ。ours と theirs がそれぞれ別の機能を実装しているのに、片側を丸ごと捨ててマーカーだけ消すのは「解消」ではなくデグレである。コミット履歴から「両側が何を実現したかったか」を読み取り、その意図が解消後コードに両方とも生き残っていることを担保する（Point: [相互機能保持]）。
本スキルは2つの起点から開始できる：
git status に unmerged paths がある（merge/rebase/cherry-pick/stash pop 進行中）。→ Phase 0 から始める。mergeable:false）等で、ローカルはまだ衝突していないが base ブランチに追従するとコンフリクトが起きる。→ Phase A で base 追従してコンフリクトを発生させてから Phase 0 に合流する。1natsu-pair-resolve-conflicts に引き継ぐ基本は出力のみで進める。ユーザーへの確認はデグレに直結する場面（bail-out への移行、検証コマンドが見つからない場合）に限定する。確認が必要な時はプラットフォームが提供する対話型の選択UIを使う。
以下のようなフレーズで要求された場合、即座にモードに入る：
コンフリクト状態を検知し、かつユーザーが「自動で」「お任せ」「自走」を示唆した場合は本スキルへの移行を提案する（勝手に入らない）。明確な意思表示がなければ、まず 1natsu-pair-resolve-conflicts か本スキルかをユーザーに 1 回確認する。
提案の例：
コンフリクトが発生しています。自動モードで解消からコミットまでやり切りますか？デグレ懸念があれば途中で pair モードに切り替えます。
モードに入ったら、必ず以下を1メッセージで宣言する：
1natsu-pair-resolve-conflicts に切り替えることgit status に unmerged paths がなく、かつユーザーの意図が 「現在のブランチ/PR を base に統合できる状態にする」 である場合に実行する。すでにコンフリクト状態なら本フェーズは飛ばして Phase 0 へ進む。
意図の汲み取り（重要）: ユーザーは必ずしも「base を merge してコンフリクトを発生させて」と機構を指示してこない。次のような 目標・症状 も Phase A のトリガーになる:
「コンフリクトを直して」と言われてローカルに衝突が無い時は、即「解消対象なし」と結論づけず、まず「base に対して遅れていて、取り込むと衝突する状態ではないか」を疑う。これが本スキルの期待挙動。ただし、base 統合の意図がまったく読み取れない（単に clean なブランチで作業中など）場合は、勝手に base を merge せず状況を報告するか1回確認する（不用意な merge はしない）。
目的は base ブランチへの追従でコンフリクトを意図的に発生させ、その後 Phase 0 以降の通常フローに合流する こと。追従戦略は base を現在ブランチにマージ（git merge origin/<base>）を既定とする。force-push 不要で PR のレビュー履歴・コメントが剥がれず、Phase 4 の2段コミットとも相性が良い。
git status で「merge/rebase 等が進行中でない」「ワーキングツリーが clean（未コミット変更がない）」を確認する。汚染があれば Phase 0 の早期 bail-out と同じ理由（責任分離困難）で着手前に bail-out する。gh pr view --json baseRefName,mergeable,mergeStateStatus（gh があり PR が紐づく場合）→ 上流追跡 @{upstream} / リポジトリ default（git symbolic-ref refs/remotes/origin/HEAD）→ いずれも不明ならユーザーに1回だけ確認、の順で決める。git fetch origin <base>。remote が無ければ省略）した上で、git log --oneline <base>..HEAD と git log --oneline HEAD..<base> で乖離を見る。HEAD が base に対して遅れている（base 側に未取り込みのコミットがある）なら追従が必要と確定する。既に base を含んでいて遅れていないなら「追従不要・統合済み」と報告して終了する（観測事実で判断し、思い込みで merge しない）。git merge origin/<base>（remote が無ければローカル base を直接 git merge <base>）。詳細な base 検出ロジック（gh の有無、PR 非紐づけ時のフォールバック、remote が無い場合、rebase 慣習が明確な場合の例外）は references/stale-pr-follow.md を参照する。
# 現在の操作種別（merge / rebase / cherry-pick / stash pop）
git status
# rerere の状態
git config rerere.enabled
git rerere status # 有効な場合rerere が有効で自動解消が適用されている場合は、その内容を診断対象に含める。rerere が怪しい挙動をしているなら git rerere forget <file> での取り消しを検討する。rerere が無効でも有効化を提案しない（ユーザー判断領域）。
以下のいずれかに該当したら、Phase 1 に入る前に即 bail-out する：
dist/, build/, *.png, *.pdf, *.snap）Subproject commit 行の両側変更）migrations/, prisma/migrations/, alembic/versions/）package.json の dependencies セクション、Cargo.toml [dependencies]、pyproject.toml、go.mod、Gemfile 等auth, crypto, secrets, RBAC, IAM, .env* 名前を含む）git status で untracked / unstaged の他要因変更がある）lockfile（パッケージマネージャが生成する依存解決ファイル全般）の両側変更は早期 bail-out にしない。代表例として bun.lock / bun.lockb / pnpm-lock.yaml / yarn.lock / package-lock.json / Cargo.lock / go.sum / poetry.lock / uv.lock / Gemfile.lock / composer.lock / mix.lock / flake.lock 等があるが、ファイル名一覧で判定するのではなく「機械生成・対応 manifest あり・対応するパッケージマネージャあり・再生成コマンドと frozen 検証手段が揃う」という 性質 で Auto-Regenerate に該当するか判定する。lockfile はテキストマージで整合性を壊しやすく、対応するパッケージマネージャで再生成するのがベストプラクティス。詳細な判定原則と対応表は references/lockfile-regeneration.md を参照。
詳細な判定基準と検出方法は references/bailout-rules.md を参照する。
# コンフリクトファイル一覧
git diff --name-only --diff-filter=U
# 操作種別ごとの両側コミット履歴
# merge:
git log --oneline HEAD...MERGE_HEAD -- <files>
# rebase:
git log --oneline REBASE_HEAD~1..REBASE_HEAD -- <files>
# cherry-pick:
git log --oneline CHERRY_PICK_HEAD -- <files>ファイルごと（必要に応じてハンクごと）に以下の4段階で分類する：
bun install / pnpm install / cargo generate-lockfile / go mod tidy / poetry lock --no-update / uv lock など、エコシステムごとの再生成コマンド）で 再生成 する。手動マージは絶対にしない。ファイル名一覧で判定するのではなく、機械生成性 + 対応 manifest の存在 + 再生成コマンドと frozen 検証の有無 という性質で判定するため、対応表外の未知 lockfile も性質を満たせば対象に含める。references/lockfile-regeneration.md 参照詳細な判定基準と具体的な検出コマンドは references/bailout-rules.md を参照する。
分類が終わったら、1メッセージで以下を提示する：
Auto-No が 1 件でもある場合は 全体 bail-out が原則。ただし Auto-OK / Auto-Regenerate と独立に解消できることが明確な場合（同じファイルではない、依存関係がない）は、安全な部分だけ適用する 混合 bail-out を選んでもよい。デグレ懸念が拭えなければ全体 bail-out を選ぶ。
各ファイルを 直列（並列にしない）で処理する。並列化は依存関係の見落としを生み、デグレ防止原則に反する。
処理順序の推奨: 同じ Phase 2 ループ内では、Auto-OK の manifest を先に解消 → Auto-Regenerate を実行 → 残りの Auto-OK を解消 の順で進めると、lockfile の再生成が最新の manifest を反映でき、整合性が高まる。
git add しない（2段コミットと bail-out の生命線）Phase 2 全体を通して `git add` は一切しない。これにより index には unmerged stages（git が記録した両側＋ベースの3版）がそのまま残る。merge の2段コミットでは、解消後に `git checkout --merge -- <file>` で index から「マーカー入りの衝突原文」を git に再生成させてスナップショットコミットを作る（手順は references/two-stage-commit.md）。マーカー原文を自前のファイルに退避しておく必要はなく、git の index が真実の源になる。bail-out 時に再衝突状態へ戻せる退路も同じ仕組みで保たれる。
衝突原文を一時ファイルに退避する設計は採らない（固定パスは並列実行で衝突し、状態が壊れやすい）。原文は常に git checkout --merge で index から復元する。各ファイルに対して以下のサイクルを回す：
git log -p HEAD -- <file> と git log -p MERGE_HEAD -- <file>（操作種別に応じてリビジョン名を変える）で両側の変更履歴を読み、コミットメッセージと周辺コードから変更意図を抽出するtsc --noEmit <file>、python -m py_compile <file>、go vet <pkg>、cargo check -p <pkg> 等）。失敗したら 即 bail-out<file>: ours採用 / 統合 / theirs採用 — <一行根拠（片側採用なら「捨てた側に固有機能なし」の根拠を含める）> の形式で1行サマリを出力lockfile 等は手動マージしない。詳細手順と対応表は references/lockfile-regeneration.md を参照。要点のみ：
package.json / Cargo.toml / pyproject.toml 等）が決定済みか確認。未解消なら先に Auto-OK ループで解消rm <lockfile> でクリーンに再生成する方が確実--help で確認）<lockfile>: regenerated via <command> (<frozen-verification> verified) の形式で出力これらが起きたら そのファイルを未解消のまま 残し（解消を書き込み済みなら git checkout --merge -- <file> で再衝突状態に戻す）、混合 bail-out に切り替える。それまでに適用した他ファイルはそのまま残す。
package.json, lockfile 各種, pyproject.toml, Cargo.toml, go.mod, Makefile, Justfile, .pre-commit-config.yaml）pnpm-workspace.yaml, turbo.json, nx.json, ルート package.json の workspaces）bun.lockb > pnpm-lock.yaml > yarn.lock > package-lock.json）詳細は references/verification-detection.md を参照する。言語別の優先コマンド表とフォールバックを記載している。
docker / db / network を含むテスト名は環境依存の疑いがあるため、失敗時は人間判断のため bail-out検出に失敗した場合は 唯一の例外 としてユーザーに 3 択を提示する：
1natsu-pair-resolve-conflicts に渡すそれ以外の場面ではユーザー確認を取らない。
ここまでで全ファイルが解消済み・検証通過済み・ステージング前（index は unmerged stages のまま）になっている。完了処理は操作種別で分岐する。
なぜ2段か — AI が「マーカーを消したコミット」を1つ積むだけだと、git ログには解消後の姿しか残らず、どのマーカーをどう解消したのか（解消の diff）が履歴から追えない。問題が起きた時にレビュワーが「どの解消でミスが入ったか」を辿れない。そこで merge/stash では ①コンフリクト発生状態（マーカー入り）をコミット → ②マーカー解消をコミット の2段にし、①→②の diff として解消内容を履歴に残す。
references/two-stage-commit.md の手順に従う。要点（状態は git index に持ち、自前の固定パス退避はしない）：
mktemp -d で作った一意のディレクトリにコピー（並列実行で衝突しないよう固定パスは使わない）。git checkout --merge -- <conflicted-files> で index の unmerged stages から マーカー入りの衝突原文を git に再生成させ、git add <conflicted-files> → git commit --no-verify。これが 2親を持つマージコミットで、中身はマーカー入り。フットプリントは conflict-snapshot by 1natsu-auto-resolve-conflicts（hook がマーカーを弾くため --no-verify）。git add <files> → git commit。これは①を親に持つ通常コミットで、マーカーは除去済み。メッセージは解消サマリ＋フットプリント auto-resolved by 1natsu-auto-resolve-conflicts（references/commit-message-template.md 参照）。結果、git log は「マージコミット（マーカー入り）→ 解消コミット」となり、git diff <マージコミット>..<解消コミット> が解消内容そのものになる。混合 bail-out（一部のみ解消）の場合は2段にせず、解消済みファイルを残したまま commit せず handoff する（従来どおり）。
stash pop は性質上コミットを作らない。解消済みファイルを git add するに留め、2段コミットは適用しない（コミットが無いので①②が成立しない）。スナップショット退避も結果として使わない。
2段にすると replay 中のコミットにマーカーが焼き込まれ、元コミットの意味破壊・bisect 破壊・履歴増殖・force-push 増幅を招くため、従来どおり1コミットに解消を畳む。
git add <resolved-file-1> <resolved-file-2> ...（未解消ファイルは add しない）git rebase --continue / git cherry-pick --continue。元コミットメッセージは --continue が保持する。`--continue` の前に `git commit --amend` を実行してはならない（その時点の HEAD は replay 対象ではなく一つ前の既存コミットで、上書きすると履歴を破壊する）。フットプリント auto-resolved by 1natsu-auto-resolve-conflicts は既定では完了報告に記す（コミットへ無理に注入しない）。コミットにも残したい場合は cherry-pick なら --continue 後に git commit --amend、rebase は replay コミットが HEAD である時に限り amend する。詳細・禁止事項は references/commit-message-template.md 参照。git range-diff / reflog で代替する。3 点をまとめて出力する：
bail-out が発動したら：
引き継ぎプロンプトのテンプレートは references/handoff-to-pair-resolve.md にある。操作種別 × bail-out 理由のマトリクスで定義しているので、当てはまるテンプレートを使う。
検証コマンドが落ちて Phase 3 で bail-out する場合、Phase 2 までの解消は 適用済みでステージング前（2段コミットの①スナップショットはまだ取っていない＝merge コミットは未作成）。ロールバックは強制せず、ユーザーが git reset / git checkout --merge するか pair で続行するかを選択できるよう、ハンドオフプロンプトに状態説明を含める。
「安全に判断できなかったので人間に渡す」は本スキルの正しい振る舞い。デグレを起こす自動コミットより、bail-out の方が常に望ましい。
references/commit-message-template.md）を必ず残し、後から監査できるようにするgit rerere forget で取り消す前に観測事実で根拠を示すreferences/bailout-rules.md — Auto-No/Risky/Regenerate/OK の詳細条件と検出方法references/stale-pr-follow.md — Phase A の base ブランチ検出と追従（未コンフリクト状態からの起点作り）references/two-stage-commit.md — Phase 4 の履歴優先2段コミットの手順（merge/stash）references/lockfile-regeneration.md — lockfile 等の自動再生成フローとパッケージマネージャ別コマンド表references/verification-detection.md — 言語・パッケージマネージャ別の検証コマンド表references/handoff-to-pair-resolve.md — bail-out 時の引き継ぎプロンプトテンプレートreferences/commit-message-template.md — 自動コミットメッセージの規約とフットプリント1natsu-pair-resolve-conflicts — 人間と1ファイル/1ハンクずつ承認を取りながら解消する協調モード。本スキルが bail-out した時の引き継ぎ先~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.