用途：在创建 git 提交前提供规范指引，帮助生成符合 Conventional Commits 格式且描述充分的提交信息。
主要能力与格式：提交信息采用 <type>(<scope>): <summary> 结构。type 必填，新功能用 feat，修复用 fix，其他常见类型包括 docs、refactor、chore、test、perf。scope 可选，为括号内的简短名词，表示受影响区域（如 api、parser、ui）。summary 必填，使用祈使语气，不超过 72 字符，结尾不加句号。
正文与限制：强烈建议包含正文，除非改动显而易见（如修正拼写）。正文应说明改了什么、为何改、采用的方法及重要决策，使读者无需查看 diff 即可理解。不要包含破坏性变更标记或页脚，不要添加 Signed-off-by 签名，只提交不推送。若不确定某文件是否应包含，需询问用户要提交哪些文件。
参数处理：调用方提供的参数视为额外提交指引。自由文本指令影响 scope、summary 和正文；文件路径或 glob 限定提交范围，若指定文件则只暂存/提交这些文件，除非用户明确要求其他；参数同时包含文件与指令时两者都遵循。
步骤：先判断用户是否提供文件路径/glob 或额外指令；查看 git status 与 git diff 了解改动（若指定文件则限定范围）；可选运行 git log -n 50 --pretty=format:%s 查看常用 scope；若存在含糊的额外文件，提交前询问用户；仅暂存目标文件（未指定则暂存全部改动）；运行 git commit -m "<subject>"（必要时加 -m "<body>"）。
适用场景：需要按统一规范撰写 git 提交信息的开发流程。限制：不跳过提交钩子，不推送，不添加签名或破坏性变更标记；具体实现细节与更多配置暂未提供。