Atomic Commit Discipline
Overview
Turn completed work into small, reviewable commits with scoped validation, related task-state updates, and no unrelated files.
This skill is not a review template or ledger template. It focuses on minimal commits, exact staged paths, task-state coupling, validation, and commit messages. For shared harness terms, see ../../references/harness-patterns.md; when commit rules are absent, use references/build-when-missing.md. For delivery artifact evidence, see references/delivery-artifact-checklist.md.
When To Use
- The user asks to commit, split commits, stage exact paths, or avoid unrelated changes.
- You are preparing a commit and need to inspect
git status or diffs to avoid unrelated work.
- The worktree has multiple changes and you need to decide which belong in the same logical commit.
- A tracked task is completed, changed, or invalidated and its task-state update must travel with the related commit.
- The project requires Conventional Commits or a ledger entry paired with each commit.
Inputs Needed
- Current
git status, git diff, and git diff --cached.
- User goal and completed validation.
- Current task-state surface, such as
tasks.md, docs/tasks.md, or the repository's issue tracker reference.
- Repository commit rules and whether ledger entries must be committed together.
Execution Order
- First: Read
git status and relevant diffs to identify your changes and unrelated changes.
- Then: Split staged paths by one logical behavior per commit, include related task-state updates, and run the minimum relevant validation.
- Finally: Write a Conventional Commit message, commit, and re-check status and commit contents.
Step-by-Step Process
- Run
git status --short --branch and list all tracked and untracked changes.
- Read
git diff -- <path> for every file you intend to commit; do not commit changes you do not understand.
- If no commit discipline is documented, bootstrap the minimum grouping and validation checklist from
references/build-when-missing.md.
- Identify whether the change completes, changes, or invalidates a tracked task; if yes, include the corresponding task-state update in the same logical commit.
- Group by logical boundary: docs, tests, implementation, harness, ledger, and task state should not be mixed unless they describe the same logical change or repository rules require the same commit.
- Run the smallest validation command that matches each group; fix failures before committing.
- Use
git add <exact paths>; avoid git add . unless the whole worktree contains only this change.
- Write a Conventional Commit subject, and use the body for validation, skip reasons, task IDs, or linked artifacts when needed.
- After committing, run
git show --stat --oneline HEAD and git status --short.
Checks
- Scope: each commit has one logical purpose.
- Ownership: no user-owned changes or temporary generated files are included by accident.
- Task coupling: task-state updates are present when the commit fulfills, changes, or invalidates a tracked task; unrelated task churn is absent.
- Validation: the commit has matching pre-commit validation.
- Message: the subject describes behavior, not "update files."
- Ledger: if the repository requires
agent_chats in the same commit, it is staged with the change.
Output Format
# Atomic Commit Plan
## Detected Mapping
- work-state:
- ledger:
- validation:
## Worktree State
-
## Commit Groups
1. Subject:
Paths:
Task-state updates:
Validation:
## Excluded Changes
-
## Final Checks
- First:
- Then:
- Finally:
Common Mistakes
- Using
git add . and bringing unrelated files into the commit.
- Mixing features, formatting, docs, refactors, and temporary fixes in one commit.
- Splitting a completed task's status update into a later unrelated commit.
- Committing before reading the diff.
- Writing commit messages such as "fix" or "update."
- Committing after validation fails.
Example Prompts
- "Split these changes into atomic commits."
- "Commit only the harness docs and leave unrelated files unstaged."
- "Check git status and commit by logical group, including related task updates."
1---2name: atomic-commit-discipline3description: Use when splitting changes into atomic commits, preparing commits from mixed worktrees, staging exact paths, including related task-state updates, writing Conventional Commits, or preventing unrelated changes.4---56# Atomic Commit Discipline78## Overview910Turn completed work into small, reviewable commits with scoped validation, related task-state updates, and no unrelated files.1112This skill is not a review template or ledger template. It focuses on minimal commits, exact staged paths, task-state coupling, validation, and commit messages. For shared harness terms, see `../../references/harness-patterns.md`; when commit rules are absent, use `references/build-when-missing.md`. For delivery artifact evidence, see `references/delivery-artifact-checklist.md`.1314## When To Use1516- The user asks to commit, split commits, stage exact paths, or avoid unrelated changes.17- You are preparing a commit and need to inspect `git status` or diffs to avoid unrelated work.18- The worktree has multiple changes and you need to decide which belong in the same logical commit.19- A tracked task is completed, changed, or invalidated and its task-state update must travel with the related commit.20- The project requires Conventional Commits or a ledger entry paired with each commit.2122## Inputs Needed2324- Current `git status`, `git diff`, and `git diff --cached`.25- User goal and completed validation.26- Current task-state surface, such as `tasks.md`, `docs/tasks.md`, or the repository's issue tracker reference.27- Repository commit rules and whether ledger entries must be committed together.2829## Execution Order3031- First: Read `git status` and relevant diffs to identify your changes and unrelated changes.32- Then: Split staged paths by one logical behavior per commit, include related task-state updates, and run the minimum relevant validation.33- Finally: Write a Conventional Commit message, commit, and re-check status and commit contents.3435## Step-by-Step Process36371. Run `git status --short --branch` and list all tracked and untracked changes.382. Read `git diff -- <path>` for every file you intend to commit; do not commit changes you do not understand.393. If no commit discipline is documented, bootstrap the minimum grouping and validation checklist from `references/build-when-missing.md`.404. Identify whether the change completes, changes, or invalidates a tracked task; if yes, include the corresponding task-state update in the same logical commit.415. Group by logical boundary: docs, tests, implementation, harness, ledger, and task state should not be mixed unless they describe the same logical change or repository rules require the same commit.426. Run the smallest validation command that matches each group; fix failures before committing.437. Use `git add <exact paths>`; avoid `git add .` unless the whole worktree contains only this change.448. Write a Conventional Commit subject, and use the body for validation, skip reasons, task IDs, or linked artifacts when needed.459. After committing, run `git show --stat --oneline HEAD` and `git status --short`.4647## Checks4849- Scope: each commit has one logical purpose.50- Ownership: no user-owned changes or temporary generated files are included by accident.51- Task coupling: task-state updates are present when the commit fulfills, changes, or invalidates a tracked task; unrelated task churn is absent.52- Validation: the commit has matching pre-commit validation.53- Message: the subject describes behavior, not "update files."54- Ledger: if the repository requires `agent_chats` in the same commit, it is staged with the change.5556## Output Format5758```markdown59# Atomic Commit Plan6061## Detected Mapping62- work-state:63- ledger:64- validation:6566## Worktree State67-6869## Commit Groups701. Subject:71 Paths:72 Task-state updates:73 Validation:7475## Excluded Changes76-7778## Final Checks79- First:80- Then:81- Finally:82```8384## Common Mistakes8586- Using `git add .` and bringing unrelated files into the commit.87- Mixing features, formatting, docs, refactors, and temporary fixes in one commit.88- Splitting a completed task's status update into a later unrelated commit.89- Committing before reading the diff.90- Writing commit messages such as "fix" or "update."91- Committing after validation fails.9293## Example Prompts9495- "Split these changes into atomic commits."96- "Commit only the harness docs and leave unrelated files unstaged."97- "Check git status and commit by logical group, including related task updates."