git-commit

Git Commit

目标

仅包含预期的变更 → 逻辑拆分 → 信息描述变更内容和原因

预解析任务包（快速路径）

当主代理已经完成范围分析并提供任务封包时，执行代理可以走快速路径，跳过重复扫描对话历史和无关目录。任务封包必须同时包含以下字段：

scope: [允许提交的仓库相对路径或绝对路径]
exclude: [明确排除的工作区修改]
groups:
  - type: publish
    scope: ai-plugins
    emoji: 📢
    files: [本组文件列表]
    summary: 发布元数据
verification: [每组提交前后的最小验证命令]
identityCheck:
  client: 客户端名称及 allowlist 结果
  model: 模型名称及 allowlist 结果
  trailer: 追加或不追加 Co-authored-by 的结论

快速路径的硬门槛：

1. 先用 git status --short --branch、git diff --cached 和目标组文件清单确认封包仍与工作树一致；不一致时退回完整工作流程并报告差异。
2. 只允许暂存 scope 和当前 groups 的文件，exclude 中的修改始终保持未暂存；禁止回退范围外文件。
3. 仍必须执行 staged diff 审查、敏感信息扫描、commitlint、最小验证、提交后 git log -1 与 git status 复核；快速路径只能省略重复发现，不能省略证据门。
4. 同一任务只解析一次远程或本地 commit-types.ts，后续分组复用 type/emoji 结果；identityCheck 也只按封包结论执行一次，不重复猜测。
5. 每个提交返回 commit hash、提交正文、实际文件集合和原始验证输出；最终确认没有 commit-message.txt 或其他临时文件残留，且不执行 git push。

如果封包缺少任一字段、白名单含糊或验证命令不可复现，不得使用快速路径。

规则来源优先级 [CRITICAL]

生成提交信息时，按以下优先级决策，低优先级不得覆盖高优先级：

1. 用户在当前对话中的明确要求
2. 当前仓库本地 commit / commitlint 规则（如 commitlint.config.*、.commitlintrc*、package.json 中的 commitlint 字段、commit-msg hook）
3. 远程 raw commit-types.ts（首选）+ 本地 commit-types.ts（fallback，详见步骤 6）
4. 技能默认模板、示例与 references/commit-message-template.md

• 若多个来源冲突，必须以更高优先级来源为准。
• 若更高优先级来源缺失或读取失败，必须停下说明，不得猜测。若来源内容完整但含义明确（如 commitlint 规则已定义 scope 列表等），直接按规则执行即可。

工作流程（清单）

1. ステージング領域と作業ツリーの状態を確認する（ステージング領域を優先）

   • git status
   • まず、ステージング領域に内容があるか確認します：git diff --cached --stat
     • ✅ ステージング領域にファイルがある：今回のコミットはステージング領域のみを対象とし、追加のファイルを独自に git add しないでください。ステップ 4 に進み、ステージング済みの内容を確認します。
     • 📭 ステージング領域が空：この場合に限り、作業ツリーからファイルを選んでステージングする必要があります。ステップ 2～3 に進みます。
   • 作業ツリーの変更を確認する必要がある場合：git diff または git diff --stat

