git-commit-helper

name	git-commit-helper
description	Generates commits with clear commit messages from git diffs. Use when creating commits and writing commit messages.

Generate conventional commit messages from git diffs with proper semantic prefixes and formatting Creates consistent, informative commit messages that follow conventional commit standards and explain what changed and why User asks to create a git commit User asks to commit changes User needs help writing a commit message After implementing features or fixes that need to be committed

<tool_restrictions> <allowed_tools> Run git commands (diff, status, log, commit) </allowed_tools> <allowed_git_commands> git diff HEAD - Analyze all changes (staged and unstaged) git status - Check repository state git log - Review recent commit message style git add - Stage files for commit git commit - Create commits </allowed_git_commands> <forbidden_git_commands> git push - Do not push unless user explicitly requests git commit --amend - Do not amend unless user explicitly requests git reset --hard - Never use destructive commands git rebase -i - Do not use interactive commands </forbidden_git_commands> </tool_restrictions>

Run git diff HEAD to analyze all changes before creating commit message Select correct semantic prefix based on change type - fix: for bug fixes, feat: for new features/enhancements, chore: for documentation/maintenance Do NOT include "Generated with [Claude Code]" footer in commit messages Keep summary line under 50 characters including prefix Include detailed description as bulleted list with affected components/files Use present tense in commit messages Explain what and why, not how Review recent git log to maintain style consistency with project Stage relevant files with git add before committing Run git diff HEAD to see all changes (staged and unstaged) Understand scope and nature of modifications Run git status to see which files are modified/added/deleted Identify all affected files Run git log --oneline -10 to see recent commit message style Maintain consistency with project commit conventions Are changes fixing existing functionality (fix:)? Are changes adding new features or enhancements (feat:)? Are changes only documentation or maintenance (chore:)? Verify summary line is under 50 characters including prefix Confirm prefix (fix:/feat:/chore:) matches the nature of changes Ensure detailed description lists affected components or files Verify commit message uses present tense Confirm no Claude Code footer is included Do not include "Generated with [Claude Code]" or similar footers Do not create empty commits if no changes detected Do not push to remote unless explicitly requested by user Do not amend commits unless explicitly requested by user Summary line must be under 50 characters

<prefix_selection> Correcting bugs or issues in existing functionality Fixing broken features or behavior Resolving errors or defects fix: Correct token validation in login Adding new features or components Enhancing existing functionality with new capabilities Introducing new code or behavior feat: Add dark mode toggle to settings Updating documentation Managing dependencies or package versions Performing maintenance tasks Refactoring without changing behavior chore: Update README with setup instructions </prefix_selection>

<commit_message_format>

[prefix]: [imperative description under 50 chars total]

<blank_line /> <detailed_description> - [Bullet point describing change and affected component] - [Additional bullet points as needed] - [Always mention affected files or components] </detailed_description>

<guideline>Use present tense imperative mood (Add, Fix, Update, not Added, Fixed, Updated)</guideline> <guideline>Explain what and why, not implementation details</guideline> <guideline>Be specific about affected components or files</guideline> <guideline>Keep summary focused on single main change</guideline>

</commit_message_format>

Run git diff HEAD to see all changes Run git status to check file states Optionally run git log to review project style Determine change type (fix/feat/chore) Identify affected components and files Write summary line with correct prefix (under 50 chars) Write detailed description with bulleted list Include affected components/files Stage relevant files with git add if not already staged Create commit using git commit with composed message Use heredoc format for proper message formatting Fixed authentication token validation issue Modified: src/auth/login.ts - Fixed token expiration check logic - Updated validation function fix: Correct token validation in login

  - Fixed token expiration check in auth/login.ts
  - Updated validateToken function logic
  - Affected components: authentication module
</commit_message>
<prefix_rationale>Used "fix:" because changes correct existing broken functionality</prefix_rationale>

Added dark mode support to application Added: src/components/DarkModeToggle.tsx Modified: src/App.tsx Modified: src/styles/theme.ts feat: Add dark mode toggle to settings

  - Created DarkModeToggle component
  - Integrated toggle into App.tsx settings
  - Updated theme.ts with dark mode colors
  - Affected components: UI settings, theme system
</commit_message>
<prefix_rationale>Used "feat:" because changes introduce new functionality</prefix_rationale>

Updated project documentation Modified: README.md Added: docs/setup-guide.md Modified: docs/api-reference.md chore: Update documentation for setup process

  - Enhanced README.md with quick start guide
  - Added detailed setup-guide.md
  - Updated api-reference.md with new endpoints
  - Affected files: documentation
</commit_message>
<prefix_rationale>Used "chore:" because changes only affect documentation, not code functionality</prefix_rationale>

Improved error handling across API endpoints Modified: src/api/users.ts Modified: src/api/auth.ts Modified: src/middleware/errorHandler.ts feat: Improve error handling in API endpoints

  - Enhanced error handling in users.ts and auth.ts
  - Updated errorHandler middleware with new patterns
  - Added detailed error messages for API failures
  - Affected components: API layer, middleware
</commit_message>
<prefix_rationale>Used "feat:" because changes enhance existing functionality with new error handling capabilities</prefix_rationale>

<error_handling> git diff HEAD returns empty Inform user no changes detected, do not create commit git commit command fails (hooks, conflicts, etc.) Report error details to user, do not retry automatically Changes span multiple types (fix + feat) Choose primary change type or ask user for clarification git diff output is extremely large Summarize major changes, group by component or file type </error_handling>

<related_skills> May invoke this skill after feature implementation to commit changes May invoke this skill after completing feature to commit work </related_skills>