git-commit

Git Commit

Goal

Include only the intended changes → logical splitting → messages describe what the change is and why

Pre-parsed task packet (fast path)

When the main agent has already completed scope analysis and provided a task packet, the executing agent can take the fast path, skipping repeated scanning of conversation history and unrelated directories. The task packet must contain all of the following fields:

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

Hard gates for the fast path:

1. First use git status --short --branch、git diff --cached and the target group file list to confirm the packet is still consistent with the working tree; if inconsistent, fall back to the full workflow and report the differences.
2. Only allow staging scope and the files of the current groups ,exclude modifications in it must always remain unstaged; reverting out-of-scope files is prohibited.
3. You must still perform staged diff review, sensitive information scanning, commitlint, minimal verification, and post-commit git log -1 and git status re-check; the fast path can only omit repeated discovery, not evidence gates.
4. For the same task, parse the remote or local commit-types.tsonly once, and reuse the type/emoji result for subsequent groupings;identityCheck should also be executed only once according to the packet's conclusion, without repeated guessing.
5. Each commit returns the commit hash, commit body, actual file set, and raw verification output; finally confirm that there is no commit-message.txt or other temporary files left over, and do not execute git push。

If the packet is missing any field, the whitelist is ambiguous, or the verification command is not reproducible, the fast path must not be used.

Rule source priority [CRITICAL]

When generating a commit message, make decisions according to the following priorities; a lower priority must not override a higher priority:

1. The user's explicit requirements in the current conversation
2. The current repository's local commit / commitlint rules (such as the commitlint.config.*、.commitlintrc*、package.json field in commitlint ,commit-msg hook）
3. Remote raw commit-types.ts(preferred) + local commit-types.ts(fallback, see step 6)
4. The skill's default template, examples, and references/commit-message-template.md

• If multiple sources conflict, the higher-priority source must prevail.
• If a higher-priority source is missing or fails to be read, you must stop and explain; do not guess. If the source content is complete and its meaning is clear (such as commitlint rules already defining a scope list), simply execute according to the rules.

Workflow (checklist)

1. Check the staging area and working tree status (staging area takes precedence)

   • git status
   • First check whether the staging area has content：git diff --cached --stat
     • ✅ The staging area has files: this commit is only for the staging area; do not git add additional files on your own. Skip directly to step 4 to review the staged content.
     • 📭 The staging area is empty: only then is it necessary to select files from the working tree for staging; continue with steps 2-3.
   • If you need to view changes in the working tree:git diff or git diff --stat

