git-cmsg

Git コミットメッセージジェネレーター

すべての変更を自動でステージし、新しいファイルが安全にコミットできるかを LLM に判定させたうえで、Conventional Commits 形式のコミットメッセージを中国語で生成します。

使用する場面

• ユーザーがコード変更のコミットを希望している
• ユーザーがコミットメッセージの生成を依頼している
• ユーザーが「提交」、「commit」、「commit message」に言及している

Git タグの入口

• ユーザーがタグ付け、バージョンタグの更新だけを求めている場合、または /git-tag / $git-tag を明示的に呼び出した場合は、隣接する git-tag スキル を使用し、cyeam tag を直接呼び出します。
• /git-tag は小バージョンの更新が既定です。/git-tag major はメジャーバージョンの更新、/git-tag minor --dry-run はプレビューのみを行います。
• タグ付けだけの場合は、以下のステージング、コミットメッセージ生成、コミット確認の手順に進みません。
• ユーザーがコミットとタグ付けの両方を求めている場合は、ユーザーが許可したコミットを完了してから git-tag を使用します。通常のコミットで自動的にタグを付けることはありません。
• スキルファイルの変更は、コードのコミットやタグの作成を求めていることを意味しません。

Conventional Commits の仕様

形式：

<type>(<scope>): <subject>

<body>

BREAKING CHANGE: <description>
Closes #<issue>
Co-authored-by: {model_name} <{model_email}>

type、scope、特殊トークン（BREAKING CHANGE、Closes）を除き、すべて中国語で記述する必要があります。

種類

Type	中国語	場合
feat	新機能	新機能
fix	不具合修正	バグ修正
docs	ドキュメント変更	ドキュメントのみの変更
style	コード形式	書式、空白、セミコロン（ロジック変更なし）
refactor	リファクタリング	新機能でもバグ修正でもない変更
perf	パフォーマンス最適化	パフォーマンスの改善
test	テスト関連	テストの追加または修正
chore	ビルド／ツール／依存関係	ビルド、ツール、依存関係
ci	CI/CD 設定	CI/CD の設定
revert	コミットの取り消し	コミットの取り消し
build	ビルドシステム	ビルドシステムまたは外部依存関係

ルール

1. まずすべての変更を自動でステージします。 git add . を実行して、変更されたファイルと未追跡ファイルをすべて自動でステージします。ユーザーに手動で git add するよう求めてはいけません。
2. 新しいファイルの安全性を LLM が判定します。 未追跡／新規ファイルごとに、安全にコミットできるかを適切に判断します。ファイル名、拡張子、想定される内容、目的を考慮します。
3. すべてのファイルが安全なら、自動的に続行します。 LLM がすべてのファイルをコミットして問題ないと判断した場合、ファイルの安全性について確認のために停止する必要はありません。
4. ステージされた変更を分析します。 変更内容を把握するため、git diff --cached を実行します。推測してはいけません。
5. ユーザーの説明ではなく、変更内容から種類を決定します。 ユーザーが「更新」と言っていても、変更が機能を追加するものであれば feat を使います。
6. scope は省略可能ですが、付けることを推奨します。 変更されたファイルパス（パッケージ名、モジュール名、ディレクトリ）から推測します。1 つのコミットにつき scope は 1 つにします。
7. 件名： 中国語で、命令形を使い、末尾に句点を付けず、50 文字未満にします。方法ではなく、変更の内容と理由を簡潔にまとめます。
8. 本文： 中国語で、変更の理由を説明します。変更が複数ある場合は番号付きリストを使用します。1 行につき 1 つの変更を記述します。
9. 実装の詳細など、方法に関する情報はメッセージに含めてはいけません。
10. コミットはしますが、プッシュはしません。 git commit のみを実行します。git push は絶対に実行しません。
11. 必ずユーザーの確認を待ちます。 コミットメッセージを生成したら、ユーザーに提示して明確な同意を待ちます。ユーザーが返信する前に git commit を実行してはいけません。ユーザーから修正意見があった場合は、それに応じて調整したうえで、再度確認のために提示します。
12. 現在のエージェントの質問ツールを使用します。 Claude Code では AskUserQuestion を使用します。Codex では、そのツールが現在のモードで一覧にあり、利用可能かつ許可されている場合に request_user_input を使用します。構造化された質問ツールが利用できない場合、またはツール呼び出しが失敗した場合は、同じ質問を通常のテキストで尋ね、ユーザーの返答を待ちます。

判断 UI

このスキルでユーザーの判断が必要な場合は、以下の順序に従います。

