Back to skills
SKILL.md
Git Sync
ASecurity「git sync」「同期して」「pullしてpush」で、対象リポジトリの変更保全・差分統合・関連配備更新・pushまで実行する。 通常の競合や配備不一致は親が解消して継続する。ユーザーが /git-sync と入力したら使う。
- 8 stars
- 0 votes
- 0 copies
- 0 views
- Added September 23, 2026
Works with
Security analysis
100/100npx -y skills add coil398/dotfiles --skill git-sync --agent claude-codeAre you the author of Git Sync?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/coil398-git-sync)---
name: git-sync
description: >-
「git sync」「同期して」「pullしてpush」で、対象リポジトリの変更保全・差分統合・関連配備更新・pushまで実行する。
通常の競合や配備不一致は親が解消して継続する。ユーザーが /git-sync と入力したら使う。
argument-hint: "[リポジトリルート。省略時は cwd]"
---
# git-sync
同期依頼を、対象リポジトリのローカル変更保全、fetch、差分統合、必要な生成・配備更新、検証、commit、pushまでの実行依頼として扱う。これらを工程ごとに再承認させない。親が対象・統合判断・復旧・最終確認を持ち、実行可能な作業が残る間は途中報告だけで終了しない。
## 同期の範囲
- 対象を省略したら cwd の Git top-level を使う。対象リポジトリが管理する生成物、submodule、ホーム側の配備コピー・リンクも整合に必要な範囲で含む。ホーム配備であることだけを別依頼の理由にしない。
- dotfiles 本体は、同じ共有skills内の `dotfiles-autosync/SKILL.md` を読み、中央 engine に引き継ぐ。sync依頼をその起動承認として扱う。
- 無関係な別リポジトリの同期へは広げない。本体同期(dotfiles では `dotfiles-autosync` の engine)のあと、同じターンで `check-updates` を実行する。更新対象 root は、利用中 runtime のプラグイン・marketplace などの独立 clone を置くディレクトリのうち、親が実在を確認したものだけを明示する(例: Claude Code の `~/.claude/plugins/marketplaces`)。見つからなければ実行せず、その旨を報告する。手での `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>` を使う。
**実コンテンツの競合も親が判断して統合する。競合があること自体を確認ゲートにしない。** 共通祖先と双方の差分、現行仕様、周辺コードを読み、双方の意図を保持する最小の統合を行う。同じ設定や関数を単純に二重追加しない。
- 生成物・ロックファイル: 原本を統合して既存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・検証失敗: ログから同期対象の原本・依存・配備を修正して再生成し、失敗した確認を再実行する。無関係な不具合は切り分け、独立して完了できる同期を進める。
- 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の無効化、未保全のローカル変更破棄は禁止する。
Attribution
Comments
Loading comments…