用途：按 Conventional Commits 格式撰写或检查提交信息，让提交意图清晰，并支持自动化工具处理。
主要能力：提供标准格式 <type>[optional scope]: <description>，以及可选正文和页脚。内置类型：feat（新功能）、fix（缺陷修复）、docs（仅文档）、style（仅格式或代码风格）、refactor（不含功能或修复的代码改动）、perf（性能改进）、test（新增或修改测试）、build（构建系统或依赖变更）、ci（CI 变更）、chore（维护）、revert（回滚提交）。
用法要点：标题使用祈使句现在时，如 add 而非 added 或 adds；描述首字母小写，结尾不加句号，保持简洁。仅在有用时添加范围，例如 fix(auth): remove stale token。正文用于说明背景，讲清做了什么和为什么，多项改动可用项目符号，行宽约 72 字符。破坏性变更使用 BREAKING CHANGE: ...，需要时引用议题，如 Closes #123。
示例：feat(ui): add dark mode toggle；feat(api): migrate to REST v2 endpoints，并在页脚注明 BREAKING CHANGE: All API endpoints are now prefixed with /api/v2。
输出结构：先给出 Commit Message，再列 Notes，包括类型、范围（无则标注 none）、是否为破坏性变更（yes/no）。
适用场景：需要起草提交信息、审阅现有提交信息是否符合规范，或希望提交历史便于自动生成变更日志等工具处理时。
限制：资料未提供具体安装命令、平台范围、收费信息或与特定工具的集成方式，这些暂未提供。