Commit

Create well-crafted git commits from the current working tree, then close the loop with a compound scan.

Step 1: Gather context

Run each as its own shell call and read the exit status directly — a non-zero exit is a state to interpret, not a failure:

• git status — working-tree state.

Clean tree → report there is nothing to commit and stop.

• git diff HEAD — the uncommitted changes.
• git branch --show-current — empty output means detached HEAD: ask whether to create a branch or commit detached.
• git log --oneline -10 — recent commit style.
• git rev-parse --abbrev-ref origin/HEAD — the default branch (strip the origin/ prefix).

If unset, fall back to main.

Step 2: Branch off the default

If the current branch is the default branch (or main/master), create a feature branch before committing: derive the name from the change content, git checkout -b , and confirm with git branch --show-current. This is automatic — committing directly on the default branch is not an option here.

Step 3: Determine the message convention

In priority order:

1. Documented repo conventions already in context (AGENTS.md, CLAUDE.md, or similar).
2. Recent commit history — if the last 10 commits show a clear pattern (conventional commits, ticket prefixes, emoji prefixes), match it.
3. Default: conventional commits — type(scope): description, type one of feat, fix, docs, refactor, test, chore, perf, ci, style, build.

Where fix: and feat: both fit, prefer fix: — a change that remedies broken or missing behavior is a fix even when implemented by adding code; reserve feat: for capabilities the user could not previously accomplish.

Message discipline, whatever the convention:

• Subject: concise, imperative mood, focused on why the change has value, not what changed.
• Body: for non-trivial changes, a blank line then motivation, trade-offs, anything a future reader needs.

Omit for obvious single-purpose changes.

• Lines run their natural length — never hard-wrap message lines to a fixed width.
• The message ends at the last line of prose — no Co-Authored-By or similar generated trailers.

Step 4: Group, stage, and commit

Scan the changed files for naturally distinct concerns; if they clearly group into separate logical changes, commit each group. Keep it lightweight: group at the file level only (no hunk splitting), split only when the separation is obvious, and stay at two or three commits at most.

For each group, stage specific files by name — a targeted git add keeps sensitive files (.env, credentials) and unrelated changes out. Commit with a heredoc to preserve formatting:

git add file1 file2 && git commit -m "$(cat <<'EOF'
type(scope): subject line here

Optional body explaining why this change was made.
EOF
)"

Verify with git status and report the commit hash(es) and subject line(s).

Step 5: Scan for compound candidates

The learning tail of the loop. Scan the whole session for candidate learnings: root causes uncovered, gotchas hit, approaches that failed, conventions or preferences decided along the way.

Judge each against compound's quality bar — would it change a future agent's behavior in a different session, and is it non-obvious and stable? Session-specific trivia dies here.

• Any candidate might clear the bar → invoke the compound skill with the candidates; it routes each to a destination and gates every write on the user.
• None → say so in one line.

Committed, compound scan done → the loop is closed.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: toverux
• Source: toverux/grimoire
• License: MIT

Install and usage instructions live in the source repository linked above.