2. コミットの範囲を決める（必要に応じて分割）［「カテゴリ別の分割ルール」を参照］

   • まず対象ファイルの範囲を確定します［CRITICAL］：
     • ユーザーの指示を注意深く読み、今回のコミットに含めるファイルの範囲（例：「関連するファイルのみ処理する」「変更したファイルのみ処理する」「xx ディレクトリをコミットする」）を確認します。
     • 作業ツリーにある対象範囲外のファイルを一覧にし、未コミットの変更があってもステージングしないでください。
     • 対象範囲外のファイルに対して、git checkout --、git restore、git reset などの巻き戻し操作を絶対に実行しないでください。変更の出どころや意図は判断できず、巻き戻すとデータを失う可能性があります。
     • 対象範囲外のファイルに未コミットの変更がある場合は、最終報告で「以下のファイルには未コミットの変更がありますが、今回のコミット対象には含めていません」とユーザーに伝え、処理を判断してもらいます。
   • まずコンテキストを分析します：会話中のユーザーによる変更内容の説明を注意深く読み、今回の変更の業務上の意図を理解します。
   • 4 つの観点に基づく分割基準：
     1. ファイルの種類：設定ファイル vs ソースコード vs ドキュメント vs テストファイル
     2. 業務機能モジュール：異なる業務モジュールの変更は別々にコミットします（例：auth vs payment）
     3. 変更の種類：機能追加 vs Bug 修正 vs リファクタリング vs フォーマット変更（異なる type の変更は分けます）
     4. 変更の範囲：フロントエンド vs バックエンド、依存関係のアップグレード vs 動作変更、本番コード vs テストコード
   • 1 つのファイルに複数種類の変更が混在している場合は、パッチによるステージング（patch staging）を計画します。

3. 次のコミットに含める内容のみをステージングします（ステージング領域が空の場合に限り実行）

   • 複数の変更が混在している場合は、パッチによるステージングを優先します：git add -p
   • ハンク／ファイルのステージングを解除します：git restore --staged -p または git restore --staged <path>

4. 実際にコミットする内容を確認します

   • git diff --cached
   • コンプライアンスチェック：
     • シークレットやトークンが含まれていないこと
     • 意図しないデバッグログが含まれていないこと
     • 無関係なフォーマット変更が含まれていないこと
   • チェックに合格したらそのまま続行します：上記 3 項目のチェックにすべて合格した場合、「機密情報が含まれているか」をユーザーに尋ねるために処理を中断しないでください。ステップ 5 に進みます。不審な内容が見つかった場合に限り、ユーザーに確認します。

5. コミットメッセージを作成する前に、ステージング済みの変更を 1～2 文で説明します

   • 「何を変更したか？」＋「なぜか？」
   • 明確に説明できない場合、コミットの範囲が広すぎるか、複数の変更が混在している可能性があります。ステップ 2 に戻ります。

6. コミットメッセージを作成します

   • 言語の選択（デフォルトは中国語。コンテキストに応じて切り替え）：
     • デフォルトでは、コミットメッセージを中国語で作成します。
     • 例外：英語を使用するオープンソース／上流リポジトリに PR を送る場合（git log の最近のコミットがすべて英語の場合）は、英語で作成します。判断基準：
       • 現在のブランチの上流ターゲットリポジトリにおけるコミットの言語スタイルを確認します（git log --oneline の直近 5～10 件）
       • 上流／ターゲットリポジトリがすべて英語を使用している場合 → 英語に切り替えます
       • それ以外の場合 → デフォルトの中国語を維持します
     • 中国語・英語のいずれの場合も、summary と body の言語は統一してください。
   • Conventional Commits を使用します（必須）：
     • 通常のコミット：<emoji> type(scope): summary
     • 破壊的変更：<emoji> type(scope)!: summary（感嘆符は ) の直後、コロンの前に置きます）
     • （空行）
     • body（実装の手順ではなく、内容／理由）
     • footer：破壊的変更の場合は BREAKING CHANGE: <説明> の行を必ず含めます
   • Emoji と Type のルール：commit-types.ts の定義を必ず確認して従い、次の優先順位で取得します：
     • 第一選択（最新の状態を確保するためのリモート raw）：GitHub から最新の定義を取得します：
       • https://raw.githubusercontent.com/ruan-cat/monorepo/dev/configs-package/commitlint-config/src/commit-types.ts
       • リモートファイルが正規の情報源です。type／emoji の対応を最新に保つため、優先して使用してください。
     • 第二選択（スキルに同梱されたローカルファイル）：リモート raw の取得に失敗した場合（ネットワークが利用できない／タイムアウト／HTTP エラー）、このスキルのディレクトリ内にある references/commit-types.ts にフォールバックします。
       • このファイルを読み込み、commitTypes 配列を解析して、今回使用する type を特定します。
       • このファイルはスキルと一緒に配布されるスナップショットのコピーです。リモートより古い可能性がありますが、オフラインでも利用できます。
     • 検索結果の概要やキャッシュだけを根拠に emoji を判断することは禁止です。ファイル全体を読み、該当する type を特定してください。続行する前に、今回の解析結果として selected type、resolved emoji、一致した元の箇所を明示的に言い直してください。
     • 同じタスクに複数の論理的なコミットが含まれる場合、解析は最初のグループで 1 回だけ行います。後続のグループでは確認済みの対応を再利用し、実行記録にその旨を記載してください。再度読み込んだり推測したりしないでください。
     • リモートとローカルの両方から取得できない場合は、処理を停止し、「commit-types.ts を取得できず、正当な type と emoji を特定できません」と報告してください。推測や古い表へのフォールバックは禁止です。
   • ファイルを使う方法を推奨します（シェル引数の受け渡しによる文字コードやエスケープの問題を避けるため）：
     • 中国語を含むコミットメッセージには、デフォルトで git commit -F commit-message.txt を使用します
     • 一時的なコミットメッセージファイル（例：commit-message.txt）を作成し、コミットメッセージを書き込みます
     • ⚠️ このステップではコミットメッセージファイルの作成のみを行い、git commit は実行しないでください。実際のコミットはステップ 9 で実行します。
   • ステップ 6 で処理を止めてコミットメッセージをユーザーに提示して終わらないでください。ステップ 7→8→9 に進み、コミットの全工程を完了します。
   • テンプレート形式と BREAKING CHANGE の例は references/commit-message-template.md を参照してください。ただし、その内容を emoji／type の正解として扱わないでください。

