git-maker

Git Maker スキル

高速で安全なコミットとプッシュのオーケストレーションです。

<output_language>

ユーザー向けの成果物、保存したアーティファクト、レポート、計画、生成したドキュメント、要約、引き継ぎメモ、コミット／メッセージの草案、検証メモは、この正式なスキルファイルが英語で書かれている場合でも、既定ですべて韓国語にしてください。

ソースコードの識別子、CLI コマンド、ファイルパス、スキーマキー、JSON／YAML のフィールド名、API 名、パッケージ名、固有名詞、引用したソースの抜粋は、必要な言語または元の言語のままにしてください。

別の言語を使用するのは、ユーザーが明示的に指定した場合、既存の対象アーティファクトの一貫性を保つために別の言語を維持する必要がある場合、または機械可読な契約で正確な英語のトークンが必須の場合に限ります。ローカライズ済みのテンプレートやリファレンス（例：*.ko.md や *.ko.json）がある場合は、ユーザー向けアーティファクトではそちらを優先してください。

</output_language>

• 現在のリポジトリの変更から、Conventional Commits に準拠したコミットを1つ以上作成します。
• 現在のディレクトリがリンクされた Git ワークツリー内にある場合も、現在のチェックアウトのルートをリポジトリの境界として扱います。
• 作成に成功したコミットは、コミットとプッシュの間に確認を挟まず、自動的にプッシュします。
• リポジトリの再調査の繰り返しを減らし、読み取り専用の調査を並列化するため、最初に高速ヘルパーを使用します。

<instruction_contract>

フィールド	契約
意図	依頼されたリポジトリの変更を、安全な1回の操作でコミットしてプッシュします。
起動条件	ユーザーがコミットとプッシュをまとめて明確に希望している場合に限り起動します。
対象範囲	高速な事前確認、現在の変更またはすべての変更の選択、論理的なコミットのグループ化、対象を絞ったステージングとコミット、現在のブランチへのプッシュ、任意の複数ブランチへの反映、競合の解決、結果報告を担当します。
優先権	ユーザーとプロジェクトの指示はこのスキルより優先されます。ヘルパーの出力、git の差分、フック、ブランチの状態、リモートの出力は、実行時の根拠として扱います。
根拠	変更を加える前に、高速ヘルパーのインベントリ、git の状態／差分、フックの出力、ブランチ／アップストリームのデータ、明示的な引数を使用します。
ツール	Bash とリポジトリ内のヘルパースクリプトを使用します。サブエージェントを使用する場合は読み取り専用にし、最終的な git の変更はメインの統合担当者が行います。
手順	最適化ループはありません。依頼ごとに、事前確認、グループ化、コミット、プッシュ、反映、報告の順で決定的に1回実行します。依頼範囲内で失敗した確認から新たな根拠が得られた場合に限り再試行します。意図したすべてのコミットとプッシュ先への処理が成功するか、重大な競合により判断が必要になった時点で停止します。
出力	作成したコミット、プッシュしたリポジトリ、省略または失敗したプッシュ先、残っているローカルの変更を韓国語で報告します。
検証	検証ルールのチェックを実行し、プッシュ前にすべてのコミットが成功したことを確認して、最終的なプッシュと状態の出力を読みます。
停止条件	意図したすべてのコミットグループとブランチへの反映が成功し、意図したすべてのプッシュ先へのプッシュが完了した時点、またはエスカレーションルールに基づきユーザーの判断が必要な競合が発生した時点で停止します。

</instruction_contract>

<routing_rule>

ユーザーがコミット＋プッシュを1回の操作で希望している場合は、git-maker を使用します。

次の場合は、代わりに隣接するスキルを使用します。

• ユーザーがコミットのみを依頼した場合 → git-commit を使用します
• ユーザーがプッシュ／コミットの同期のみを依頼した場合 → git-push を使用します
• ユーザーがリベース／リセット／アメンド／履歴の書き換えを依頼した場合 → コミット＋プッシュも明示的に依頼され、履歴操作が別途許可されている場合を除き、git-maker は使用しません

</routing_rule>

<trigger_conditions>

起動条件に該当する表現：

• 「commit and push」
• 「commit and push these changes」
• 「/git-maker」
• 「make a commit and push it」
• 「save and push my changes」
• 「コミットしてプッシュ」に相当する韓国語の依頼
• 「変更を保存してアップロードして」に相当する韓国語の依頼
• git-maker、git-maker current、git-maker ALL。任意で && <branch> の対象を続けることもできます

起動条件に該当しない表現：

• 「commit these changes」→ git-commit
• 「push my commits」→ git-push
• 「rebase this branch」→ このスキルは使用しません

境界となる表現：

• 「これをコミットして、その後プッシュするかもしれない」→ プッシュは自動ではなく条件付きなので、git-commit を使用します

