avinyc:commit
Git Commit Assistant
Analyze git changes and create logical, well-structured commits using conventional commit format.
When to Use
- User asks to commit changes
- Multiple unrelated changes need separate commits
- Changes need conventional commit formatting
Workflow
Step 1: Review Current State
Run git status to see all changes:
git status
Review both staged and unstaged changes. Identify modified, added, and deleted files.
Step 2: Analyze and Plan Commits
Group changes into logical commits based on:
- Feature boundaries: Files that implement the same feature together
- Type of change: Separate fixes from features from refactors
- Scope: Group by component, module, or area of the codebase
Present the commit plan to the user before proceeding:
I see the following logical commits:
1. feat(auth): Add password reset - auth/reset.rb, auth/mailer.rb
2. fix(api): Handle null responses - api/client.rb
3. docs: Update README - README.md
Step 3: Execute Commits One by One
For each planned commit:
Stage specific files only:
git add <file1> <file2>
Verify staging:
git status
Create commit with conventional format:
git commit -m "<type>[scope]: <description>" -m "<body>"
Verify commit succeeded:
git status
Only proceed to the next commit after verifying the current one completed.
Conventional Commit Types
| Type | Description |
|---|---|
| feat | New feature |
| fix | Bug fix |
| docs | Documentation only |
| style | Formatting, no code change |
| refactor | Code change, no new feature or fix |
| perf | Performance improvement |
| test | Adding or fixing tests |
| chore | Build process, auxiliary tools |
Commit Message Format
<type>[optional scope]: <description>
[optional body]
[optional footer]
- Description: Imperative mood, lowercase, no period ("add feature" not "Added feature.")
- Body: Explain what and why, not how
- Scope: Component or area affected (auth, api, db, ui)
Rules
- Never mix unrelated changes in a single commit
- Always verify staging before committing
- Always verify success after committing
- Explain the plan before executing
- Never use
git add .orgit add -Awithout explicit approval - Never include "Generated with Claude Code" or Co-Authored-By footers
Example Session
$ git status
# Modified: auth/login.rb, auth/signup.rb, README.md, api/client.rb
Plan:
1. feat(auth): Improve login validation - auth/login.rb, auth/signup.rb
2. fix(api): Handle timeout errors - api/client.rb
3. docs: Add authentication guide - README.md
Executing commit 1...
$ git add auth/login.rb auth/signup.rb
$ git status # verify only auth files staged
$ git commit -m "feat(auth): improve login validation" -m "Add email format check and rate limiting"
$ git status # verify commit succeeded
Executing commit 2...
[continues...]
More from aviflombaum/claude-code-in-avinyc
ux-ui
UX/UI design principles for clean, intuitive interfaces. Use when designing layouts, improving usability, planning information architecture, or ensuring accessibility. Triggers on "user experience", "usability", "information architecture", "accessibility", "interaction design".
12interview
Interview about a plan file to refine it through in-depth questioning. Use when you have a plan that needs validation, refinement, or deeper exploration before implementation. Triggers on "interview me about", "refine this plan", "question this spec".
9tailwind
Tailwind CSS patterns, utilities, and component styling for Rails. Use when styling with Tailwind, creating responsive layouts, or building UI components. Triggers on "tailwind", "style with", "css classes", "responsive layout".
9write
Write technical blog posts, tutorials, and documentation in Flatiron School's engaging style. Use for explaining code patterns, debugging stories, or turning complex topics into clear narratives. Triggers on "write a blog post", "tutorial about", "explain how", "technical writing".
8hotwire
Hotwire, Turbo, and Stimulus patterns for Rails. Use when implementing JavaScript interactions, Turbo Frames/Streams, or Stimulus controllers. Triggers on "stimulus controller", "turbo frame", "turbo stream", "hotwire", "rails javascript".
8write-test
Writes comprehensive RSpec tests for Rails applications. Use when writing model specs, request specs, system specs, job specs, mailer specs, channel specs, or storage specs. Triggers on "write tests for", "add specs to", "test the User model", "create request specs", "write RSpec", "add test coverage".
8