7. コミットメッセージを事前検証します［CRITICAL］

   • まず、現在のリポジトリにローカルのコミットルールが存在するか確認します：commitlint.config.*、.commitlintrc*、package.json の commitlint フィールド、commit-msg フック。
   • リポジトリにローカルの commitlint 設定がある場合、または commitlint を実行できる場合は、git commit に進む前に commit-message.txt を必ず事前検証します。
   • 推奨コマンド：pnpm exec commitlint --edit commit-message.txt --strict。リポジトリで npx --no-install commitlint を使用している場合は、既存のフック／スクリプトに合わせてください。
   • 警告、エラー、ルール違反はすべてブロッカーとして扱い、続行する前に文面を修正してください。
   • リポジトリで scope が必須の場合は、有効な scope を使用してください。有効な scope を特定できない場合は、停止して理由を説明してください。
   • リポジトリで scope が必須でない場合は、scope を捏造するのではなく、省略することを優先してください。

8. 関連する最小限の検証を実行します

   • 下記の「最小有効検証マトリクス」に従って、今回のコミット前に実行するデフォルトの最小検証を選択します。
   • 検証に合格してからステップ 9 に進み、コミットを実行します。
   • 検証に失敗した場合は問題を修正してから、検証を再実行します。
   • リポジトリに有意義な自動検証が実際に存在しない場合は、最終報告で「検証を実行していません。リポジトリに利用可能なスクリプト／ルールがないためです」と明記してください。

