aitune-commit

# Conventional Commit ## Workflow 1. Run `git diff HEAD`, `git log --oneline`, `git status` to understand the changes 2. Compose **one** commit message covering the current task changes 3. Stage only the files that belong to the current task 4. Run `git commit -s -S -m "..."` to add the DCO sign-off and cryptographically sign the commit using the configured signing key. 5. After the commit succeeds, suggest one MR title that summarises the branch's overall purpose (derived from `git log origin/main..HEAD --oneline`). Rules: - Follow Conventional Commits format: `type(scope): description` - Pick the **dominant** type (most impactful: feat > fix > refactor > chore/docs/test) - Pick the **primary** scope (most commits, or most user-visible change) - If commits span unrelated areas, omit scope and describe the branch goal abstractly - Present as: `**MR title suggestion:** <title>` If commit signing is not configured, explain how the user can configure GPG or SSH signing and refer them to [GitHub's signing guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). The user must run the configuration steps. Do not modify their Git or signing-key configuration. **Never ask the user to confirm the commit message.** Commit directly once the message is selected. **Never offer multiple commit options or ask whether to split.** Always produce a single message. **Always use both `-s` and `-S` for commits, including amendments.** `-s` adds the `Signed-off-by` trailer; `-S` cryptographically signs the commit. If signing fails, report the error, suggest how the user can fix the signing setup, and wait for them to complete the configuration before retrying; do not fall back to an unsigned commit. **Never run `git push`.** Pushing is a manual step for the user. ## Format ``` <type>(<scope>): <description> [optional body] [optional footer(s)] ``` ## Types | Type | When to use | |------|-------------| | `feat` | New feature | | `fix` | Bug fix | | `chore` | Maintenance, deps, tooling (no prod code change) | | `docs` | Documentation only | | `refactor` | Code change that is neither fix nor feature | | `test` | Adding or fixing tests | | `perf` | Performance improvement | | `ci` | CI/CD configuration changes | | `revert` | Revert a previous commit | ## Rules - **type** and **description** are required - **scope** is optional — use the affected module/area (e.g. `feat(auth):`) - Description is lowercase, imperative mood, no period at end - **Single message line only** — do not manually add a body or footer; let `git commit -s` add the sign-off trailer - Keep it short and informative — aim for 50–72 chars, hard limit 120 - Breaking changes: add `!` after type/scope (`feat!:`) - Exception: `BREAKING CHANGE:` footer only if `!` alone is insufficient ## Examples ``` feat(plan): add diffusers benchmark group fix(ci): correct needs dependency in generate job chore: update aitune-benchmarks to main branch docs: add plan file format to CLAUDE.md refactor(builds): consolidate hub Dockerfiles feat!: rename platform key for Colossus GPU BREAKING CHANGE: platform key changed from RTX-PRO-6000 to RTX-PRO-6000-MAXQ-PCIE-96GB-Colossus ``` ## Common Mistakes - `fix: Fixed the bug` → should be `fix: fix the bug` (imperative, lowercase) - `feat: add new feature.` → no trailing period - `update: something` → `update` is not a valid type; use `chore` or `refactor` - First line > 72 chars → move detail to body - Offering multiple messages or asking to split → always pick one and present it