2. Determine commit boundaries (split if necessary) [see "Categorized splitting specification"]

   • First lock down the file scope [CRITICAL]：
     • Carefully read the user's instructions and confirm thefile scopefor this commit (e.g., "only handle the files involved", "only handle the files you changed", "commit the xx directory").
     • List the files in the working tree that areout of scopebut do not stage them, even if they have uncommitted changes.
     • Absolutely forbiddento perform git checkout --、git restore、git reset and other revert operations on files out of scope—you cannot determine the source and intent of these changes, and reverting will cause data loss.
     • If files out of scope have uncommitted changes, mention to the user in the final report that "the following files have uncommitted changes but were not included in this commit scope", and let the user decide how to handle them.
   • First analyze the context: Carefully read the changes described by the user in the conversation and understand the business intent of this modification.
   • Four-dimensional splitting basis：
     1. File type: configuration files vs source code vs documentation vs test files
     2. Business function module: changes to different business modules are committed independently (e.g., auth vs payment）
     3. Modification type: new feature vs bug fix vs refactoring vs formatting (changes of different types are separated)
     4. Modification scope: frontend vs backend, dependency upgrade vs behavior change, production code vs test code
   • If changes are mixed within one file, plan to use patch staging (patch staging)。

3. Only stage the content belonging to the next commit(perform this step only when the staging area is empty)

   • For mixed changes, prefer patch staging:git add -p
   • Unstage hunks/files:git restore --staged -p or git restore --staged <path>

4. Review what will actually be committed

   • git diff --cached
   • Compliance check：
     • No keys or tokens
     • No unexpected debug logs
     • No unrelated formatting changes
   • Continue directly after the check passes: If all three checks above pass,do not stop to ask the user "whether sensitive information is involved". Continue directly to step 5. Only when the check finds suspicious content do you need to confirm with the user.

5. Describe the staged changes in 1-2 sentences (before writing the message)

   • "What changed?" + "Why?"
   • If you cannot describe it clearly, then the commit may be too large or mixed; return to step 2.

6. Write the commit message

   • Language selection (default Chinese, switch according to context)：
     • DefaultWrite the commit message in Chinese.
     • Exception: If you are submitting a PR to an open-source/upstream repository that uses English (git log the recent commits are all in English), then write in English instead. Basis for judgment:
       • Check the commit language style of the upstream target repository of the current branch (git log --oneline the most recent 5-10 records)
       • If the upstream/target repository is entirely in English → switch to English
       • Otherwise → keep Chinese (default)
     • Regardless of Chinese or English, the language of the summary and body must remain consistent.
   • Use Conventional Commits(required):
     • Normal commit:<emoji> type(scope): summary
     • Breaking change:<emoji> type(scope)!: summary(the exclamation mark immediately follows ) and comes before the colon)
     • (blank line)
     • body (content/reason, not a play-by-play of the implementation)
     • footer: for breaking changes, it must include the BREAKING CHANGE: <说明> line
   • Emoji and Type conventions: you must consult and follow the definitions in commit-types.ts , obtained in the following order of priority:
     • Preferred (remote raw, to ensure it is up to date): fetch the latest definition from the GitHub remote:
       • https://raw.githubusercontent.com/ruan-cat/monorepo/dev/configs-package/commitlint-config/src/commit-types.ts
       • The remote file is the authoritative source; prefer it to ensure the type/emoji mapping is up to date.
     • Fallback (the local file bundled with the skill): if fetching the remote raw file fails (network unavailable/timeout/HTTP error), fall back to the file under this skill directory, references/commit-types.ts
       • read that file and parse the commitTypes array to locate the type。
       • This file is a snapshot copy distributed with the skill; its version may lag behind the remote, but it ensures offline availability.
     • Do not determine the emoji based solely on search summaries or caches—you must read the complete file and then locate the type. Before continuing, explicitly restate the result of this parsing:selected type、resolved emoji, and the matched raw fragment.
     • When the same task contains multiple logical commits, you only need to parse once in the first group; subsequent groups reuse the already confirmed mapping and note the reuse in the execution record—do not repeatedly read and infer.
     • If both the remote and local fetches fail → stop, report "Unable to fetch commit-types.ts, cannot determine valid type and emoji", and do not guess or fall back to an old table.
   • Using the file method is recommended(to avoid encoding and escaping issues caused by passing shell arguments):
     • For commit messages containing Chinese, by default use git commit -F commit-message.txt
     • to create a temporary commit message file (e.g. commit-message.txt), and write the commit message content into it
     • ⚠️ This step only creates the commit message file; do not run git commitin this step. The actual commit will be performed in step 9.
   • Do not stop at step 6 after showing the commit message text to the user and end the process—continue with steps 7→8→9 to complete the entire commit process.
   • Refer to references/commit-message-template.md for the template format and BREAKING CHANGE examples; do not treat its contents as the source of truth for emoji/type.

7. Commit message pre-validation [CRITICAL]

   • First check whether the current repository has local commit rules:commitlint.config.*、.commitlintrc*、package.json the commitlint field ofcommit-msg hook。
   • If the repository has a local commitlint configuration or an executable commitlint, you must first perform pre-validation on commit-message.txt before allowing entry into git commit。
   • Recommended command:pnpm exec commitlint --edit commit-message.txt --strict; if the repository uses npx --no-install commitlint, stay consistent with the repository's existing hook / script.
   • Any warning, error, or rule violation is treated as blocking; the text must be corrected first before continuing.
   • If the repository requires a scope, a valid scope must be used; if a valid scope cannot be determined, stop and explain why.
   • If the repository does not require a scope, prefer omitting the scope rather than inventing one.

8. Run the minimal relevant validation

   • Select the default minimal validation before this commit according to the "Minimal Effective Validation Matrix" below.
   • After validation passes, proceed to step 9 to commit.
   • If validation fails, fix the issue and re-run the validation.
   • If the repository truly has no meaningful automated validation, the final explanation must clearly state "no validation was run because the repository has no available scripts/rules".