9. Assisted-by / Co-authored-by 情報を取得してコミットを実行する

   • AI クライアントのモデル名を取得する：現在の会話の system prompt または初期化情報から確認します：
     • "You are Claude Code" → クライアント = "Claude Code"
     • "You are Cursor" → クライアント = "Cursor"
     • "You are Gemini CLI" → クライアント = "Gemini CLI"
     • その他の AI IDE / CLI も同様です
   • AI モデルのモデル名を取得する：現在の会話の model 情報から確認します：
     • "MiniMax-M2.5-highspeed" → モデル = "MiniMax-M2.5"
     • "claude-opus-4-6" → モデル = "Claude Opus 4.6"
     • "claude-sonnet-4-6" → モデル = "Claude Sonnet 4.6"
     • その他のモデルも同様です
   • Assisted-by を生成する [CRITICAL]：
     • 上記で取得済みのクライアント名とモデル名をそのまま使用し、2 つ目の識別フローを追加したり、既存のクライアント／モデル取得ルールを変更したりしないでください。
     • クライアントとモデルの両方を確実に取得できる場合は、Assisted-by: AGENT_NAME / MODEL_VERSION trailer を必ず 1 つだけ追加します。順序はクライアント／Agent が先、モデルが後で固定し、スラッシュ / の両側にはそれぞれ 1 つのスペースを入れます。
     • 例：Assisted-by: Codex / gpt-5.6-terra、Assisted-by: Claude Code / deepseek-v4-flash、Assisted-by: WorkBuddy / MiniMax-M2.5。
     • この手順では、「AI が実質的に関与したか」「意味のある支援に該当するか」や貢献割合を追加で判定しません。このスキルが今回の commit を実際に実行し、両方の識別情報を取得できた場合にのみ、この trailer を生成します。
     • Assisted-by に記録するのは今回実際に実行した Agent と Model のみです。GitHub アカウント／メールアドレスは照会せず、以下の Co-authored-by の allowlist や blacklist も使用しません。Assisted-by と Co-authored-by は互いに独立しており、同時に存在できます。
     • クライアントまたはモデルのいずれかを確実に取得できない場合は、Assisted-by を省略します。1 つのフィールドだけの形式に切り替えたり、Unknown と記載したり、推測したり、ネットワーク経由で不足情報を補ったりしてはいけません。
     • 検出ログを必ず出力する：→ Assisted-by 检测: 客户端="{クライアント名}"; 模型="{モデル名}"; 结论="{Assisted-by trailer または省略理由}"。
   • Co-authored-by を個別に判定する：クライアントとモデルがそれぞれ以下の allowlist に含まれるかを個別に判断します。「クライアントを検証できた」ことから「モデルも検証できた」と判断してはいけません。
   • 検出ログを必ず出力する（結果にかかわらず）：
     • 形式：→ Co-authored-by 检测: 客户端="{クライアント名}" → {allowlist に含まれる／含まれない}; 模型="{モデル名}" → {allowlist に含まれる／含まれない}; 结论="{結論}"
     • 例：→ Co-authored-by 检测: 客户端="WorkBuddy" → allowlist に含まれない; 模型="Deepseek-V4-Flash" → allowlist に含まれない; 结论="trailer は追加しない"
     • これにより、「Co-authored-by がいつの間にか消えた」のではなく、検出プロセスをユーザーが明確に把握できるようにします。
   • 許可される結果は次の 4 種類のみです：
     1. クライアントのみ検証可能 → クライアントの trailer のみ追加
     2. モデルのみ検証可能 → モデルの trailer のみ追加
     3. 両方とも検証可能 → 2 つの trailer を追加
     4. 両方とも検証不可、または識別できない → trailer を追加しない
   • 現在のセッションでモデル識別子を確実に取得できない場合は、「モデルを検証できない」とみなします。推測してはいけません。
   • allowlist に含まれない現在のクライアント（Codex、Gemini CLI など）には、以下の対応表に後から明示的に追加されない限り、デフォルトでは Co-authored-by を記載しません。
   • --trailer パラメーターを使用して追加する：git commit -F commit-message.txt を実行するとき：
     • Assisted-by の条件を満たす場合は、対応する --trailer "Assisted-by: AGENT_NAME / MODEL_VERSION" を最初に追加します。
     • 続いて、既存の Co-authored-by 判定結果に従い、検証済みの識別情報に限って対応する --trailer を追加します。識別情報 1 つにつき、Co-authored-by trailer を 1 つ追加します。
     • Assisted-by の有無は、Co-authored-by の allowlist 判定に影響されません。クライアントまたはモデルの検証可能な GitHub ID がなくても、両方の実行時の識別情報を確実に取得できていれば、Assisted-by を生成できます。
   • コミット成功後に一時ファイルを削除する：
     • PowerShell：Remove-Item -LiteralPath commit-message.txt
     • POSIX Shell：rm -- commit-message.txt
   • コミット結果を確認する：
     • git log -1 --format=%B
     • git status --short --branch
     • commit 中に warning が発生した場合、hook によってファイルが書き換えられた場合、または最終的なコミットメッセージが想定と異なる場合は、完了したと宣言せず、先に修正してください。
   • 🛑 push しないでください：コミットの実行後、git push を実行しないでください。push の実行はユーザーが判断して行います。

10. 作業ツリーがクリーンになるまで、次のコミットを繰り返す

最小限の有効な検証マトリクス [CRITICAL]

変更の種類	デフォルトの最小検証
Markdown／ドキュメントのみ	Markdown のフォーマット、またはドキュメントのレンダリングフローに関連する最小限のビルド
設定のみ	対応する lint / config check / 最小限の build
ソースコード	対応モジュールの test / typecheck / build のうち、最も速く有意義なもの
複合変更	主なリスクをカバーする最小限の検証の組み合わせ

分類ごとに分割してコミットする規則 [CRITICAL]

作業ツリー内に多数のファイル変更がある場合は、全件を一括コミットするのではなく、必ず変更を独立した小さなコミットに分割します。以下の判断フローに従ってください：

分析变更文件列表
    ↓
有没有不同 type 的混合变更？ → 是 → 按 type 拆分
    ↓ 否
有没有跨越多个业务模块的变更？ → 是 → 按模块拆分
    ↓ 否
有没有配置/文档/测试等文件混在一起？ → 是 → 按文件类型拆分
    ↓ 否
变更范围是否横跨前后端或基础设施？ → 是 → 按范围拆分
    ↓ 否
所有变更都聚焦于同一职责 → 合并为一个提交

ファイル移動（rename）の検出 [CRITICAL]

type／モジュール／ファイルの種類ごとに分割する前に、必ずファイル移動の検出を行ってください。ファイル移動は、他のあらゆる観点より優先される分割上の制約です。

检查 git status --short 中是否存在同名文件对
    ↓
同时出现 D <旧路径/文件名> 和 ?? <新路径/文件名> 且 basename 相同？
    ↓ 是
这些文件必须合并为一个 rename 提交，禁止拆成删除 + 新增两个提交
    ↓ 否
继续正常的 type/模块/文件类型拆分流程

検出手順（git-commit の実行時に毎回必ず実行）：

1. git status --short を実行し、D 行（削除済み）と ?? 行（未追跡）から、それぞれファイル名の basename を収集します。
2. D 行と ?? 行の basename を照合します。
3. 一致した場合（同名ファイルで親ディレクトリが異なる場合）：該当する削除と追加を1 つの rename コミットにまとめる必要があります。コミット時に git add で旧パスの削除と新パスの追加を同時にステージし、git に rename を自動認識させます。
4. 削除と追加を個別のコミットに分割済みの場合は、git reset --soft HEAD~1 で取り消し、新しいパスをステージしてから再コミットします。

判定の手がかり：

• git diff --cached --stat に deletions(-) が多数あり、insertions(+) が 0 の場合 → 直ちに git status --short に一致する ?? 行がないか確認します
• git status --short の D 行と ?? 行で basename が同じ、かつ親ディレクトリが異なる場合 → ほぼ確実にファイル移動です

type とファイルの種類の対応例：設定ファイル→config、ドキュメント→docs、テスト→test、依存関係→deps、コアソースコード→feat／fix／refactor

詳細な分割例（8 ファイルの分割案を含む）については、references/commit-splitting-example.md を参照してください。

破坏性变更规范 [CRITICAL]

当用户提及**「破坏性变更」**关键词，或本次变更确实存在不向下兼容的 API/行为改动时，必须按以下规范编写提交信息。

主动评估准则（每次提交前执行）

不要只等用户说"破坏性变更"才行动。 在完成步骤 5 后（描述变更内容后），主动对照以下清单判断本次变更是否属于破坏性：

判断维度	属于破坏性变更的情况	不属于破坏性变更的情况
API 签名变更	函数参数数量/顺序/类型变化、删除导出的函数或类、重命名公共 API	新增仅额外可选参数的 API、内部私有函数改名
配置格式变更	修改配置文件的字段名/类型/结构、删除已有配置项	新增配置项（默认值兼容旧行为）、仅调整注释
行为语义变更	修改已有功能的预期行为、删除功能、改变错误处理策略	新增功能（不影响已有行为）、修复 Bug（恢复预期行为）
依赖升级	框架/运行时大版本升级（如 Vue 2→3、Node 16→20）、peerDependencies 范围收窄	补丁版本升级、开发依赖升级
数据结构变更	修改数据库 schema、修改 API 响应格式、修改缓存键结构	新增字段（客户端可忽略）、仅增加索引
删除/重命名文件	删除或重命名被其他模块引用的文件、删除导出的符号	删除未使用的文件、内部重组不影响外部

决策规则：只要以上任意一维度命中"属于破坏性变更"，就必须使用 ! 格式。

如果不确定：偏向保守——标记为破坏性变更，并在 BREAKING CHANGE: 正文中说明"可能的影响范围"。

感叹号位置（唯一正确格式）

<emoji> type(scope)!: summary

• ! 紧跟在 ) 之后，冒号 : 之前
• ! 与 ) 之间不留空格
• ! 与 : 之间不留空格

错误示例 vs 正确示例

写法	状态	问题说明
🦄 refactor!(scope): summary	❌	感叹号在 type 之后、scope 之前，不符合规范
🦄 refactor(scope) !: summary	❌	感叹号与 ) 之间有空格
🦄 refactor(scope)! : summary	❌	感叹号与 : 之间有空格
🦄 refactor(scope)!: summary	✅	正确——! 紧跟在 ) 之后，无空格
🦄 refactor!: summary（无 scope）	✅	无 scope 时 ! 紧跟在 type 之后

完整破坏性变更提交模板

<emoji> type(scope)!: 简短描述破坏性变更

BREAKING CHANGE: 详细说明破坏性变更的内容、原因，以及用户需要如何迁移。

- 变更点 1
- 变更点 2

示例

🦄 refactor(api)!: 重构用户查询接口

BREAKING CHANGE: 函数签名从 `getUser(id)` 改为 `getUser({ id, includeDeleted? })`，需更新所有调用方。

提交类型（commit type）选择指南

本仓库在 references/commit-types.ts（随技能分发的快照）中定义了 18 个提交类型。 远程 GitHub raw 文件是权威来源，本地 references/commit-types.ts 作为离线 fallback。

核心类型（高频使用）

type	emoji	适用场景	注意
feat	✨	新增功能、新特性、新组件	有 semver: minor，CLI 用户可见的新能力
fix	🐞	修复 Bug、修正异常行为	恢复预期行为，非新增功能
refactor	🦄	代码重构——重写/重命名/拆分代码但不改变外部行为	如果改变了行为 → 用 feat 或 fix
docs	📃	仅文档变更（README、JSDoc、注释、CHANGELOG）	不包括源码注释——源码注释用 chore
test	🧪	新增/修改测试用例、测试配置	不包括测试工具链的升级
style	🌈	代码格式化（缩进、分号、引号）、Lint 修复	不包括 CSS/UI 样式变更——那是 feat

辅助类型（中频使用）

