git

Git ワークフロースキル

このスキルはランタイムに依存せず、Claude Code、OpenCode、Codex で動作します。現在のランタイムのシェル、読み取り、編集／書き込み、検索、質問ツールを使用してください。どのランタイムでも、AI による帰属を示すフッターを追加しないでください。

ランタイムに関する注意事項

• Claude Code：選択肢の提示には、利用可能な場合は AskUserQuestion を使用してください。
• OpenCode：選択肢の提示には、利用可能な場合は質問ツールを使用してください。
• Codex：対話形式での入力が必要な場合は、ユーザーに直接尋ねてください。
• 対話型の git コマンドが必要になる場合は、それを避け、非対話型の代替手段を使用してください。ランタイムが安全に操作できる場合を除き、git add -p は使用しないでください。それ以外の場合は、明示したファイルをステージするか、含めるファイルをユーザーに尋ねてください。

アトミックコミット

コミットする前に、すべての変更を確認し、論理的な単位に整理してください。

• 関連する変更をまとめる - 同じ機能、バグ修正、またはリファクタリングに関する変更はまとめます
• 関連しない変更を分ける - 異なる修正や機能は別々のコミットにします
• 単一の責務にする - 各コミットは個別に取り消せるようにします
• 関心事を混在させない - フォーマットの変更はロジックの変更と分けます

変更が複数の関心事にまたがる場合は、特定のファイルをステージして別々のコミットを作成してください。ランタイムが安全にサポートする場合に限り部分ステージを使用し、それ以外の場合は変更の分け方をユーザーに尋ねてください。

コマンド

/git（サブコマンドなし）

サブコマンドを指定せずに実行した場合は、以下のコミットワークフローをデフォルトで使用します。

/git help

利用可能なすべてのサブコマンドの一覧を表示します。以下をそのまま出力してください。

/git subcommands:

  commit [message]   — Commit staged/unstaged changes with conventional format
  commit-all         — Commit all changes as logical atomic commits, skipping junk files
  pr [context]       — Create a draft pull request for the current branch
  pr-update          — Push and update an existing PR description
  pr-pull-review     — Fetch PR review comments and address them
  help               — Show this help message

/git commit [message]

AI による帰属を示さずに変更をコミットします。

1. git status を実行して、コミットが必要な内容（未追跡ファイルを含む）を確認します
2. git diff を実行して変更を確認します
3. 変更を分析して論理的なグループに分けます。関連しない変更がある場合は、複数のコミットを作成します
4. 関連する変更をまとめてステージします
   • 特定のファイルの場合：git add <file1> <file2>
   • 部分ステージの場合：ランタイムがサポートする非対話型のパッチワークフローを使用するか、変更の分け方をユーザーに尋ねます
   • git status に表示された新規ファイル／未追跡ファイルも含めます
5. 従来の形式でコミットを作成します：type: description
6. AI による帰属を示すフッターを含めないでください
7. ユーザーが $ARGUMENTS にメッセージを指定している場合は、コミットのコンテキストとして使用します
8. コミット後、ランタイムの質問方法を使って、プッシュするかどうかをユーザーに尋ねます
9. プッシュする場合、main ブランチにいなければ、PR を作成するかどうかをユーザーに尋ねます
10. 作成する場合は、適切なタイトルと説明を指定して gh pr create --draft を使用します

/git commit-all

不要そうなファイルをスキップしながら、作業ツリーの変更を論理的かつアトミックなコミットにまとめます。

1. git status を実行し、ステージ済み、未ステージ、未追跡の変更をすべて確認します
2. 不要なファイルを除外します — 次のファイルはステージングまたはコミットしないでください：
   • OS のアーティファクト：.DS_Store、Thumbs.db、Desktop.ini、._*
   • エディター／IDE のファイル：.idea/、.vscode/settings.json、*.swp、*.swo、*~
   • ビルドアーティファクト：_build/、deps/、node_modules/、dist/、*.beam
   • 一時ファイル／デバッグファイル：*.log、*.tmp、*.bak、*.orig、dump.rdb
   • シークレット：.env、.env.*（ただし .env.sample、.env.example は除く）、credentials.*
   • .gitignore のパターンですでに対象となっているファイル
   • ファイルが必要かどうか判断できない場合は、ランタイムの質問機能を使ってユーザーに確認します
3. git diff と git diff --cached を実行し、すべての変更を確認します
4. アトミックなコミットのルールに従い、変更を論理的なコミットにグループ化します：
   • 変更されたファイルをすべて分析し、それぞれがどの関心事に属するかを判断します
   • 機能、修正、リファクタリング、または領域ごとにグループ化し、各グループを1つのコミットにします
   • フォーマット／スタイルの変更はロジックの変更と分けます
   • マイグレーション、スキーマの変更、およびそれに対応するコードはまとめます
   • テストファイルは、テスト対象のコードとまとめます
5. 各論理グループについて、依存関係の順序（例：使用するコードより先にマイグレーション）に従って次を行います：
   • そのグループのファイルのみをステージングします：git add <file1> <file2> ...
   • Conventional Commits 形式でコミットします：type: description
   • AI の帰属を示すフッターは含めないでください