9. Obtain Assisted-by / Co-authored-by information and perform the commit

   • Obtain the AI client model: Look it up from the system prompt or initialization information of the current conversation:
     • "You are Claude Code" → client = "Claude Code"
     • "You are Cursor" → client = "Cursor"
     • "You are Gemini CLI" → client = "Gemini CLI"
     • The same applies to other AI IDEs / CLIs
   • Obtain the AI model name: Look it up from the model information of the current conversation:
     • "MiniMax-M2.5-highspeed" → model = "MiniMax-M2.5"
     • "claude-opus-4-6" → model = "Claude Opus 4.6"
     • "claude-sonnet-4-6" → model = "Claude Sonnet 4.6"
     • The same applies to other models
   • Generate Assisted-by [CRITICAL]：
     • Directly reuse the client name and model name already obtained above; do not add a second identification process, and do not change the existing client/model acquisition rules.
     • When both the client and the model can be reliably obtained, exactly one Assisted-by: AGENT_NAME / MODEL_VERSION trailer must be appended; it is fixed asclient/Agent first, model second, with a slash / and one space on each side.
     • Example:Assisted-by: Codex / gpt-5.6-terra、Assisted-by: Claude Code / deepseek-v4-flash、Assisted-by: WorkBuddy / MiniMax-M2.5。
     • This step does not additionally judge whether "AI actually participated", whether it constitutes "meaningful assistance", or the contribution ratio; as long as this skill actually performs this commit and both identity fields have been obtained, generate this trailer.
     • Assisted-by It only records the Agent and Model actually running this time; it does not query GitHub account/email, nor does it use the allowlist or blacklist of Co-authored-by below; it is independent of Co-authored-by and can coexist with it.
     • If either the client or the model cannot be reliably obtained, skip Assisted-by; do not degrade to a single-field form, do not write Unknown, and do not guess or complete missing fields via the internet.
     • A detection log must be output：→ Assisted-by 检测: 客户端="{客户端名}"; 模型="{模型名}"; 结论="{Assisted-by trailer 或跳过原因}"。
   • Co-authored-by item-by-item determination: The client and the model must separately determine whether they are in the allowlist below; "client-verifiable" must not be automatically extended to "model-verifiable" as well.
   • A detection log must be output(regardless of the result):
     • Format:→ Co-authored-by 检测: 客户端="{客户端名}" → {在/不在} allowlist; 模型="{模型名}" → {在/不在} allowlist; 结论="{结论}"
     • For example:→ Co-authored-by 检测: 客户端="WorkBuddy" → 不在 allowlist; 模型="Deepseek-V4-Flash" → 不在 allowlist; 结论="不追加任何 trailer"
     • This is done so that users clearly know the detection process, rather than "Co-authored-by mysteriously disappearing".
   • Only the following four results are allowed:
     1. Client-verifiable only → append only the client trailer
     2. Model-verifiable only → append only the model trailer
     3. Both verifiable → append two trailers
     4. Neither verifiable or unable to identify → append no trailer
   • If the current session cannot reliably obtain the model identifier, it must be treated as "model not verifiable"; do not guess.
   • Current non-allowlist clients (such as Codex, Gemini CLI, etc.) do not write Co-authored-by by default, unless explicitly added later in the comparison table below.
   • Use --trailer parameter to append: when executing git commit -F commit-message.txt :
     • If Assisted-by condition is met, first append a corresponding --trailer "Assisted-by: AGENT_NAME / MODEL_VERSION"。
     • then, according to the original Co-authored-by determination result, append the corresponding --traileronly for verified identities; one identity corresponds to one Co-authored-by trailer。
     • Assisted-by Whether it exists is not affected by the Co-authored-by allowlist determination; even if the client or model has no verifiable GitHub identity, as long as both runtime identities are reliably obtained, it can still be generated Assisted-by。
   • Delete the temporary file after a successful commit：
     • PowerShell：Remove-Item -LiteralPath commit-message.txt
     • POSIX Shell：rm -- commit-message.txt
   • Review the commit result：
     • git log -1 --format=%B
     • git status --short --branch
     • If a warning appears during the commit process, a hook rewrites files, or the final commit message is inconsistent with expectations, you must not directly claim completion; you must fix it first.
   • 🛑 Do not push: after completing the commit,do not execute git push. The push operation is decided and performed by the user.

