commit

Commit

Create smart, context-aware git commits with conventional commit messages.

Core Principle: Small Logical Chunks

Always prefer committing in the smallest logical chunks that are appropriate. Each commit should represent a single coherent change: one bug fix, one new function, one refactor, one documentation update, etc. Do not batch unrelated changes into a single commit.

Why this matters:

• Small commits are easier to review, revert, cherry-pick, and bisect.
• Each commit tells a clear story about one thing that changed and why.
• When something breaks, small commits make it straightforward to identify the cause.

What constitutes a "logical chunk":

• A single bug fix (even if it touches multiple files)
• A single new feature or capability
• A refactor that moves or renames code without changing behavior
• A documentation update
• A configuration or tooling change
• Test additions or updates for a specific feature

What does NOT belong in the same commit:

• A bug fix mixed with an unrelated refactor
• A new feature combined with formatting changes to unrelated files
• Documentation updates bundled with code changes they do not describe

Options

The user may provide these options inline:

• --push: Commit and push to remote after committing
• --staged: Commit only staged changes (ignore unstaged changes)
• --plan: Commit only the plan file
• --all: Stage and commit all changes (including untracked files)

Workflow

1. Check for Changes

Run these commands in parallel to understand the current state:

# See all changed and untracked files
git status

# See staged changes
git diff --cached

# See unstaged changes
git diff

# See recent commit messages for style reference
git log --oneline -10

If there are no changes at all (no staged, unstaged, or untracked files), report that there is nothing to commit and stop.

2. Determine What to Commit

First, resolve which files are in scope using these rules in order: