git-commit

git-commit

Automatically generates a Conventional Commits compliant commit message and commits staged changes.

Important:

• This skill only commits staged changes. It does not stage any new files
• DO NOT RUN git push

Behavior

1. Use the git-verify-identity skill to confirm git user identity before proceeding

2. Gather the current state by running:

   • git diff --staged — the staged changes to commit
   • git status — overall working tree state
   • git log --oneline -20 — recent commits, to learn the repository's style

3. Analyze the staged changes and recent commits

4. Scan the staged diff for potential secrets (see Secret Scan below); ask the user before proceeding if any are found

5. Generate a commit message following:

   • Conventional Commits specification (structure and basic rules)
   • User's commit style patterns learned from repository history

6. Execute git commit with the generated message

Secret Scan

Before committing, check the staged diff for:

• API keys and tokens: strings starting with ghp_, gho_, AKIA, sk-, xox, or matching -----BEGIN.*PRIVATE KEY
• Variables with sensitive names holding a value: patterns like API_KEY=, _SECRET=, _TOKEN=, PASSWORD=
• Hardcoded absolute home paths: /Users/<name>/ or /home/<name>/ (prefer ~)
• Personal or organizational proper nouns that could identify specific individuals or organizations

If any of the above are found, do not commit. Use AskUserQuestion to present these options:

• "Commit as-is" — proceed despite the finding
• "Fix then commit" — cancel so the user can fix the issue first
• "Cancel" — abort without further action

Only proceed if the user selects "Commit as-is", or if nothing suspicious was found.

Conventional Commits Specification Summary

Commit message structure:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Key rules:

• type: Required noun (feat, fix, chore, refactor, etc.) followed by optional scope and colon
• scope: Optional, describes section of codebase in parenthesis (e.g., fix(parser):)
• description: Required short summary immediately after colon and space
• body: Optional, provides additional context, begins one blank line after description
• footers: Optional, one blank line after body, uses git trailer format (e.g., Reviewed-by: Z)
• BREAKING CHANGE: Use exclamation mark after type/scope (e.g., feat!:) or footer BREAKING CHANGE: for breaking changes