atomic-commit

Atomic Commit

The core goal is for each commit to have independently explainable business meaning and to be directly rollback-able as a whole. Commit boundaries are determined jointly by the complete business result, delivery completeness, and rollback boundary, without pursuing the smallest or finest granularity.

Atomicity criteria

Business meaning: After this commit is completed, the user, a role, or the system gains a complete capability, or an observable business result is produced. The commit should be able to explain its value in business language, rather than only describing which files or technical layers were modified.
Complete delivery unit: The implementation, tests, documentation, configuration, migrations, and generated files required to jointly complete the same business result are placed in the same commit. On top of its dependency baseline, this commit can stand completely and be verified as a whole, without depending on remaining uncommitted changes.
Directly rollback-able: This delivery can be undone by rolling back the commit as a whole, without selecting hunks, also rolling back unrelated commits, or manually piecing together the restored state; after rollback, no obviously incomplete state is left behind.
Business boundaries take precedence over granularity: Do not split by number of files, amount of change, technical layer, or conventional commit type. As long as the content jointly forms a complete business result and shares verification and rollback boundaries, it is treated as one commit.
Split by business result: Split only when different and individually complete business results are formed and can be separately verified, delivered, and rolled back.

Process

Use the loaded CONTEXT terminology and RULE. If not yet loaded, follow the project knowledge protocol; if knowledge is unavailable, continue and state so truthfully.

Prefer to understand the purpose and scope of the changes based on the current session. View git status, and read only the relevant diff needed to divide commit boundaries and generate messages; do not expand the investigation just to re-understand already known changes.
Before staging, explain in business language the capability or observable result each commit unit completes, then verify its delivery completeness and direct rollback capability. Even when the caller has already given the boundaries, this validation still must be completed; do not re-split a complete business result based on file distribution or technical layer.
Execute for each delivery unit one by one:
- Stage only the paths or hunks of that unit;
- Check the staged diff to confirm the content is complete, contains no unrelated changes, and does not depend on remaining uncommitted changes;
- Reuse the verification already completed in the current session and truthfully preserve the verification boundary;
- Generate a message for the staged diff and complete the local commit, then handle the next unit.
When the delivery unit given by the caller is inconsistent with the diff, return a boundary conflict before writing. If the ownership of changes is unclear, or the commit method requested by the user would break delivery completeness or direct rollback capability, ask for confirmation.
When the commit message involves business terminology, use the unified terminology in CONTEXT, and use the following format:
```
<type>[(scope)]: <summary>

[body]

[footer]
```
Choose the type closest to the purpose of the change:
- feat new feature;fix bug fix;refactor refactoring;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.
scope Prefer stable business domains; if accurate classification is not possible, use modules or components, and if still inaccurate, omit it.
summary Use the imperative mood and directly describe the business outcome brought by the commit; for purely engineering delivery descriptions, describe the system capability or quality result formed, not as a checklist of file operations. Do not add a period, keep the title within 72 characters, and follow terminology already established by the user and in the code.
Only add this when the title alone cannot clearly explain the content or reason for the change body; explain "what changed and why it changed," and do not restate code implementation details.
For breaking changes, add after the type !, and in footer write BREAKING CHANGE: <影响>. Use related information as needed Refs: #123。

Execution boundaries

Only stage changes related to the current session. If the ownership of already staged content is unclear, ask for confirmation before writing.
Do not push automatically.

Example

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

feat(审批)!: 返回统一审批结果与元数据

审批接口统一返回业务结果与元数据。

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

About this skill

Atomicity criteria

Process

Execution boundaries

Example