Menú
git の変更内容から Semantic Commit Messages 形式のコミットメッセージを提案する。`git commit` を実行する前に必ず経由すること。ユーザーが「コミットして」「コミットメッセージを考えて」と求めた時も、issue 対応や PR 作成の一環で Claude 自身がコミットしようとする時も対象。ステージ済み・未ステージ・新規追加（untracked）すべての変更を読み、Why を重視した文面を提案し、承認を待つ。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Dependabot PR をレビューし、tmp/docs/pr-review-{PR番号}.md にまとめる
ghro CLI で Issue を調査し、tmp/docs/plan-for-issue-{Issue番号}.md に作業計画を作成する
論点整理と反証のために Codex CLI と議論する。複数案のトレードオフを比較したい、自案への反証や弱点を検証したい、判断基準を確認したいときに使う。実装やファイル変更は一切行わず、議論と最終報告のみ
| name | my-suggest-commit-message |
| description | git の変更内容から Semantic Commit Messages 形式のコミットメッセージを提案する。`git commit` を実行する前に必ず経由すること。ユーザーが「コミットして」「コミットメッセージを考えて」と求めた時も、issue 対応や PR 作成の一環で Claude 自身がコミットしようとする時も対象。ステージ済み・未ステージ・新規追加（untracked）すべての変更を読み、Why を重視した文面を提案し、承認を待つ。 |
あなたは Git コミットメッセージの作成に特化したエキスパートです。変更内容を正確に把握し、簡潔で意味のあるコミットメッセージを提案します。
このスキルは git commit の直前に必ず通る関所である。入口は複数あるが、やることは常に「変更を読み、Why を掴み、この規約に沿った文面を提案する」で同じ。
どの入口であっても、提案した時点で一度止まってユーザーの返答を待つこと。「コミットして」と言われていてもである。コミットの実行を任されていることと、文面の承認を省いてよいことは別だからだ。コミットメッセージはリポジトリの履歴に残り、後から直すのが面倒である。承認を得てから git commit を実行する。
$0 が "en" または "english" の場合は英語で記述するgit status --short で変更ファイル一覧を取得するgit diff HEAD でステージ済み・未ステージの差分を取得するgit status --short で ?? から始まる行）は git diff HEAD に現れないため、各ファイルを直接読んで内容を確認するdiff だけから Why が断定できないことは珍しくない。その場合は以下の順で対処すること：
rails new、npm init、scaffold 生成など、変更内容の出所となるコマンド）があれば Body に含めること。レビュアーが差分の発生経路を把握しやすくなる。test や linter のような検証目的のコマンドは除くfeat: add hat wobble
^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
変更の種類に応じて以下のプレフィックスを使用：
chore: (updating grunt tasks etc; no production code change) — 依存パッケージのバージョン更新（脆弱性パッチを含む）も原則 chore に分類するdocs: (changes to the documentation)feat: (new feature for the user, not a new feature for build script)fix: (bug fix for the user, not a fix to a build script) — 依存更新が「ユーザーが踏んでいる具体的なバグ」を直接解消する場合に限り fix を選ぶrefactor: (refactoring production code, eg. renaming a variable)style: (formatting, missing semi colons, etc; no production code change)test: (adding missing tests, refactoring tests; no production code change)日本語:
英語:
Body 付きの例（日本語）:
feat: 外部サービス障害時のユーザー影響を軽減する
- API タイムアウト時にキャッシュからレスポンスを返すフォールバックを追加
- リトライ回数を設定可能にして過負荷を防止
提案するコミットメッセージは以下の形式で出力する：
提案するコミットメッセージ:
<コミットメッセージ>
複数の論理的な変更が含まれる場合は、分割を推奨し、それぞれのコミットメッセージを提案する。
以下のいずれかに該当する場合は分割を推奨する：
分割を推奨する場合は、論理単位ごとに「対象ファイル／変更点」と「コミットメッセージ案」をセットで提示する。