用途：在创建 git 提交信息时遵循 Conventional Commits 1.0.0 规范。适用场景包括用户要求提交已暂存或未暂存的改动、要求“为这个 diff 写提交信息”，或仓库中存在 commitlint、husky，或 CONTRIBUTING.md 提到 Conventional Commits。
主要能力与用法：先查看改动，运行 git diff --staged（若无暂存内容则用 git diff），不得在未读 diff 的情况下凭空编造信息。类型依据实际改动而非文件名选择：feat 表示新增用户可见行为，fix 表示修复用户可见缺陷，refactor 表示不改变行为的重构，另有 docs、test、build、ci、chore、style、perf。若仓库已使用 scope，则添加 scope，可查看 git log --oneline -20 了解既有风格。主题行使用祈使语气，冒号后小写，结尾不加句号，不超过 72 字符。正文可选，说明原因，按 72 字符换行。页脚可写 BREAKING CHANGE: 或问题引用（如 Closes #123）。
决策规则：同一 diff 中混入不相关改动时，建议拆分为多个提交，而非用一个含糊的 chore；回滚改动使用 revert: 并引用被回滚的 SHA；在 fix 与 refactor 之间不确定时，看终端用户是否能观察到差异，能则为 fix，不能则为 refactor。
完成标准：git log -1 --format=%s 的输出匹配 ^(feat|fix|refactor|docs|test|build|ci|chore|style|perf|revert)((.+))?!?: .+，且信息如实描述该 diff。
限制：资料未提供安装命令、收费、价格、平台支持或效果数据，暂未提供。