commit

Conventional Commits

The core goal is to state this change clearly with one accurate, concise, traceable message.

Process

1. Prioritize understanding the purpose and scope of the change from the current session. When information is insufficient, only read what is needed to determine the message, git status and the relevant diff; do not expand the investigation just to re-understand known changes.

2. When the commit message involves business terminology, prioritize the unified terminology already known from the current session.

3. Generate the commit message in the following format:

   <type>[(scope)]: <summary>
   
   [body]
   
   [footer]
   

1. Choose the type closest to the purpose of the change:
   • feat new feature;fix bug fix;refactor refactor;perf performance optimization;
   • docs documentation;test tests;build build or dependencies;ci continuous integration;
   • style formatting adjustments that do not affect logic;chore other maintenance;revert revert commit.
2. scope Use only when it can reliably point to a module, component, or business domain; omit it when it cannot be accurately categorized.
3. summary Use the imperative mood and directly describe the result brought by the change; do not add a period, and keep the title within 72 characters. Follow terminology already established by the user and in the code, and do not invent naming.
4. Add bodyonly when the title alone cannot clearly explain the content or reason for the change; explain "what was changed and why it was changed", and do not restate code implementation details.
5. For breaking changes, add !after the type, and write it in footer stated in BREAKING CHANGE: <影响>. Use related information as needed Refs: #123。
6. One message should express only one logical change. When a change contains multiple independent purposes, it should be split into separate commits.

Execution Boundaries

• When the user only asks to "write a commit message" or "review a message", only output the result and do not perform Git writes.
• When the user asks to "commit", only stage changes related to the current session. If the ownership of already staged content is unclear, use the question tool to confirm before writing.
• Do not automatically push.

Examples

fix(订单): 处理空订单号时不再崩溃

feat(api)!: 使用信封格式包装审批响应

统一响应元数据的承载方式。

BREAKING CHANGE: 客户端必须从 data 字段读取原响应内容