This document defines how commits should be named and which ones appear in the changelog.
Consistent commit naming keeps release notes clear and meaningful for users, while avoiding noise from internal work.
Each commit message starts with one of the keywords below, followed by a short description in plain English.
Example:
feat: add --auto-resume flag for interrupted tests
fix: avoid crash when results folder is missing
change: rename --standalone-attacks to --include-standalone-inputs
dataset: refresh base_user_inputs.jsonl with updated prompts
dev: refactor result parser for readability
docs: clarify README usage examples
New features or major improvements visible to users.
Examples:
feat: add --auto-resume flagfeat: improve CLI progress display
Bug fixes — things that were broken now behave correctly.
Examples:
fix: avoid crash when results folder is missingfix: correct default output path
Non-breaking behavior or UX changes that users will notice.
Examples:
change: enable language matching by defaultchange: rename CLI flag for clarity
Changes to bundled datasets, prompts, or test seeds that affect tool behavior or evaluation results.
Examples:
dataset: update base_user_inputs.jsonldataset: correct mislabeled input samples
Internal maintenance, refactors, or cosmetic changes with no user-facing impact.
Examples:
dev: refactor runner for simplicitydev: rename variables for clarity
Documentation changes — READMEs, examples, or guides.
Examples:
docs: update usage examplesdocs: fix changelog typo
Commits included in CHANGELOG.md:
feat, fix, change, dataset
Commits excluded from the changelog:
dev, docs
- Keep commit messages under 80 characters.
- Use imperative mood (
add,fix,update, notaddedorfixed). - Write clear, self-contained commits — one logical change per commit.
- Avoid merging work with vague messages like “misc updates” or “wip”.