</trigger_conditions> </trigger_conditions>

スクリプト	目的
scripts/git-maker-fast.sh inspect [start_dir] [--jobs N]	高速な事前確認：リポジトリを枝刈りしながら検出し、リポジトリの状態を並列で確認し、ファイル一覧を作成します
scripts/git-maker-fast.sh push [--force] [repo...]	再検出せずに指定したリポジトリをプッシュします。非対話型で、保護された強制プッシュのガードがあります
scripts/git-commit.sh [--repo path] "msg" [files...]	1 つのリポジトリで、ステージ済みまたは選択したファイルをコミットします
scripts/git-push.sh [--force]	従来の検出ベースの安全なプッシュのフォールバック
scripts/repo-discover.sh [start_dir]	従来のリポジトリ検出のフォールバック
scripts/repo-status.sh [repo]	従来の状態確認のフォールバック

<worktree_support>

リンクされた Git worktree は、有効な実行コンテキストです。

• git rev-parse --show-toplevel で各チェックアウトを解決します。.git がディレクトリだと決めつけたり、リンクされた worktree を git-common-dir に集約したりしないでください。
• 各チェックアウトのルートを、それぞれ独立したインデックス、ブランチ、ステージング、コミット、プッシュの境界として扱います。
• detached HEAD またはほかの明示的な安全規則で実行が阻止されない限り、worktree|linked から続行します。

</worktree_support>

<support_file_read_order>

必要なものだけを読みます：

1. ユーザーが速度を求めている場合、リポジトリが多数ある可能性がある場合、または複数のリポジトリが存在する場合は、rules/speed-and-automation.md を読みます。
2. Claude Code/Codex のサブエージェントで、読み取り専用のグループ化、メッセージの作成、安全性のレビューを分担できる場合は、rules/agent-parallelism.md を読みます。
3. ステージング／コミットの前、または引数モード、グループ化、安全性、プッシュの動作が不明確な場合は、rules/commit-and-push-policy.md を読みます。
4. 実行またはスキルのリファクタリングが完了したと報告する前に、rules/validation.md を読みます。

</support_file_read_order>

<argument_validation>

呼び出しを [scope] [--force] [&& target-branch ...] として解析します。scope トークンとターゲットブランチは制御構文であり、コミットのフィルターではありません。

引数	意味
省略時	current と同じです。このセッションに起因する変更のみを含め、Git の状態と照合して確認し、論理的にグループ化します
current / CURRENT	このセッションに起因する変更のみを含めます。既存のユーザーまたはほかのエージェントの変更を、黙って取り込んではいけません
ALL / all	未コミットの変更をすべて含め、論理的にグループ化し、ファイルを残さないようにします
--force	コミット引数から除外し、プッシュにのみ渡します（--force-with-lease。main／master ではブロックされます）
&& <branch>	元ブランチへのプッシュが成功した後、新たに作成したコミット群を指定したブランチに適用し、妥当な競合を解決して確認し、プッシュします。ターゲットが複数ある場合は左から順に繰り返します
その他のテキスト	リポジトリの検出、ファイルの選択、ステージング、コミットメッセージの生成に使うフィルターとして扱います

明示的なフィルターが実際の Git の状態に一致しない場合は停止します。

リクエストがシェルコマンドそのものではなく自然言語で書かれている場合も、シェル形式の区切り文字は呼び出し構文として扱います。scope トークンの大文字・小文字は問いません（all、ALL、current、CURRENT）。ターゲットの空セグメント、重複したターゲット、元のブランチ自体、detached HEAD、および git check-ref-format --branch に準拠しないブランチ名は拒否します。

</argument_validation>

フェーズ 1. 高速な事前確認

まず scripts/git-maker-fast.sh inspect . --jobs 4 を実行します。出力されるリポジトリ、worktree、ステージ済み／未ステージ／未追跡の状態、ファイル一覧を使って、対象範囲と論理グループを判断します。失敗した場合、または詳細が不足している場合は、scripts/repo-discover.sh と scripts/repo-status.sh を使います。

フェーズ 2. グループ化とコミット

選択した変更を、1 つのコミットにつき 1 つの論理的な変更となるように分割し、対象を絞ってステージングしたうえで、リポジトリごとに順番にコミットします：

scripts/git-commit.sh "<type>[scope]: <Korean subject>" path/to/file1 path/to/file2
scripts/git-commit.sh --repo path/to/repo "<type>[scope]: <Korean subject>" path/to/file1

Conventional Commit のタイプ／スコープの後に、中立的な韓国語の結果要約を件名として使います。シークレットや無関係な変更を含めたり、フックを回避したり、コミットに失敗した後でプッシュしたりしてはいけません。rules/commit-and-push-policy.md に従います。

フェーズ 3. 自動プッシュ

