git-sync

同期依頼を、対象リポジトリのローカル変更保全、fetch、差分統合、必要な生成・配備更新、検証、commit、pushまでの実行依頼として扱う。これらを工程ごとに再承認させない。親が対象・統合判断・復旧・最終確認を持ち、実行可能な作業が残る間は途中報告だけで終了しない。

同期の範囲

• 対象を省略したら cwd の Git top-level を使う。対象リポジトリが管理する生成物、submodule、ホーム側の配備コピー・リンクも整合に必要な範囲で含む。ホーム配備であることだけを別依頼の理由にしない。
• dotfiles 本体は、同じ共有skills内の dotfiles-autosync/SKILL.md を読み、中央 engine に引き継ぐ。sync依頼をその起動承認として扱う。
• 無関係な別リポジトリの同期へは広げない。本体push後、同じターンで check-updates を実行する。更新対象 root は、利用中 runtime のプラグイン・marketplace などの独立 clone を置くディレクトリのうち、親が実在を確認したものだけを明示する（例: Claude Code の ~/.claude/plugins/marketplaces）。このrootを渡したbackground担当で非同期実行でき、親はその間に本体同期の最終確認を行う。見つからなければ実行せず、その旨を報告する。手での git pull に置換しない。check-updates の失敗で独立した本体同期を止めない。
• 依頼の反映先をGit rootとupstreamごとに確定する。submodule・独立ライブラリ・配布用コピーがある場合、編集したコピーと公開元を区別し、依頼に必要な反映先を同期対象から落とさない。内容やruntime固有の役割を確認し、一律のファイル一致や無関係なcloneの公開は要求しない。

1. 対象と状態を実測する

対象 path を引用して Git top-level、branch、remote URL、既存 upstream、進行中操作、git status -sb、差分、直近commitを確認する。

既存 upstream を優先する。未設定なら remote と同名branchの実在、push先設定、直近履歴から送り先を確定する。一意に確認できればそのremote/branchを使い、必要なtracking設定は git push -u で行う。候補が複数で根拠がない場合だけ送り先を確認する。remote URLの書き換えや新設を推測で行わない。

進行中の merge/rebase/cherry-pick/revert は開始元と対象を確認し、今回の同期に属するものなら下の統合手順で完了して続行する。別作業の操作は変更せず、その操作に依存しない確認を進める。detached HEAD はHEADを含む作業branchと保全状況を調べ、対象branchが確定して変更を失わず戻せる場合は復帰する。

2. ローカル変更を保全する

dirty、untracked、既存staged変更をpathごとに確認する。通常の対象内WIPは同期依頼に含まれる保全commitとして扱う。git sync だけの依頼でもこの承認は成立し、ファイル名や「保全commit」の明記を要求したり、変更一覧を示してcommitの可否を再確認したりしない。秘密情報、一時バックアップ、明示的に除外された変更は含めない。既存staged内容も公開可能か確認する。

必要な生成・配備更新とリポジトリ所定のversion更新を行い、対象pathを個別にstageする。git diff --cached と git diff --cached --check を確認し、既存規約に従って git commit -m でcommitする。空なら省略する。

除外した変更がpullに干渉するときは、対象pathを限定して退避し、復元まで親が持つ。stashを使う場合もpathを明示し、参照を記録してapplyし、復元確認後にそのstashだけをdropする。除外ファイルを巻き込む一括stashや、その存在だけを理由にした停止はしない。

3. fetch・統合

確定したremote/branchをfetchし、ahead/behindを実測する。behindがあれば git pull --no-rebase --no-edit <remote> <branch> で統合する。対象規約が線形履歴を要求する場合だけ git pull --rebase <remote> <branch> を使う。

Git状態と統合判断は親が所有する。 親は共通祖先、双方の意図、残す条件を決め、stage、merge/rebase --continue、commit、push、path限定stashを行う。実コンテンツ競合の編集と原本/generator/hookの修正は、意図・条件を確定してからimplementation-delegation SSOTの既定担当へファイル編集だけを委譲できる。担当は git add、--continue、commit、pushをしない。親は返却diffを受け入れてからstageし、統合をcontinueする。既存generatorでの再生成、実測値の採用、gitlinkのfast-forward、既存のバックアップ付き配備処理などの機械処理は親が直接行ってよい。競合の統合では共通祖先と双方の差分を読み、意図を保つ最小変更を選び、同じ設定や関数を二重追加しない。競合があるだけで停止しない。

