ワンクリックで
compose-commit
git コマンドで変更ファイルを解析し、論理的な単位で適切な粒度のコミットを作成する。 ステージ済みまたは未ステージの git 変更が存在し、グループ化してコミットする必要がある場合に使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
git コマンドで変更ファイルを解析し、論理的な単位で適切な粒度のコミットを作成する。 ステージ済みまたは未ステージの git 変更が存在し、グループ化してコミットする必要がある場合に使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
セッションのコンテキストが肥大化したときに、現在のタスク状況・変更ファイル・作業サマリを収集し、 新しいセッションへ引き継ぐためのドキュメントを生成する。 会話が長くなって新しいセッションで作業を続けたい場合に使用する。
AI 特有の文章パターンを排除し、自然で簡潔な日本語テキストを生成・レビューする。 報告書・文書・その他の出力として自然で人間らしい日本語が求められる場合に使用する。 Japanese triggers: レポート、報告書、文書、まとめ、サマリー、日本語で書く、日本語で出力、自然な日本語
ベースブランチにマージ済みのローカル作業ブランチを安全に削除する。 リモートブランチの削除は明示的に指示された場合のみ実行する。 マージ済みブランチの整理、PR マージ後の古いブランチ削除、ローカルやリモートの refs の整頓時に使用する。
定量的かつ定性的な調査を通じて事実と意見を収集し、分析して 構造化されたレポートや提言として実行可能な知見を提供する。 市場動向、テクノロジー、競合分析など、複数の角度から調査が必要なテーマに使用する。
対話を通じてインタラクティブに Mermaid ダイアグラムを作成するスキル。 ユーザーが可視化したい内容を明確にし、ASCII アートでスケルトンを確認してから 合意が得られた時点で正確な Mermaid コードを生成する。 ダイアグラム、フローチャート、シーケンス図、ER 図、クラス図、状態図、 ガントチャート、マインドマップ、その他の可視化を求められた場合に使用する。 トリガー: 「図を描いて」「可視化して」「フローチャートを作って」「シーケンス図」 「ER 図」「クラス図」「状態機械」「ガントチャート」「Mermaid ダイアグラム」 「システムフローを図にして」「プロセスを図解して」「ダイアグラムにして」
記事の構造を情報依存グラフとして分析し、明確さ、物語の流れ、認知のしやすさを高めるために 各セクションを書き直す。記事、ブログ記事、エッセイ、技術文書の改善、再構成、書き直しを 求められた場合に使用する。
| name | compose-commit |
| description | git コマンドで変更ファイルを解析し、論理的な単位で適切な粒度のコミットを作成する。 ステージ済みまたは未ステージの git 変更が存在し、グループ化してコミットする必要がある場合に使用する。 |
| allowed-tools | ["Bash(git add *)","Bash(git branch *)","Bash(git commit *)","Bash(git config *)","Bash(git diff *)","Bash(git log *)","Bash(git stash *)","Bash(git status *)","Bash(git switch *)","Glob","Grep","Read","AskUserQuestion"] |
変更ファイルを解析して関連する変更をグループ化し、適切な粒度でコミットを作成する。
/compose-commit を実行するか「コミットして」と伝える変更内容とプロジェクトのコミットスタイルを確認する。これらのコマンドは独立しているので、すべて並行して実行する:
git branch --show-current
git config --get commit.gpgsign
git status
git diff --stat HEAD
git log --oneline -10
git stash list
GPG 署名が有効な場合(commit.gpgsign=true)、フラグを立てる。
この時点ではユーザーへの確認は不要。ステップ 4 の承認後、ステップ 5 の実行前に確認する。
git stash list にエントリがある場合、続行前にユーザーへ通知する:
注意: N 件のスタッシュがあります。今回のコミットから意図的に除外されていることを確認してください。
処理はブロックせず、情報を表示して続行する。
main または master ブランチにいる場合は必ずユーザーに確認する。
現在のブランチが main または master の場合、コミット前に AskUserQuestion で確認する:
AskUserQuestion({
questions: [{
question: "現在 main ブランチにいます。どのように進めますか?",
header: "ブランチの確認",
options: [
{ label: "作業ブランチを作成する", description: "コミット前に新しいブランチを作成する" },
{ label: "main にコミットする", description: "現在のブランチに直接コミットする" }
],
multiSelect: false
}]
})
「作業ブランチを作成する」が選択された場合、続けてブランチ名をテキスト質問で尋ね、git switch -c <branch> を実行してから続行する。
すでにステージ済みファイルがある場合、続行前に AskUserQuestion でユーザーの意図を確認する:
AskUserQuestion({
questions: [{
question: "すでにステージ済みのファイルがあります。どのように進めますか?",
header: "ステージ済みファイル",
options: [
{ label: "すべての変更を解析する", description: "未ステージの変更も含めて解析する(ステップ 2 へ)" },
{ label: "このままコミットする", description: "ステージ済みファイルのみをコミットする(ステップ 2 をスキップ)" }
],
multiSelect: false
}]
})
「すべての変更を解析する」が選択された場合、通常通りステップ 2 へ進む。
「このままコミットする」が選択された場合、git diff --cached でステージ済みの内容を確認し、すべてのステージ済みファイルを 1 つのコミットグループとして扱い、ステップ 4 へスキップする。
ファイルごとではなく、1 つのコマンドですべての差分を取得する:
git diff HEAD
出力を解析して各変更の意図を把握する。以下の観点から分析する:
追跡されていない新規ファイルは git diff HEAD に含まれないため、Read でその内容を確認する。
以下の原則に従って変更をグループ化する:
まとめてよい変更
別々のコミットにすべき変更
変更した 1 ファイルに複数の意図が混在している場合、git add -p による部分ステージングを検討する。
必ず実行前に確認する。 まず提案する計画をテキストで出力する:
提案するコミット(計 N 件):
コミット 1: feat(auth): JWT ベースの認証を実装する
ファイル:
- src/auth/jwt.ts(新規)
- src/auth/middleware.ts(変更)
- tests/auth/jwt.test.ts(新規)
コミット 2: chore: ESLint 設定を更新する
ファイル:
- .eslintrc.json(変更)
続けて AskUserQuestion を使用する:
AskUserQuestion({
questions: [{
question: "このコミット計画で進めますか?",
header: "コミット計画",
options: [
{ label: "進める", description: "提案通りにコミットを実行する" },
{ label: "修正する", description: "グループ分けやコミットメッセージを調整する" },
{ label: "キャンセル", description: "コミットせずに中断する" }
],
multiSelect: false
}]
})
「修正する」が選択された場合、具体的な変更内容をテキスト質問で尋ね、計画を調整してステップ 4 の最初から再提示する。
「キャンセル」が選択された場合、即座に停止する。
承認されたら、GPG が設定されていない場合はグループ順にコミットを作成する。
GPG フラグが立っている場合、コミット前に AskUserQuestion で確認する:
AskUserQuestion({
questions: [{
question: "GPG 署名が有効です。Claude Code はパスフレーズを入力できないため、このセッションのコミットには --no-gpg-sign を使用します。よろしいですか?",
header: "GPG 署名",
options: [
{ label: "自分で実行する", description: "ターミナルで手動実行するコマンドを出力する" },
{ label: "--no-gpg-sign でコミットする", description: "このセッションのみ GPG 署名をスキップする" },
{ label: "キャンセル", description: "コミットせずに中断する" }
],
multiSelect: false
}]
})
「キャンセル」が選択された場合、何も出力せずに停止する。
「自分で実行する」が選択された場合、コピー&ペーストで実行できるコマンドとしてコミット計画を出力して停止する。heredoc の解釈の問題を避けるため、git add と git commit コマンドは別々のブロックに分ける。メッセージは(heredoc を使わず)引用符で囲んだ文字列を使用する:
GPG 署名が必要です。ターミナルから以下のコマンドを実行してください:
---
### コミット 1: `feat(auth): JWT ベースの認証を実装する`
```bash
git add src/auth/jwt.ts src/auth/middleware.ts tests/auth/jwt.test.ts
```
```bash
git commit -m "feat(auth): JWT ベースの認証を実装する
既存のセッションベース認証を置き換えるために JWT を導入した。
Co-Authored-By: <model-name> <noreply@anthropic.com>"
```
---
### コミット 2: `chore: ESLint 設定を更新する`
```bash
git add .eslintrc.json
```
```bash
git commit -m "chore: ESLint 設定を更新する
Co-Authored-By: <model-name> <noreply@anthropic.com>"
```
「--no-gpg-sign でコミットする」が選択された場合、グループ順にコミットを作成する。
本文が必要な場合(変更の背景、理由、詳細を伝える必要がある場合):
git add <file1> <file2> ...
git commit [--no-gpg-sign] -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<変更の背景・理由・詳細>
Co-Authored-By: <model-name> <noreply@anthropic.com>
EOF
)"
本文が不要な場合(件名だけで意図が伝わる場合):
git add <file1> <file2> ...
git commit [--no-gpg-sign] -m "$(cat <<'EOF'
<type>(<scope>): <subject>
Co-Authored-By: <model-name> <noreply@anthropic.com>
EOF
)"
[--no-gpg-sign] は GPG フラグが立っており、ユーザーが承認した場合のみ含める。
すべてのグループが完了したら、git log --oneline -N(N = 作成したコミット数)でコミットを確認して一覧を報告する:
✓ 2 件のコミットを作成しました
abc1234 feat(auth): JWT ベースの認証を実装する
def5678 chore: ESLint 設定を更新する
Conventional Commits 形式を使用する:
<type>(<scope>): <subject>
<body>
| type | 使用場面 |
|---|---|
| feat | 新機能 |
| fix | バグ修正 |
| refactor | リファクタリング(振る舞いの変更なし) |
| test | テストの追加、更新 |
| docs | ドキュメントの変更 |
| chore | ビルド、CI、設定、その他のハウスキーピング |
| style | フォーマットの変更(振る舞いの変更なし) |
メッセージはプロジェクトで使用している言語で記述する(日本語プロジェクトなら日本語で記述する)。
.env などの認証情報を含むファイルをコミットに含める前に警告する。--no-verify を提案する。index.lock がすでに存在する(別の git プロセスが実行中。他のプロセスが保持していないことを確認してから .git/index.lock の削除を提案する)、ファイルのパーミッションエラー(影響するパスを報告する)、ディスク容量不足エラー(即座に報告して停止する)。git status の出力を表示する。<model-name> を現在使用している正確なモデル名(例: Claude Sonnet 4.6)に置き換える。