1. Claude Code： 指定された question、header、options を使って AskUserQuestion を使用します。
2. Codex： 1 つの質問オブジェクトを使って request_user_input を使用します。header、安定した snake_case の id、question、2～3 個の選択肢を含めます。推奨する選択肢を先頭に置き、そのラベルの末尾に (Recommended) を付けます。
3. フォールバック： 現在のエージェントに構造化された質問ツールがなく、そのツールが利用不可、許可されていない、または失敗した場合は、同じ選択肢を通常のテキストで尋ねます。ユーザーが明確に選択するまで続行してはいけません。

現在の実行環境で利用できないツール名を作り出してはいけません。

コミット前のファイルチェック

まず自動でステージします： すべての変更を自動的にステージするため、必ず最初に git add . を実行します。

LLM によるファイルの安全性判断

ステージングする新規／未追跡ファイルごとに、LLM の判断能力を使ってコミットすべきかどうかを判断します。

判断基準：

1. ファイルの種類： ソースコード、設定ファイル、ドキュメント、バイナリ／blob のいずれですか？
2. ファイル名： 秘密情報、認証情報、一時データが含まれていることを示唆する名前ですか？
3. プロジェクトのコンテキスト： プロジェクトの言語／フレームワークに照らして、このファイルはリポジトリに含めるべきですか？
4. 常識的な判断： 同様のプロジェクトで、ほとんどの開発者がこのファイルをコミットしますか？

自動対応ルール：

• ✅ コミットして問題なし： ソースコード（.go、.py、.js、.ts、.java など）、設定ファイル（.json、.yaml、.yml、.toml）、ドキュメント（.md、.txt）、テスト、プロジェクトの一部であることが明らかなアセット。自動的に続行し、確認は不要です。
• ⚠️ ユーザーに確認： サイズの大きなバイナリファイル、不審な拡張子のファイル、秘密情報が含まれている可能性のあるファイル、または用途が不明なファイル。
• ❌ 自動削除： 以下の既知の危険なパターンに一致するファイル。これらを自動的にステージング解除し、ユーザーに通知します。

既知の危険なパターン（自動削除）

以下に一致するファイルは、確認せずに自動的にステージング解除します。

カテゴリ	パターン
IDE／エディター	.idea/、.vscode/、*.swp、*.swo、*~、.DS_Store
ビルド出力	*.o、*.a、*.so、*.exe、*.dll、*.pyc、__pycache__/、*.class、*.jar、*.war、dist/、build/、out/、target/
依存関係	node_modules/、vendor/、venv/、.venv/
秘密情報／認証情報	.env、*.pem、*.key、*.p12、credentials.*、*.secret、id_rsa*
ログ／一時ファイル	*.log、*.tmp、*.bak、*.cache、.cache/
OS ファイル	Thumbs.db、Desktop.ini、.DS_Store

ワークフロー

1. git add . → Auto-stage ALL changes (modified + untracked files)
2. git diff --cached --name-only → Get staged file list
3. Check for known bad patterns → Auto-unstage them, inform user
4. For remaining new files → LLM safety judgment
   a. If all judged safe → Proceed automatically (no user prompt)
   b. If uncertain/suspicious → Use Decision UI to confirm
5. If patterns suggest missing .gitignore:
   - Check if .gitignore exists and already covers these patterns
   - If not covered, propose .gitignore additions
   - Use Decision UI to ask: whether to create/update .gitignore
6. Proceed with commit message generation

.gitignore の扱い

• リポジトリのルートに .gitignore がない場合は、プロジェクトの言語／フレームワークに適したパターンを含むファイルの作成を提案します。
• .gitignore が存在しても、フラグが付いたファイルに対応するパターンが不足している場合は、不足パターンの追記を提案します。
• ユーザーの確認なしに .gitignore を変更してはいけません。
• ユーザーが .gitignore の更新を確認した場合は、.gitignore の変更をステージングし、chore タイプで同じコミットに含めます。

ワークフロー

1. git add .                        → Auto-stage ALL changes (no need to ask user to git add)
2. git diff --cached --stat         → Overview of changes
3. git diff --cached --name-only    → Staged file list
4. Pre-commit file check:
   a. Auto-unstage known bad patterns and inform user
   b. LLM safety judgment on new files
   c. If all safe → proceed automatically
   d. If uncertain → stop for user confirmation
