diff options
| -rw-r--r-- | AGENTS/HOW_TO_COMMIT.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/AGENTS/HOW_TO_COMMIT.md b/AGENTS/HOW_TO_COMMIT.md index fc94655..d12040c 100644 --- a/AGENTS/HOW_TO_COMMIT.md +++ b/AGENTS/HOW_TO_COMMIT.md @@ -64,7 +64,7 @@ Use conventional commit format, following [Conventional Commits 1.0.0](https://w 1. Inspect `git status --short`, `git diff` and `git diff --cached` to understand the working tree, the staged changes and the intended commit scope. 2. Review `git log -10 --format='%s'` for recent naming conventions. When useful, inspect related history with `git log -5 --format='%s' -- <affected paths>` or search commit messages with `git log --oneline --grep='<topic>'`. Use history to choose consistent scopes and terminology; base the message on the actual diff. 3. Choose a lowercase type: `feat` for a new feature, `fix` for a bug fix, `docs` for documentation, or `refactor`, `perf`, `test`, `build`, `ci`, `style` or `chore` when appropriate. Use a short scope for the affected subsystem when it adds useful context. -4. Write a concise English description in the imperative, without a trailing period. For example: `docs(agents): require conventional commit messages`. Add a body only when it helps explain the reason or consequences of the change. Separate the body and any trailers with blank lines. Mark breaking changes with `!` before the colon or a `BREAKING CHANGE:` footer explaining the incompatibility. +4. Commit messages must be clear and descriptive: state what changed and identify the affected behavior or component. Avoid vague summaries such as `update files` or `fix issues`. Write a concise English description in the imperative, without a trailing period. For example: `docs(agents): require conventional commit messages`. Add a body only when it helps explain the reason or consequences of the change. Separate the body and any trailers with blank lines. Mark breaking changes with `!` before the colon or a `BREAKING CHANGE:` footer explaining the incompatibility. 5. Preserve the user's staged selection and stage only additional files relevant to the authorized task, using explicit paths. Review `git diff --cached` and run `git diff --cached --check`, plus any checks appropriate to the changes, before committing. 6. Complete staging before creating the commit, then run `git status --short` after the commit succeeds. These dependent operations must run sequentially; only independent inspections may run in parallel. |