10. Repeat the next commit until the working tree is clean

Minimal effective verification matrix [CRITICAL]

Change type	Default minimal verification
Markdown / documentation only	Markdown formatting or the minimal build related to the documentation rendering pipeline
Configuration only	Corresponding lint / config check / minimal build
Source code	The fastest and most meaningful item among the corresponding module's test / typecheck / build
Mixed changes	Choose the minimal combination of verification that covers the main risk areas

Specification for splitting commits by category [CRITICAL]

When there are many file changes in the working tree,mustsplit the changes into independent small commits rather than committing everything at once. Follow this decision process:

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

File move (rename) detection [CRITICAL]

Before splitting by type/module/file type, file move detection must be performed first. File moves are the highest-priority splitting constraint, higher than any other dimension.

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

Detection steps(mandatory each time git-commit is executed):

1. Run git status --short, and separately collect the filename basenames from the D lines (deleted) and the ?? lines (untracked).
2. Cross-compare the basenames of the D lines and the ?? lines.
3. If there is a match (same filename, different parent directory):mustmerge the corresponding deletion and addition intoa single rename commit. When committing, use git add to stage both the deletion of the old path and the addition of the new path at the same time, so that git automatically detects the rename.
4. If it has already been split into a separate deletion commit → git reset --soft HEAD~1 undo it, stage the added path as well, and recommit.

Identify signal：

• git diff --cached --stat If a large number of deletions(-) appear and 0 insertions(+) → immediately check whether there are matching git status --short in ?? lines
• git status --short In the D and ?? lines output by , if the basenames are the same but the parent directories are different → it is almost certainly a file move

type and file type mapping reference: configuration file→config, documentation→docs, tests→test, dependencies→deps, core source code→feat/fix/refactor

For a detailed split example (including an 8-file split plan), see references/commit-splitting-example.md。

Breaking change specification [CRITICAL]

When the user mentions the keyword **"breaking change"**, or when this change actually contains backward-incompatible API/behavior changes,mustwrite the commit message according to the following specification.

Proactive assessment criteria (execute before every commit)

Do not wait until the user says "breaking change" to act. After completing step 5 (after describing the change content), proactively check the following checklist to determine whether this change is breaking:

Assessment dimension	Cases that are breaking changes	Cases that are not breaking changes
API signature change	Changes to the number/order/type of function parameters, deletion of exported functions or classes, renaming of public APIs	APIs that only add extra optional parameters, renaming of internal private functions
Configuration format change	Modifying the field names/types/structure of configuration files, deleting existing configuration items	Adding configuration items (default values are compatible with old behavior), only adjusting comments
Behavioral semantic change	Modifying the expected behavior of existing functionality, deleting functionality, changing error handling strategy	Adding functionality (does not affect existing behavior), fixing bugs (restoring expected behavior)
Dependency upgrade	Major version upgrades of frameworks/runtimes (such as Vue 2→3, Node 16→20), narrowing the peerDependencies range	Patch version upgrades, development dependency upgrades
Data structure change	Modifying the database schema, modifying the API response format, modifying the cache key structure	Adding fields (clients can ignore them), only adding indexes
Deleting/renaming files	Deleting or renaming files referenced by other modules, deleting exported symbols	Deleting unused files, internal reorganization that does not affect the outside

Decision rules: As long as any of the above dimensions hits "is a breaking change", you must use the ! format.

If unsure: lean conservative—mark it as a breaking change, and explain the "possible scope of impact" in the body of BREAKING CHANGE: .

Exclamation mark position (the only correct format)

<emoji> type(scope)!: summary

• ! immediately follows ) , before the colon : before
• ! and ) betweenno space
• ! and : betweenno space

Incorrect examples vs correct examples

Format	Status	Issue description
🦄 refactor!(scope): summary	❌	The exclamation mark is after type and before scope, which does not conform to the specification
🦄 refactor(scope) !: summary	❌	There is a space between the exclamation mark and ) there is a space between
🦄 refactor(scope)! : summary	❌	There is a space between the exclamation mark and : there is a space between
🦄 refactor(scope)!: summary	✅	Correct—! immediately follows ) , with no space
🦄 refactor!: summary(no scope)	✅	When there is no scope, ! immediately follows type