5. git diff --cached                → Detailed diff (after any file removals)
6. Analyze: type + scope + subject + body
7. Add Co-authored-by trailer (fallback chain: model → client → omit):
   a. **Detect model name** (priority order, highest first):
      1. **Claude Code system prompt** - look for exact line: "You are powered by the model <model_name>"
      2. `~/.trae/traecli.yaml` → `model.name` field
      3. `$ANTHROPIC_MODEL` environment variable
      4. Self-identify from system prompt metadata
   b. **CRITICAL**: If system prompt says "ark-code-latest", use that EXACTLY. Do NOT translate to Claude 4.7 or any other model name"
   c. **Infer provider** from model name prefix (see Provider Mapping below)
   d. **If no prefix match**, infer provider from `$ANTHROPIC_BASE_URL` domain (see Base URL Fallback below)
   e. **If still unresolved**, omit the Co-authored-by line entirely — never use "Unknown"
   f. Format: `Co-authored-by: {model_name} ({provider}) <noreply@{provider_domain}>`

   Provider Mapping:
   | Prefix/Keyword        | Provider         | Domain              |
   |-----------------------|------------------|---------------------|
   | ark-*                 | ByteDance (ARK)  | volcesengine.com    |
   | glm-*, GLM-*          | Zhipu AI         | zhipuai.cn          |
   | claude-*, Claude*     | Anthropic        | anthropic.com       |
   | gpt-*, o1-*, o3-*     | OpenAI           | openai.com          |
   | deepseek-*            | DeepSeek         | deepseek.com        |
   | qwen-*, Qwen*         | Alibaba Cloud    | alibabacloud.com    |
   | doubao-*              | ByteDance        | bytedance.com       |
   | llama-*, Llama*       | Meta             | meta.com            |
   | gemini-*, Gemini*     | Google           | google.com          |
   | mistral-*, Mistral*   | Mistral AI       | mistral.ai          |

   Base URL Fallback:
   | Domain Pattern         | Provider         |
   |------------------------|------------------|
   | volces.com / ark.*     | ByteDance (ARK)  |
   | anthropic.com          | Anthropic        |
   | openai.com             | OpenAI           |
   | deepseek.com           | DeepSeek         |
8. ⚠️ MUST STOP: 使用 Decision UI 展示生成的 commit message 并等待用户确认
   - question: "生成的提交信息是否符合要求？\n\n提交信息预览：\n```\n{commit_message}\n```"
   - header: "提交信息确认"
   - id: "commit_message_action"
   - options: [
       { label: "提交并推送", description: "使用此提交信息进行提交并直接 push 到远程仓库" },
       { label: "确认提交", description: "使用此提交信息进行提交" },
       { label: "重新生成", description: "重新分析代码变更并生成新的提交信息" },
       { label: "取消操作", description: "取消当前提交操作" }
     ]
9. git commit -m "<message>"       → Execute commit (only after user confirms)
10. If user chose "提交并推送": git push  → Execute push (only after commit is successful)
11. Show git log -1 --oneline       → Confirm result

件名の例

良い例：

• feat(user): 新增用户注册接口
• fix(cache): 修复缓存过期时间未生效的问题
• refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数
• perf(query): 减少数据库查询次数
• chore(deps): 升级Gin框架至v1.9.0

悪い例：

• feat(user): 新增了一个用户注册的接口功能（冗長すぎます）
• fix: fix bug（スコープがなく、詳細もありません）
• update code（Conventional Commits に準拠していません）
• feat(user): add user register API（中国語ではありません）

本文の例

良い例：

refactor(handler): 优化指标打点逻辑并调整handleBinlogMessage参数

1. 重构emitCounter函数，移除固定name参数，内置指标名并通过tagkv传递维度信息
2. 调整handleBinlogMessage签名，新增topic参数用于传递binlog主题
3. 统一所有指标打点的标签格式，补充binlog主题、失败原因等维度信息
4. 调整日志和指标打点的关联逻辑，移除重复的指标调用

Co-authored-by: GLM-5.1 (Zhipu AI) <[email protected]>

悪い例：

fix: 修复了一些问题

- 改了代码
- 修了bug

（曖昧で、実質的な情報がありません）

エッジケース

• 変更がまったくない場合： git add . の結果、ステージングエリアが空の場合は、コミットする変更がないことをユーザーに伝えます。
• 1 つのコミットに複数のタイプが混在する場合： 最も重要なタイプを選びます。リファクタリングにバグ修正も含まれる場合、主な目的がバグ修正なら fix、構造の変更なら refactor を使います。
• 複数のスコープがある場合： 最も影響を受けるスコープを使います。特定のスコープが優勢でない場合は、スコープを省略します。
• 破壊的変更： 本文に必ず BREAKING CHANGE: フッターを追加します。
• 自動削除されたファイル： 既知の危険なファイルを自動的にステージング解除した後、コミット対象のファイルが残っていない場合は、そのことをユーザーに伝えます。