• 生成物・ロックファイル: 原本を統合して既存generatorで再生成する。
• 機種依存値: 今の環境で実測した値を使う。
• gitlink: submodule内で双方のcommitの祖先関係を確認する。包含側へ進め、分岐ならsubmodule内で統合・必要な検証・pushを済ませ、親のgitlinkを更新する。
• 退避の復元競合: 同じ手順で統合し、復元できたことを確認する。

競合pathだけをstageし、mergeなら git commit --no-edit、rebase等なら対応する --continue を実行する。無条件のours/theirs採用や未確認の変更破棄で済ませない。ユーザーが留保した仕様判断など、資料から決められない排他的な要件だけを具体化して確認する。

4. 失敗を解消して再開する

scriptやhookの非ゼロ終了は親への復旧情報であり、そのままターンを終了する指示ではない。失敗した層・原因・成功条件を実測し、必要な修正を行って失敗工程から再開する。検証の無効化で通さない。

• 配備コピー・リンクの不一致: 原本とのdiffを読み、配備先だけの有効な変更は原本へ統合する。既存内容を既存のバックアップ付き配備処理で保全して更新する。dotfilesでは etc/link.sh の既存配備関数を使い、必要な範囲だけを更新する。LINK_SH_LIB_ONLY=1 で読み込むと配備関数を利用できる。Cursorは materialize_cursor_skill で対象を更新する。
• generator・hook・検証失敗: 失敗層・原因・成功条件を実測する。原本/generator/hookのコード修正は親が意図と条件を決めてからimplementation-delegation SSOTの既定担当へファイル編集だけを委譲する。担当は git add、--continue、commit、pushをせず、親がdiffを受け入れた後に再生成、stage、continue、失敗した確認の再実行を行う。無関係な不具合は切り分け、独立して完了できる同期を進める。
• network・認証・権限: 利用可能な既存認証と環境の正規の権限申請を使う。失敗理由が分かり成功条件が変わったときだけ再試行する。実際の拒否は迂回しない。
• pushのnon-fast-forward: 再fetchして追加差分を統合し、必要な検証後に再pushする。

配備処理が既存の実ファイル・ディレクトリを保持してskipした場合は、終了コードだけで配備完了としない。その内容を原本と比較・統合し、既存のバックアップ処理で保全してから管理対象リンク・コピーを配備し直す。秘密や管理対象外の内容は原本へ混入させず保持する。

engineを使う場合、進行中のGit操作を完了し、原因を除去してから同じengineへ戻す。原因不明の同じコマンドを反復しない。

5. 完了確認とpush

統合後に必要な生成・配備更新を行い、その差分も個別stage・cached diff確認・commitする。関連する検証を通し、競合と未復元の退避がないことを確認して、確定したupstreamへ git push <remote> HEAD:<branch> する。承認を再要求しない。

対象repoごとにpush成功、ローカル・リモートHEADの一致、staged/unstaged/untrackedを実測する。独立repoをpushしてから親のgitlinkを更新し、親もpushする。残る変更はpathと理由（ユーザーの別作業・明示除外・実際のblocker等）を確認し、今回の自分の差分を理由なく残さない。最終報告は各反映先とcommit、意図的に残した差分を示し、一つのrepoの成功を全体の成功へ拡張しない。

継続できない場合

実行環境の拒否、利用できる認証がない、対象・送り先が確定できない、既存変更の保全ができない、ユーザーが留保した判断が必要な場合は、その条件に依存する操作だけを止める。独立した許可済み作業を完了し、観測した原因・試した復旧・必要な入力を一度に示す。dirty・競合・配備差分・hook失敗という状態名だけで確認や停止を選ばない。

git add -A / git add .、秘密のcommit、force push、reset --hard、hookの無効化、未保全のローカル変更破棄は禁止する。