git-commit

# Git Commit with Conventional Commits ## Overview Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message. ## Conventional Commit Format ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ## Commit Types | Type | Purpose | | ---------- | ------------------------------ | | `feat` | New feature | | `fix` | Bug fix | | `docs` | Documentation only | | `style` | Formatting/style (no logic) | | `refactor` | Code refactor (no feature/fix) | | `perf` | Performance improvement | | `test` | Add/update tests | | `build` | Build system/dependencies | | `ci` | CI/config changes | | `chore` | Maintenance/misc | | `revert` | Revert commit | ## Breaking Changes ``` # Exclamation mark after type/scope feat!: remove deprecated endpoint # BREAKING CHANGE footer feat: allow config to extend other configs BREAKING CHANGE: `extends` key behavior changed ``` ## Host shell Do **not** assume Bash. Cursor on Windows uses PowerShell, where `&&`, `$(cat <<'EOF')`, and POSIX `[ -z ... ]` fail. - Prefer **separate git invocations** over chained one-liners. - If you must chain: PowerShell uses `;` (or separate calls). Bash/zsh may use `&&`. - Examples below show Bash and PowerShell when the syntax differs. ## Workflow ### 1. Analyze Diff ```bash # If files are staged, use staged diff git diff --staged # If nothing staged, use working tree diff git diff # Also check status git status --porcelain ``` From the diff, determine the commit **type** and a short **description** (needed for branch naming in step 2). ### 2. Ensure Feature Branch If the current branch is `main` or `master`, create a feature branch **before** staging or committing. ```bash git branch --show-current ``` **Branch naming** — documented prefixes in `CONTRIBUTING.md`: `feat/`, `fix/`, `docs/`. For other commit types, use the commit type as prefix (e.g. `chore/`): ``` <type>/<kebab-case-description> ``` | Commit type | Branch prefix | Example | | ----------- | ------------- | ------- | | `feat` | `feat/` | `feat/custom-shortcuts` | | `fix` | `fix/` | `fix/upload-timeout` | | `docs` | `docs/` | `docs/contributing-guide` | | other types | `<type>/` | `chore/add-create-pr-skill` (aligns with commit type; not listed in CONTRIBUTING.md) | Rules for `<kebab-case-description>`: - Lowercase, words separated by hyphens - Derived from the commit description (drop scope, articles, punctuation) - Keep it short (2–5 words), e.g. `add create pr skill` → `add-create-pr-skill` ```bash # Example: chore commit about adding create-pr skill git checkout -b chore/add-create-pr-skill ``` Do **not** commit directly on `main` or `master`. If the user explicitly asks to commit on the default branch, confirm before proceeding. ### 3. Stage Files (if needed) If nothing is staged or you want to group changes differently: ```bash # Stage specific files git add path/to/file1 path/to/file2 # Stage by pattern git add *.test.* git add src/components/* ``` Do **not** run `git add -p` (interactive; agents cannot complete it). Stage explicit paths instead. **Never commit secrets** (.env, credentials.json, private keys). ### 4. Generate Commit Message Analyze the diff to determine: - **Type**: What kind of change is this? - **Scope**: What area/module is affected? - **Description**: One-line summary of what changed (present tense, imperative mood, <72 chars) ### 5. Execute Commit Single line (any shell): ```bash git commit -m "<type>[scope]: <description>" ``` Multi-line with body/footer: ```bash # Bash / zsh git commit -m "$(cat <<'EOF' <type>[scope]: <description> <optional body> <optional footer> EOF )" ``` ```powershell # PowerShell git commit -m @" <type>[scope]: <description> <optional body> <optional footer> "@ ``` ## Best Practices - One logical change per commit - Present tense: "add" not "added" - Imperative mood: "fix bug" not "fixes bug" - Reference issues: `Closes #123`, `Refs #456` - Keep description under 72 characters ## Git Safety Protocol - NEVER update git config - NEVER run destructive commands (--force, hard reset) without explicit request - NEVER skip hooks (--no-verify) unless user asks - NEVER force push to main/master - If commit fails due to hooks, fix and create NEW commit (don't amend) ## Project Notes (doocs/md) - Commit messages and PR titles must be in **English** (see `AGENTS.md` and `CONTRIBUTING.md`) - Branch naming: `feat/`, `fix/`, `docs/` per `CONTRIBUTING.md`; for other commit types use `<type>/` prefix; never commit on `main`/`master` — create a branch first (step 2) - Pre-commit runs `eslint --fix` via lint-staged; if the hook modifies files, fix and create a new commit instead of amending