Complete breaking change commit template

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

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

- 变更点 1
- 变更点 2

Example

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

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

Commit type selection guide

This repository defines 18 commit types in references/commit-types.ts(a snapshot distributed with the skill). The remote GitHub raw file is the authoritative source, and the local references/commit-types.ts serves as an offline fallback.

Core types (high-frequency use)

type	emoji	Applicable scenarios	Notes
feat	✨	New features, new capabilities, new components	Has semver: minor, new capabilities visible to CLI users
fix	🐞	Fix bugs, correct abnormal behavior	Restore expected behavior, not add new features
refactor	🦄	Code refactoring—rewriting/renaming/splitting code butnot changing external behavior	If behavior is changed → use feat or fix
docs	📃	Documentation-only changes (README, JSDoc, comments, CHANGELOG)	Does not include source code comments—use chore
test	🧪	Add/modify test cases, test configuration	Does not include upgrades to the test toolchain
style	🌈	Code formatting (indentation, semicolons, quotes), lint fixes	Does not include CSS/UI style changes—that is feat

Auxiliary types (medium-frequency use)

type	emoji	Applicable scenarios	Notes
config	🔧	Add/modify configuration files	Limited to the configuration itself, excluding code changes caused by configuration changes
build	🔨	Build system changes (build tools, bundling configuration, tsconfig)	Boundary with config :build is only used for configuration changes that "affect build artifacts"
deps	📦	Adding/upgrading/removing dependency packages	When dependency changes are accompanied by code adjustments, make a separate commit for the code part
chore	🐳	Miscellaneous items that do not belong to any of the above categories—such as .gitignore、.editorconfig, source code comment cleanup	Fallback type—use only when no other type matches
ci	🐎	CI/CD configuration file changes (GitHub Actions, CI scripts)	does not affect production code
perf	🎈	performance optimization	if the code was refactored during optimization → use refactor; optimized and changed behavior → use feat
i18n	🌐	addition/modification of internationalization translation text	does not include internationalization infrastructure—that counts as feat or config

Special types (used infrequently)

