badrusiddique enggenie:dev-commit
Announce: "I'm using enggenie:dev-commit to create a commit message."
Overview
Analyze staged changes and propose a well-crafted commit message. The message explains WHY something changed, not just what changed. Every commit gets user approval before it lands.
Step 1: Analyze Staged Changes
Run these commands to understand what is being committed:
git status
git diff --staged
Read the full diff output. Understand:
- Which files changed and why
- Whether the changes are a new feature, bug fix, refactoring, documentation, test, or performance improvement
- The relationship between changed files (are they part of one logical change?)
If nothing is staged, tell the user: "No changes are staged. Stage your changes with git add first."
Step 2: Propose Commit Message
Commit Types
Only use the following types:
| Type | When to use |
|---|---|
feat: |
New feature or capability |
fix: |
Bug fix |
refactor: |
Code restructuring without behavior change |
docs: |
Documentation only |
style: |
Formatting, whitespace, linting (no logic change) |
test: |
Adding or updating tests |
perf: |
Performance improvement |
chore: |
Build, config, tooling, dependencies |
Format
<type>: <concise_description>
<optional_body_explaining_why>
Rules
- Present tense. "add feature" not "added feature"
- Explain why, not what. The diff shows what changed. The message explains the motivation.
- Subject line under 72 characters.
- One logical change per commit. If staged changes cover multiple unrelated things, suggest splitting them.
- No co-authored-by tags. The commit should look human.
- No AI attribution. Do not add any mention of AI assistance.
Step 3: Present and Confirm
Show the user:
- Summary of staged changes - brief overview of what is staged
- Proposed commit message - the full message with type and body
- Ask for confirmation - "Commit with this message? (yes/edit/cancel)"
NEVER auto-commit. Wait for explicit user approval.
If the user wants to edit, incorporate their changes and re-present. If they cancel, do nothing.
Step 4: Commit
Only after user confirms:
git commit -m "<approved message>"
Report the result: commit hash, branch, and files committed.
Hard Rules
- Never commit without user approval. Present the message, wait for "yes."
- Never add co-authored-by or AI attribution. Commits must look human-written.
- Never commit unstaged changes. Only commit what is in the staging area.
- Never commit secrets. Check staged files for .env, credentials, API keys, tokens. Warn the user if detected.
Shortcut Tax
When the user's request matches a shortcut pattern from this table, show them the relevant row and explain the cost before proposing a proper alternative. Do not silently ignore shortcuts -- surface the cost explicitly.
| Shortcut | What it costs you |
|---|---|
| "Just commit it, I'll fix the message later" | You won't. Commit history becomes unreadable. Future you wastes time deciphering cryptic messages. |
| "One big commit is fine" | Can't bisect, can't revert cleanly, can't understand changes in review. Split by logical unit. |
| "The diff speaks for itself" | Diffs show WHAT changed. Only messages explain WHY. Future debuggers need the why. |
| "I'll add the body later" | Later never comes. Write the why now while context is fresh. |
| "Generic message is fine" | "fix stuff" tells nobody anything. 10 seconds to write a good message saves 10 minutes reading diffs. |
Gut Check
- Are you about to auto-commit? Stop. Show the message first.
- Does the subject line exceed 72 characters? Shorten it.
- Does the message say "what" but not "why"? Add the motivation.
- Are there .env files or credentials staged? Warn immediately.
- Are the staged changes one logical unit? If not, suggest splitting.
Recommended Model
Primary: haiku Why: Commit message generation is a lightweight task. Haiku is fast and sufficient.
Override: Use sonnet for complex commits spanning many files where understanding relationships matters.
This is a recommendation. Ask the user: "Confirm model selection or override?" Do not proceed until the user responds.
Jira Fallback
If no Jira ticket is referenced in the current conversation and the commit is for feature work (not a quick fix or chore), ask:
"Is there a Jira ticket for this work? I can include the ticket ID in the commit message."
If the user provides one, read the ticket using MCP tools to get the ticket title, and use it to write a better "why" in the commit body. If Jira MCP is not available, just use the ticket ID the user provides.
This is a soft fallback, not a blocking gate. If the user says no or skips it, proceed with the commit.
Entry Condition
None - can be invoked anytime there are staged changes.
Exit Action
Commit created (or cancelled). Resume previous workflow.