用途：帮助开发者编写清晰、原子化的 Git 提交信息。先检测并匹配项目既有约定，找不到明确规范时回退到 Conventional Commits 格式。核心理念是每个提交对应一个完整、可工作的变更，提倡“尽早提交、频繁提交”。
主要能力：检测项目约定（检查 .commitlintrc*、commitlint.config.*、.czrc、.cz.json 等配置文件，并用 git log --oneline -15 观察历史模式），据此决定遵循既有规则还是使用 Conventional Commits；按 <type>(<scope>)!: <subject> 格式组织信息，主题行理想 50 字符、最多 72 字符，正文每行 72 字符换行；提供 feat、fix、docs、style、refactor、perf、test、build、ci、chore、revert 等类型及对应 SemVer 影响；支持破坏性变更标记（! 与 BREAKING CHANGE）和页脚（Closes、Fixes、Refs、Co-authored-by 等）；指导提交粒度，区分应合并与应拆分的变更；给出提交时机与不应提交的情形。
使用方式：提交前确认代码可构建、测试通过、只含一个逻辑变更并已检查项目约定；按检测约定、格式化信息、按需写正文、写页脚四步执行；通过标准 git 命令创建提交，不保存额外文件，历史可用 git log 查看。
适用场景：功能分支工作流中的频繁提交、TDD 的 RED/GREEN/REFACTOR 提交、需要自动生成变更日志与语义化版本的项目。
限制：资料未提供具体安装命令、收费、价格或平台信息；正文与页脚为可选，仅在破坏性变更、非显而易见修复或复杂功能时建议填写。