type	emoji	Applicable scenarios	Note
revert	🔙	Only used for commits generated by git revert Generated commit	Do not manually write this type; let git revert generate it automatically
delete	🔪	Delete deprecated code/files/comments	Deleting something that may be referenced → use a breaking change !
init	🎉	Initialization or reinitialization of a project/module/subpackage. For example: creating a new monorepo subpackage, integrating a build toolchain for the first time, initializing a documentation site scaffold, establishing the basic structure and conventions for a new directory	Applicable tofrom scratchscenarios of building infrastructure. Do not use it for incremental feature development of an existing project (use feat）
publish	📢	Publish a new version of an npm package (CHANGELOG + version bump)	Only for the release process
save-file	🤔	Only used for "temporarily saving progress, not constituting a meaningful change"	Try to avoid; use a meaningful type instead

Boundary type determination process

When unsure which type to choose, make the decision according to the following process:

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（兜底）

Type selection taboos

• ❌ Do not confuse style with UI styling：style is only used for code formatting (indentation, semicolons), not for CSS/UI visual effects
• ❌ Do not abuse chore: it can only be used when it clearly does not belong to any other type—chore is not "I don't know what to use so I choose this"
• ❌ Do not mix different types into one commit: if you changed code and also changed documentation, split it into feat + docs two commits
• ❌ Do not invent a type that is not in commit-types.ts: if you feel none of the existing types match, use the closest one instead of inventing a new type
• ❌ Do not use config for version releases instead of publish: version number synchronization + CHANGELOG update → must use 📢 publish, cannot use 🔧 config。config is only used for modifications to the configuration file itself (such as adding configuration items, adjusting the configuration structure), not for operations like "changing the version number because a release is needed"

Co-authored-by email mapping table

Note:

• GitHub identifies Co-authored-by mainly based on whether the email can be attributed to a GitHub account. Below, the users.noreply.github.com email format of the corresponding account is used uniformly.
• All entries have been verified through the GitHub API (https://api.github.com/user/:id + /users/:login/orgs), confirming that the account attribution is trustworthy.
• The client and model must each match this table; if either item does not match, skip only that item and do not fabricate the other item as a consequence.
• If a tool or model is not in this table, it is forbidden to fabricate or guess an account; skip Co-authored-by directly.

Verified Co-authored-by accounts

Tool name	GitHub account / email type	Follower count / verification source	Co-authored-by format
Cursor	cursoragent	1,856	Co-authored-by: Cursor <199161495+cursoragent@users.noreply.github.com>
Claude Code	Company email	Official documentation	Co-authored-by: Claude <noreply@anthropic.com>
MiniMax	Organization email	6,703 (org followers)	Co-authored-by: MiniMax <model@minimax.io>
MIMO	Organization email	1,741 (org followers)	Co-authored-by: MIMO <mimo@xiaomi.com>

Note: The organization emails used by MiniMax and MIMO have been made public in the GitHub organization settings (MiniMax-AI / XiaomiMiMo), but the model icon may not be displayed on the GitHub commit page (depending on GitHub domain verification and avatar association status). If the vendors later provide official bot accounts or users.noreply.github.com IDs, use them to replace the organization emails.

No official account (use prohibited)

The following tools/models currently have no verified official GitHub bot account or company email,use of any impersonating, name-squatting account is prohibited：

• AI CLI: Codex CLI (belongs to the openai organization), Gemini CLI (belongs to the google-gemini organization) both have no dedicated bot account
• ZCode CLI: launched by Zhipu AI (zai-org), no independent GitHub bot account. Zhipu officially has not established any verifiable bot account (see zai-org/GLM-5#75, community proposal glm-bot + noreply@z.ai, no official reply to date)
• WorkBuddy (Tencent Xiaolongxia): maintained by the Tencent Cloud CodeBuddy team, code is hosted at cnb.cool/CodeBuddy, GitHub has no official organization or bot account
• AI IDE: VS Code, Trae, Codebuddy, Antigravity, Qoder, Kiro have all not confirmed official bot accounts
• AI models: OpenAI GPT series, Gemini series, GLM series (Zhipu), Kimi series (Moonshot AI/MoonshotAI) all have no officially attributed bot account

Wait until each vendor officially provides a verifiable bot account or company email before adding it to this table.

Confirmed fake/impersonating account blacklist [CRITICAL]

The following accounts have all been verified via the GitHub API as non-official accounts,strictly prohibited from use in Co-authored-by：

Impersonation target	Fake account	Brief description of basis for determination
Claude Code	anthropics-claude	Not in the anthropics organization; contains cryptocurrency scam projects
Gemini CLI	google-gemini-cli	Not in the google-gemini organization; all forks with no original content
Codex CLI	codex-cli	Does not belong to the openai organization; name squatted 5 days after Codex release
VS Code	vscode-triage-bot	Is an Issue triage bot, not VS Code itself
GLM-5	zhipuch	Ordinary individual user, no affiliation with Zhipu AI
Trae	Trae-AI-Admin	Does not belong to any organization; 0 public repositories
Codebuddy	CodeBuddy-Official-Account	Does not belong to any organization; cannot be confirmed as an official account
Other (Antigravity/Qoder/Kiro/MiniMax/Kimi/MIMO)	Various fake accounts	None are in the corresponding organizations, 0 or very few public repositories

For the complete blacklist (including IDs and detailed basis for determination), see references/co-authored-by-blacklist.md。

Deliverables

Provide:

• The final commit message (including Emoji, written in Chinese or English as appropriate for the context)
• A brief summary of each commit (content/reason)
• Commands used for staging/review (at least:git diff --cached, plus any tests run)

Reference files

The following files are stored in this skill directory's references/ Below, consult as needed:

File	When to consult
commit-types.ts	Local fallback data source for emoji/type mapping
commit-message-template.md	Commit message writing templates and structural reference
commit-splitting-example.md	When splitting logic is complex and there are many files, detailed splitting examples are needed
staging-priority.md	When you have questions about the staging area handling logic
input-requirements.md	When user information is insufficient and input needs to be confirmed
co-authored-by-blacklist.md	When an unknown Co-authored-by account is found and needs verification
breaking-change-examples.md	When writing a complex breaking change commit message
command-reference.md	When you cannot remember the specific PowerShell/POSIX commands