type	emoji	适用场景	注意
config	🔧	配置文件新增/修改	仅限配置本身，不包括配置变更引起的代码改动
build	🔨	构建系统变更（构建工具、打包配置、tsconfig）	与 config 的边界：build 只用于"影响构建产物"的配置变更
deps	📦	依赖包的新增/升级/移除	当依赖变更伴随代码调整时，代码部分另开提交
chore	🐳	不属于以上任何类别的杂项——如 .gitignore、.editorconfig、源码注释清理	兜底 type——只有其他 type 都不匹配时才用
ci	🐎	CI/CD 配置文件变更（GitHub Actions、CI 脚本）	不影响生产代码
perf	🎈	性能优化	如果优化时重构了代码 → 用 refactor；优化且改变行为 → 用 feat
i18n	🌐	国际化翻译文本的新增/修改	不包括国际化基础设施——那算 feat 或 config

特殊类型（低频使用）

type	emoji	适用场景	注意
revert	🔙	仅用于 git revert 生成的提交	不要手动编写此 type，让 git revert 自动生成
delete	🔪	删除已废弃的代码/文件/注释	删除可能被引用的东西 → 用破坏性变更 !
init	🎉	项目/模块/子包的初始化或重新初始化。如：新建 monorepo 子包、首次接入构建工具链、初始化文档站脚手架、为新目录建立基础结构和约定	适用于从无到有搭建基础设施的场景。不要用于已有项目的增量功能开发（那用 feat）
publish	📢	发布 npm 包新版本（CHANGELOG + version bump）	仅限发布流程专用
save-file	🤔	仅用于"临时保存进度，不构成有意义变更"	尽量避免，用有意义的 type 代替

边界类型判断流程

当不确定选哪个 type 时，按以下流程决策：

1. 这个变更是"新增"还是"修复"？
   → 新增功能 → feat
   → 修 Bug → fix
   → 都不是 → 第 2 步

2. 变更是否影响用户可见行为？
   → 是 → 回到第 1 步（用 feat 或 fix）
   → 否 → 第 3 步

3. 变更属于以下哪一类？
   → 重构代码结构 → refactor
   → 改配置文件 → config
   → 改构建/打包 → build
   → 改文档/注释 → docs
   → 改测试 → test
   → 改 CI/CD → ci
   → 改依赖 → deps
   → 改翻译文本 → i18n
   → 性能优化 → perf
   → 格式化/Lint → style
   → 删除废弃文件 → delete
   → 版本发布（版本号同步 + CHANGELOG） → publish
   → 从零初始化项目/模块 → init
   → 都不匹配 → chore（兜底）

类型选择禁忌

• ❌ 不要混淆 style 和 UI 样式：style 只用于代码格式化（缩进、分号），不用于 CSS/UI 视觉效果
• ❌ 不要滥用 chore：只有明确不属于其他任何 type 时才能用——chore 不是"我不知道用什么所以选这个"
• ❌ 不要把不同类型混入一个提交：如果改了代码又改了文档，拆成 feat + docs 两个提交
• ❌ 不要臆造不在 commit-types.ts 中的 type：如果觉得现有 type 都不匹配，用最接近的那个，而不是发明新 type
• ❌ 不要将版本发布用 config 代替 publish：版本号同步 + CHANGELOG 更新 → 必须用 📢 publish，不能用 🔧 config。config 仅用于配置文件本身的修改（如新增配置项、调整配置结构），不用于"因为要发布所以改版本号"的操作

Co-authored-by 邮箱对照表

注意：

• GitHub 识别 Co-authored-by 主要依赖邮箱是否能归属到 GitHub 账号。下面统一使用对应账号的 users.noreply.github.com 邮箱格式。
• 所有条目均已通过 GitHub API（https://api.github.com/user/:id + /users/:login/orgs）验证，确认账号归属可信。
• 客户端与模型必须分别匹配此表；任一项未命中时，仅跳过该项，不得连带臆造另一项。
• 若某工具或模型不在此表中，禁止编造或猜测账号，直接跳过 Co-authored-by。

已验证的 Co-authored-by 账号

