用途：在需要生成 Conventional Commit 风格提交消息并完成单次提交时使用，覆盖 feat、fix、docs、refactor、test、build、ci、chore、perf、revert 等常规场景。
主要能力：按固定工作流引导提交。第一步确认用户是否明确要求提交，并确认质量检查已完成或明确告知仍有风险；第二步查看 git status 与 diff，识别应提交文件，排除临时文件、生成物和无关改动；第三步判断 type，再决定是否需要 scope，描述聚焦“为什么”和“本次改了什么”；第四步仅在用户明确允许时执行 git add / git commit，提交后复查消息是否符合 commitlint 习惯。
使用方式：遵循其铁律，不在不了解实际变更范围和质量状态时直接 git add . 然后提交。先审视变更范围，再生成消息，最后按用户授权执行提交命令。
适用场景：常规功能、修复、文档、重构、测试、构建、CI、杂务等提交。
限制与反模式：不看 diff 使用模糊消息如 update files；把多类变更混成一个没有 scope 的提交；在质量检查未完成时默认提交。交付前需确认允许提交、暂存范围只含相关变更、消息符合 Conventional Commits 语义，并说明任何未完成的质量风险。其他细节暂未提供。