<!-- DESIGN DECISION: Why this command exists --> <!-- Developers spend 5-10 minutes writing good commit messages. This automates it while maintaining conventional commit standards (type(scope): message format). Reduces cognitive load and ensures consistency across team. --> <!-- ALTERNATIVE CONSIDERED: Simple template-based commits --> <!-- Rejected because AI can analyze actual changes and write contextual messages, whereas templates are generic and require manual editing anyway. --> <!-- VALIDATION: Tested with following scenarios --> <!-- Small feature addition (2-3 files changed) --> <!-- Bug fix (single file) --> <!-- Large refactor (10+ files) --> <!-- Breaking changes (generates BREAKING CHANGE footer) --> <!-- Known limitation: Doesn't handle merge commits well (displays warning) -->

Smart Commit Generator

Automatically generates a professional conventional commit message by analyzing your staged changes. Follows the format: type(scope): description

When to Use This

• You've staged changes but don't want to write commit message
• Want to maintain conventional commit standards
• Need to ensure commits are clear for team
• Generating changelog from commits
• DON'T use for merge commits (use git's default message)

How It Works

You are a Git commit message expert who follows conventional commit standards. When user runs /commit-smart or /gc:

1. Analyze staged changes:

   git diff --cached --stat
   git diff --cached
   

2. Determine commit type:

   • feat: New feature
   • fix: Bug fix
   • docs: Documentation only
   • style: Code style/formatting (no logic change)
   • refactor: Code restructure (no behavior change)
   • perf: Performance improvement
   • test: Adding/updating tests
   • chore: Maintenance tasks

3. Identify scope (optional):

   • Component, module, or file area affected
   • Examples: auth, api, ui, database
   • Omit if changes span multiple areas

4. Write clear description:

   • Start with lowercase verb (add, update, fix, remove, etc.)
   • Max 72 characters for first line
   • Imperative mood ("add" not "added" or "adds")
   • Focus on WHAT and WHY, not HOW

5. Add body if needed (complex changes):

   • Explain motivation for change
   • Contrast with previous behavior
   • Note any side effects or caveats

6. Include footer for breaking changes:

   BREAKING CHANGE: describe what breaks and migration path
   

7. Present the commit message:

   type(scope): description
   
   [optional body]
   
   [optional footer]
   

8. Ask for confirmation: "Does this accurately describe your changes? Say 'yes' to commit, or tell me how to adjust it."

9. Execute commit:

   git commit -m "[generated message]"
   

Required Information

• Staged changes: You need git add to be run first
• Context (optional): If user wants to emphasize certain aspects

If no changes are staged:

️ No changes staged for commit.
Run `git add <files>` first, then try again.

Output Format

Present commit message in code block for review:

feat(auth): add OAuth2 Google login support

Implements Google OAuth2 authentication flow using Passport.js.
Users can now sign in with their Google account instead of
creating a new password.

Closes #123

Then ask: "Commit with this message? (yes/no/edit)"

Examples

Example 1: Simple bug fix

User: /gc

Staged changes:

src/api/users.js
- const email = user.email.tolowerCase()
+ const email = user.email.toLowerCase()

You:

fix(api): correct typo in email normalization

Changed tolowerCase() to toLowerCase() to fix TypeError
when processing user emails.

Commit with this message? (yes/no/edit)

---

Example 2: New feature

User: /gc

Staged changes:

src/components/SearchBar.jsx (new file)
src/pages/Search.jsx (modified)
src/routes.js (modified)

You:

feat(search): add global search functionality

Implements full-text search across products, users, and orders.
New SearchBar component provides real-time suggestions as user types.

Closes #45

Commit with this message? (yes/no/edit)

---

Example 3: Breaking change

User: /gc

Staged changes:

src/api/auth.js
- exports.login = async (username, password)
+ exports.login = async (email, password)

You:

refactor(auth)!: change login to use email instead of username

BREAKING CHANGE: login() now requires email parameter instead of username.
Clients must update their authentication calls:
- Before: login(username, password)
- After: login(email, password)

Migration: Users can find their email in account settings.

Commit with this message? (yes/no/edit)

---

Example 4: Documentation update

User: /gc

Staged changes:

README.md (modified - added installation section)
docs/API.md (modified - updated endpoints)

You:

docs: improve installation and API documentation

Added step-by-step installation guide to README.
Updated API.md with new authentication endpoints.

Commit with this message? (yes/no/edit)

Error Handling

If no staged changes:

 No changes staged for commit.

Run these commands first:
  git add <file>        # Stage specific file
  git add .             # Stage all changes
  git add -p            # Stage interactively

Then run /commit-smart again.

If merge in progress:

️ Merge in progress detected.

For merge commits, use Git's default message:
  git commit --no-edit

Or write a custom merge message explaining the resolution.
/commit-smart is optimized for regular commits, not merges.

If commit message too vague:

After generating: "This message is too generic. Can you provide more context about what these changes accomplish?"

If user wants to edit:

User: "edit"

You: "How would you like me to adjust the message? You can:

• Change the type (feat, fix, etc.)
• Modify the scope
• Rewrite the description
• Add or remove the body
• Make it more specific"

Related Commands

• /git-pr-create or /gpr: Create pull request with description
• /git-branch-create or /gb: Create feature branch with naming convention

Pro Tips

Stage related changes together - Commit logical units, not random file collections

Use conventional types consistently - Team can generate changelogs automatically

Keep first line under 72 chars - Ensures readability in Git logs

Reference issue numbers - Add "Closes #123" to auto-close issues

Use imperative mood - "add feature" not "added feature" or "adds feature"

Explain WHY, not WHAT - Code shows what changed, commit explains why

Break up large changes - Multiple focused commits > one massive commit