以下为本文档的中文说明该技能用于规范Ant Design项目的Git提交信息格式。它根据Angular提交规范帮助开发者生成符合项目标准的提交信息包括类型、作用域、描述等要素。适用于Ant Design及其相关项目的贡献者确保Git历史记录的一致性和可读性提升项目协作效率。规范的提交信息不仅是项目文档的重要组成部分也为自动化版本发布和变更日志生成提供了基础。该技能确保了Ant Design庞大的贡献者社区能够遵循统一的提交规范。该技能基于Angular提交规范为Ant Design项目提供标准化的Git提交信息生成指导。规范要求提交信息采用(): 的格式其中type表示变更类型feat新功能、fix修复、docs文档、style格式、refactor重构、test测试、chore构建等scope表示影响范围组件名或模块名subject是简要描述。这种规范化的提交信息不仅使Git历史清晰可读还为自动化工具如semantic-release生成版本变更日志提供了基础数据。该技能确保Ant Design庞大的贡献者社区能够遵循统一的提交规范保持项目历史的整洁和一致。Ant Design Commit Message 生成规范目标一、准确概括提交内容- 基于当前git 暂存区生成一行 commit message覆盖本次提交包含的全部改动。二、保持仓库风格一致- 优先贴近仓库已有提交习惯而不是机械套模板。核心原则commit message 不是对 diff 的逐文件罗列而是对这次提交意图的压缩表达。先读暂存区再归纳再输出一行。触发场景当用户提及以下任一情况时使用本 skill要写 commit message、提交信息说「msg」且语境是 git 提交需要根据当前改动生成一句提交说明想让 agent 按 staged changes 总结一行提交标题基本规则一、默认只看暂存区默认只根据staged changes生成 message因为真正会被提交的是暂存区内容。若用户明确说「包含未暂存内容」或「按全部改动写」才额外查看git diff。二、必须先看仓库最近提交风格生成 message 前除了看暂存区还要看最近提交避免写出不符合仓库习惯的格式。三、默认只输出最终一行除非用户明确要求解释理由否则最终回复只给一行 commit message不要附带分析、项目符号、代码块或引号。执行步骤1. 读取 git 状态、暂存区和最近提交必须先获取以下信息再生成 message。不要猜测也不要只凭文件名写。建议执行的命令gitstatus--shortgitdiff--cached--statgitdiff--cachedgitlog--oneline-10git status --short确认哪些文件已 stage是否还有未 stage 内容。git diff --cached --stat快速把握改动范围。git diff --cached查看实际提交内容这是生成 message 的依据。git log --oneline -10检查仓库最近的提交风格、语言、type/scope 习惯。2. 先判断是否能生成若暂存区为空不要编造 message。明确说明当前没有 staged changes无法基于提交区生成准确的一行 commit message。3. 归纳这次提交的主语义根据git diff --cached的结果找出本次提交的主要目的新功能、修 bug、文档修改、重构、测试、脚本或依赖调整等。识别主要影响范围组件、目录、站点、脚本、文档等。若包含多个文件或多类小改动用一个更高层级的概括覆盖全部不要逐项拼接成长句。4. 对齐 ant-design 仓库风格优先模仿仓库近期写法。对于 ant-design通常可见这些形式fix(Component): ...docs: ...chore: ...ci: ...site: ...注意不要强行把所有提交都写成严格的 Conventional Commits。如果仓库已有更自然的写法优先贴近仓库已有习惯。若改动主要在site可用site: ...若是明确修 bug也可用fix(site): ...。5. 生成一行 message输出应满足一行覆盖全部 staged changes简洁与仓库风格一致可直接拿去提交写法要求标题格式优先使用以下之一type(scope): subject或scope: subject例如fix(Table): correct pagination when data is emptydocs: update FAQ link in issue templatesite: add one-click copy theme code button标题规则使用祈使语气写现在要做什么如add/fix/update首字母不要大写除非scope是组件名如Button、Table结尾不要句号尽量控制在72 个字符内不要出现WIP、misc、update files这类空泛表述type 选择常见类型feat新增功能fix修复问题docs文档改动refactor重构test测试改动chore依赖、脚本、工程杂项ciCI 流程改动site站点展示、文档站交互、官网相关不确定时有用户可见行为修正优先fix只是文字、示例、说明更新优先docs只是工具链、依赖、脚本调整优先chorescope 选择改动集中在单个组件时用组件名如Button、Table改动集中在目录或模块时用site、scripts、docs若没有明确 scope允许省略边界情况多类改动混在一起如果 staged changes 混合了文档、样式、类型、小修复等内容优先找主目的如果没有单一主目的用更上层的概括目标是“诚实地覆盖全部改动”不是把每个点都塞进标题提交内容过于分散若暂存区包含明显不相关的多组改动仍然给出一个尽量诚实的一行 message不要假装这些改动只有一个很具体的目的可使用较宽的概括如chore(components): clean up styles, types and docs禁止不读取git diff --cached就写 message只根据文件名猜测内容只描述部分文件或部分改动忽略其它已 stage 内容输出多行说明把分析当成 commit message为了套格式而违背仓库已有风格写超过 72 个字符的冗长标题除非很难避免参考更多 type、scope、antd 风格示例与边界情况见references/format-and-examples.md。3e:[“,,,L48”,null,{“content”:“$49”,“frontMatter”:{“name”:“antd-commit-msg”,“description”:“Generate a single-line commit message for ant-design by reading the project’s git staged area and recent commit style. Use when the user asks for a commit message, says \“msg\”, \“commit msg\”, \“写提交信息\”, or wants one-line text that covers all staged changes. Output should match the repository’s existing commit style and summarize all staged changes in one line.”}}]