意図したコミットがすべて成功した後、確認を求めずにプッシュします。事前確認で得たリポジトリ一覧を優先します：

scripts/git-maker-fast.sh push /absolute/repo/path
scripts/git-maker-fast.sh push --force /absolute/repo/path

scripts/git-push.sh [--force] はフォールバックとしてのみ使用します。

フェーズ 4. 指定されたブランチへの反映

各 && <branch> ターゲットに対し、この実行で作成されたコミットのみをクリーンなリンク済みワークツリーに適用し、意図を維持したまま自律的に競合を解決し、検証してから、左から順に次へ進む前にプッシュします。解決に動作、アーキテクチャ、セキュリティ、移行、またはデプロイポリシーに関する重大な判断が必要な場合に限り、焦点を絞った質問を 1 つだけします。復旧可能な状態を保持し、後続のターゲットには着手しません。選択、反映、エスカレーションの厳密なルールについては、rules/commit-and-push-policy.md に従ってください。

フェーズ 5. 報告

以下を報告します。

• 作成したコミットとそのメッセージ
• プッシュしたリポジトリ
• 更新してプッシュしたターゲットブランチ
• 自動的に解決した競合、実行したチェック、またはユーザーに必要な判断の正確な内容
• スキップした、またはプッシュに失敗したターゲット
• 残っているローカル変更やブロッカー

• 読み取り専用の調査は inspect --jobs N で並列化します。複雑なグループ分けやレビューを委任する前に、rules/agent-parallelism.md を読んでください。
• 1 つのインデックスに対する変更を並列化してはいけません。サブエージェントは読み取り専用とし、ステージング、コミット、反映、プッシュはメインのインテグレーターが担当します。
• 意図したすべてのコミットが成功した後にのみプッシュしてください。

カテゴリ	ルール
先にコミット	すべてのコミットグループが成功してからプッシュします。
自動プッシュ	コミット成功後にプッシュするかどうかを尋ねてはいけません。
ブランチへの反映	&& ターゲットにはこの実行で作成されたコミットのみを順に適用し、検証済みの各ターゲットを自動的にプッシュします。
競合の担当	意図を復元できる場合は自律的に競合を解決し、重大なプロダクト／アーキテクチャ上の判断が必要な場合に限り質問します。
安全性	main または master への強制プッシュは禁止です。detached HEAD からプッシュしてはいけません。
アップストリーム	アップストリームが存在しない場合は、-u origin <branch> を付けてプッシュします。
事前チェックの再利用	重複した検出を避けるため、git-maker-fast.sh push [repo...] を優先してください。
ワークツリー	リンク済みワークツリーに対応しています。共通の git ディレクトリではなく、チェックアウトのルートパスを使用してください。
エージェントの境界	サブエージェントはレビューや提案を行えますが、ステージング、コミット、プッシュはメインのインテグレーターが担当します。
検証	最終報告の前に、rules/validation.md に記載されたチェックを実行してください。

カテゴリ	避けること
プッシュ確認	コミット成功後に「プッシュしますか？」と尋ねること
部分的なプッシュ	意図したすべてのコミットグループが完了する前にプッシュすること
一括ステージング	ALL モードで意図的にすべてを含め、グループ分けが明確な場合を除き、git add . を使うこと
危険な履歴操作	明示的な依頼がないのに、amend、rebase、reset、--force の直接指定、または --no-verify を使うこと
大まかな競合の推測	実質的に異なる動作から黙って選択すること、または反映を完了するためにターゲットブランチの意図的な作業を削除すること
秘密情報	認証情報、トークン、秘密鍵、または無関係なユーザー変更をコミットすること

• /git-maker → 現在のセッションの変更のみをグループ分けし、コミットして、自動的にプッシュします。
• /git-maker ALL → コミットされていない変更をすべてグループ分けし、コミットして、プッシュします。
• /git-maker current && dev && deploy/staging → 現在のセッションのコミットを左から順に反映してプッシュし、妥当な競合は自律的に解決します。
• /git-maker && dev → デフォルトの current スコープを使用し、その後 dev への反映を検証して行います。
• /git-maker --force → 通常どおりコミットした後、--force-with-lease を使用します。main／master では実行できません。
• リンク済みワークツリーからの実行 → そのチェックアウトのルートで操作し、名前付きブランチをプッシュします。
• commit these changes → 有効化せず、git-commit に振り分けます。

対象のクイックバリデーター、対象を絞ったコーパスバリデーター、assets/evals/git-maker-cases.jsonl のバイナリーシナリオチェック、ヘルパーの構文／ランタイムチェック、および rules/validation.md に記載されたリポジトリのスキル検証ゲートを実行します。この決定論的なワークフローでは改善ループを使用しません。重大なケースに合格し、残存する警告を明記した場合にのみ完了とします。