1---2name: git-commit3description: Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping4license: MIT5---67<!-- Generated from harness/github-copilot/skills/git-commit/SKILL.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->89# Git commit with Conventional Commits1011Create one logical Git commit by inspecting `git status --porcelain`, choosing the correct staged or working-tree diff, staging only intended files, and writing a Conventional Commits message that matches the actual change.1213## When to invoke1415- "Commit these changes."16- "Create a git commit for my staged files."17- "Use /commit for this diff."18- "Generate a conventional commit message and commit it."19- "Stage this logical change and commit it."2021## Commit workflow22231. Run `git status --porcelain` before touching the index.242. If files are already staged, inspect `git diff --staged`; otherwise inspect `git diff` for the working tree the user wants included.253. Decide whether the requested change is one logical commit. If unrelated changes are present, stage specific paths only: `git add path/to/file1 path/to/file2`.264. For mixed hunks in the same file, use `git add -p` instead of staging the whole file.275. Preserve a user-supplied type, scope, description, issue reference, or breaking-change note unless the inspected diff contradicts it; explain any necessary correction.286. Generate the subject from the diff: type, optional scope, and imperative description under 72 characters.297. Execute `git commit -m "<type>[scope]: <description>"` when the user asked to commit. For a body or footer, pass separate `-m` arguments rather than embedding command substitutions.308. If hooks fail, fix the hook findings and create a new commit attempt. Do not amend unless the user explicitly asks.3132## Conventional Commit format3334```text35<type>[optional scope]: <description>3637[optional body]3839[optional footer(s)]40```4142| Element | Rule | Example |43| --- | --- | --- |44| `type` | Choose the primary intent of the diff. | `feat`, `fix`, `docs` |45| `scope` | Add a short module, package, app, or feature area only when it clarifies ownership. | `api`, `auth`, `docs` |46| `description` | Present tense, imperative mood, no trailing period, preferably <72 chars. | `add token refresh guard` |47| `body` | Explain why, migration notes, or context that does not fit the subject. | `This keeps old clients working during rollout.` |48| `footer` | Use for issue references and breaking changes. | `Closes #123`, `Refs #456`, `BREAKING CHANGE: extends key behavior changed` |4950## Commit types5152| Type | Use when the diff primarily changes |53| --- | --- |54| `feat` | User-visible capability or supported behavior. |55| `fix` | Bug fix, regression, broken behavior, or incorrect output. |56| `docs` | Documentation only. |57| `style` | Formatting/style only, with no logic change. |58| `refactor` | Internal restructuring with no feature or fix. |59| `perf` | Performance improvement. |60| `test` | Test additions or corrections. |61| `build` | Build system, packaging, dependency, or generated artifact behavior. |62| `ci` | CI, workflow, release automation, or config changes. |63| `chore` | Maintenance/misc work that does not fit another type. |64| `revert` | Reverts an earlier commit. |6566## Staging rules6768| Situation | Command | Constraint |69| --- | --- | --- |70| Exact files requested | `git add path/to/file1 path/to/file2` | Stage only named files. |71| Test files by pattern | `git add *.test.*` | Confirm the pattern does not catch unrelated files. |72| Component directory | `git add src/components/*` | Use only when all files belong to the same logical change. |73| Partial file | `git add -p` | Prefer hunk staging to unrelated whole-file commits. |74| Already staged | `git diff --staged` | Do not replace the index unless the user asks. |7576## Git safety protocol7778- Never commit secrets: `.env`, `credentials.json`, private keys, tokens, or generated secret dumps.79- Never update git config as part of committing.80- Never run destructive commands such as `--force` pushes or hard resets without an explicit request.81- Never skip hooks with `--no-verify` unless the user explicitly asks.82- Never force push to `main` or `master`.83- Reference issues with `Closes #123` only when the diff actually completes the issue; use `Refs #456` for partial work.84- Preserve legacy decision labels when useful: `type/scope`, `body/footer`, `area/module`, `feature/fix`, `system/dependencies`, `CI/config`, and `Add/update` tests all map to the Conventional Commits choices above.85- NEVER force push to `main/master`; keep this uppercase warning visible because it is the core Git safety rule.8687## Breaking changes8889Use either an exclamation mark in the subject or a `BREAKING CHANGE:` footer; use both when the risk is high or external users must notice it.9091```text92feat!: remove deprecated endpoint9394feat: allow config to extend other configs9596BREAKING CHANGE: `extends` key behavior changed97```9899## Gotchas100101- **Do not stage by habit**: `git add .` can silently include secrets or another user's work.102- **Do not use past tense**: write `fix auth redirect`, not `fixed auth redirect`.103- **Do not force a vague scope**: omit the scope rather than writing `chore(repo)` when the type already carries the meaning.104- **Do not amend after hook failure by default**: the original instruction requires a new commit attempt unless the user asks for amend.105106## Output template107108```markdown109## Git commit result110111**Status:** committed | message only | blocked112**Files reviewed:** <staged count> staged, <unstaged count> unstaged, <untracked count> untracked113**Diff used:** `git diff --staged` | `git diff`114115**Commit message**116Subject: `<type>[optional scope]: <description>`117Body: `<body or none>`118Footer: `<footer(s) or none>`119120**Commands run**121- `git status --porcelain`122- `git diff --staged` or `git diff`123- `git add <paths>` / `git add -p` if staging was needed124- `git commit -m "<subject>" [-m "<body>"] [-m "<footer>"]`125126**Safety checks**127- Secrets check: pass | blocked with evidence128- Hook result: pass | fail with evidence129```130131## Quality gate132133- [ ] `git status --porcelain` was reviewed before staging or committing.134- [ ] The diff inspected is the diff being committed: `git diff --staged` for staged files or `git diff` for intended unstaged files.135- [ ] The commit contains one logical change and no unintended files.136- [ ] No secrets such as `.env`, `credentials.json`, private keys, or tokens are staged.137- [ ] The type is one of `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, or `revert`.138- [ ] The description is imperative, present tense, non-empty, and under 72 characters where practical.139- [ ] Breaking changes use `!` or a `BREAKING CHANGE:` footer.140- [ ] Hooks were not skipped unless the user explicitly requested `--no-verify`.
paulasilvatech