工具名称	GitHub 账号 / 邮箱类型	关注者数 / 验证来源	Co-authored-by 格式
Cursor	cursoragent	1,856	Co-authored-by: Cursor <[email protected]>
Claude Code	公司邮箱	官方文档	Co-authored-by: Claude <[email protected]>
MiniMax	组织邮箱	6,703 (org followers)	Co-authored-by: MiniMax <[email protected]>
MIMO	组织邮箱	1,741 (org followers)	Co-authored-by: MIMO <[email protected]>

注意：MiniMax 和 MIMO 使用的组织邮箱已在 GitHub 组织设置（MiniMax-AI / XiaomiMiMo）中公开，但可能无法在 GitHub 提交页显示模型图标（取决于 GitHub 域名验证与头像关联状态）。若各厂商后续提供官方 bot 账号或 users.noreply.github.com ID，再用其替换组织邮箱。

无官方账号（禁止使用）

以下工具/模型目前没有经验证的官方 GitHub bot 账号或公司邮箱，禁止使用任何冒名抢注账号：

• AI CLI：Codex CLI（属于 openai 组织）、Gemini CLI（属于 google-gemini 组织）均无专属 bot 账号
• ZCode CLI：由智谱 AI（zai-org）推出，无独立 GitHub bot 账号。智谱官方尚未建立任何可验证的 bot 账号（参见 zai-org/GLM-5#75，社区提议 glm-bot + [email protected]，至今无官方回复）
• WorkBuddy（腾讯小龙虾）：腾讯云 CodeBuddy 团队维护，代码托管在 cnb.cool/CodeBuddy，GitHub 无官方组织或 bot 账号
• AI IDE：VS Code、Trae、Codebuddy、Antigravity、Qoder、Kiro 均未确认官方 bot 账号
• AI 模型：OpenAI GPT 系列、Gemini 系列、GLM 系列（智谱）、Kimi 系列（月之暗面/MoonshotAI）均无官方归属 bot 账号

待各厂商官方提供可验证的 bot 账号或公司邮箱后再补充到此表中。

已确认的假冒/冒名账号黑名单 [CRITICAL]

以下账号均已通过 GitHub API 验证为非官方账号，严禁在 Co-authored-by 中使用：

冒充目标	假冒账号	判定依据简述
Claude Code	anthropics-claude	不在 anthropics 组织；含加密货币诈骗项目
Gemini CLI	google-gemini-cli	不在 google-gemini 组织；全是 fork 无原创
Codex CLI	codex-cli	不属于 openai 组织；Codex 发布 5 天后抢注
VS Code	vscode-triage-bot	是 Issue 分流机器人，非 VS Code 本体
GLM-5	zhipuch	普通个人用户，与智谱 AI 无关联
Trae	Trae-AI-Admin	不属于任何组织；0 个公开仓库
Codebuddy	CodeBuddy-Official-Account	不属于任何组织；无法确认为官方账号
其他（Antigravity/Qoder/Kiro/MiniMax/Kimi/MIMO）	各假冒账号	均不在对应组织中，0 或极少公开仓库

完整黑名单（含 ID 和详细判定依据）参见 references/co-authored-by-blacklist.md。

交付物

提供：

• 最终的提交信息（包含 Emoji，按上下文选择中文或英文编写）
• 每个提交的简短摘要（内容/原因）
• 用于暂存/审查的命令（至少：git diff --cached，加上运行的任何测试）

参考文件

以下文件存放在本技能目录的 references/ 下，按需查阅：

文件	何时查阅
commit-types.ts	emoji/type 映射的本地 fallback 数据源
commit-message-template.md	提交信息写作模板与结构参考
commit-splitting-example.md	拆分逻辑复杂、文件众多时需要详细拆分示例
staging-priority.md	对暂存区处理逻辑有疑问时
input-requirements.md	用户信息不足需要确认输入时
co-authored-by-blacklist.md	发现未知 Co-authored-by 账号需验证时
breaking-change-examples.md	编写复杂破坏性变更提交信息时
command-reference.md	PowerShell/POSIX 具体命令记不清时