6. すべてのコミット後、コミット数、ファイル、簡潔なログを含むコミット内容の概要を表示します
7. ランタイムの質問機能を使って、プッシュするかどうかをユーザーに尋ねます
8. プッシュする場合、main ブランチ以外にいるなら、PR を作成するかどうかをユーザーに尋ねます

/git pr [context]

現在のブランチのプルリクエストを作成します。

1. git status で未コミットの変更がないか確認します
2. 未コミットの変更がある場合：
   • git diff を実行して確認します
   • アトミックなコミットのルールに従い、必要に応じて複数のコミットを作成します
   • Conventional Commits 形式でステージングしてコミットします
   • AI の帰属表示は含めないでください
3. git log で現在のブランチと最近のコミットを確認します
4. プッシュされていないコミットをリモートにプッシュします
5. ベースブランチを特定します（デフォルトブランチは git remote show origin で確認し、確認できない場合は 'main' を使用します）
6. 次の内容で gh pr create --draft を使って PR を作成します：
   • Conventional Commits 形式の明確なタイトル
   • 次の内容を含む詳細な本文：
     • 箇条書きの概要セクション
     • 領域ごとに整理した変更の詳細
     • チェックリスト項目を含むテスト計画
     • 該当する場合は、破壊的変更またはマイグレーションに関する注意事項
   • AI の帰属表示や生成元を示すフッターは含めないでください
7. ユーザーが $ARGUMENTS にコンテキストを指定している場合は、PR のタイトル／説明に使用します
8. PR の URL をユーザーに返します

/git pr-update

現在のブランチをプッシュし、PR の説明を更新します。

1. Git リポジトリ内にいることを確認し、現在のブランチ名を取得します
2. 未コミットの変更がないか確認し、ある場合はユーザーに知らせます
3. 現在のブランチを origin にプッシュします（ブランチがリモートに存在しない場合は -u フラグを使用します）
4. gh pr view で PR が存在するか確認します
5. PR が存在する場合：
   • 現在の PR 番号と詳細を取得します
   • git log で PR 作成以降のコミットを分析します
   • 次の内容を含む更新後の説明を作成します：
     • すべての変更の概要
     • 含まれるコミットの一覧
     • 関連する場合はテスト計画の更新
   • gh pr edit で PR を更新します
6. PR が存在しない場合：
   • 作成するかどうかをユーザーに尋ねます
   • 作成する場合は、main/master から分岐して以降のすべてのコミットを分析します
   • gh pr create --draft で詳細な PR を作成します
7. PR の URL と更新内容の概要を表示します

/git pr-pull-review

PR のレビューコメントを取得し、対応します。

1. 現在のブランチ名を取得し、関連する PR を見つけます：
   • gh pr view --json number,url,title を実行して PR の詳細を取得します
   • PR が存在しない場合は、ユーザーに伝えて停止します
2. すべてのレビューコメントを取得します：
   • gh pr view --json reviews,comments を実行して、PR のトップレベルコメントを取得します
   • gh api repos/{owner}/{repo}/pulls/{number}/comments を実行して、インラインレビューコメント（ファイル固有のコメント）を取得します
   • 未解決かつ対応が必要なコメントのみを対象にし、以下は除外します：
     • すでに解決済みのコメントスレッド
     • 承認のみ、または「LGTM」のコメント
     • ボットのコメント（CI、リンターなど）
3. 各レビューコメントの番号付き概要をユーザーに提示します：
   • インラインコメントの場合：ファイル、行、コメント本文を表示します
   • 一般コメントの場合：コメント本文を表示します
   • ランタイムの質問機能を使用して、対応するコメント（すべて、特定の番号、またはスキップ）をユーザーに確認します
4. ユーザーが対応を希望した各コメントについて：
   • 該当ファイルを読み、状況を把握します
   • 要求された変更を実装します
   • コメントの意図が曖昧な場合、または提案に同意できない場合は、変更を加える前にランタイムの質問機能を使用してユーザーに確認します
5. すべての変更を行った後：
   • アトミックコミットのルールに従い、関連するレビュー修正をまとめます
   • 次の形式でコミットします：fix: address PR review — <brief summary>
   • AI 帰属フッターを含めないでください
6. 対応した各コメントに PR 上で返信します：
   • gh api repos/{owner}/{repo}/pulls/{number}/comments/{comment_id}/replies -f body="Addressed in <commit-sha>" を実行します
   • トップレベルコメントには、gh pr comment --body "Addressed: <summary of what was fixed>" を使用します
7. 変更をプッシュし、対応内容の概要を示します

コミットメッセージの形式

type: concise description

Optional body for context

タイプ： feat、fix、chore、docs、refactor、test、style

エラー処理

エラーが発生した場合：

• 何が問題だったのかを明確に説明します
• 修正方法または代替案を提案します
• 再試行するか、手動で対応するかをユーザーに確認します

$ARGUMENTS