Home
ce-commit
everyinc/compound-engineering-plugin
Create a git commit with a clear, value-communication message. Use when the user asks to commit/save staged or unstaged changes with a repo-appropriate, value-communicating message.
...Expand allAbout ce-commit
A workflow for creating a single, well-crafted git commit from the current working tree, producing a message that communicates value and follows repository conventions when they exist and conventional commit format otherwise. It activates when the user asks to commit, save changes, or create a commit from staged or unstaged work. On Claude Code it consumes pre-populated git status, working tree diff, current branch, recent commits, and remote default branch sections directly, and on other platforms it runs a single fallback command to gather the same context.
The workflow runs in five steps. Step 1 gathers context and handles edge cases: a clean tree means there is nothing to commit, and a detached HEAD prompts the user, via the platform's blocking question tool, about creating a feature branch. Step 2 determines the message convention by priority, preferring documented repo conventions, then a pattern inferred from the ten most recent commits, then conventional commits of the form type scope description with types like feat, fix, docs, refactor, test, chore, perf, ci, style, and build; where fix and feat both fit it defaults to fix. Step 3 lightly considers splitting clearly distinct concerns into separate commits, grouping at the file level only, with two or three logical commits described as the sweet spot.
Step 4 stages and commits, and if the current branch is main, master, or the resolved default branch it automatically creates a feature branch first rather than committing on the default branch. Messages use a concise imperative subject focused on why over what, with an optional body for non-trivial changes, and staging prefers naming specific files over git add all to avoid sweeping in sensitive files; commits are written with a heredoc to preserve formatting. Step 5 confirms success by running git status and reporting the resulting commit hashes and subject lines.
FAQ
What commit message format does it use by default?
It prefers documented repo conventions, then a pattern inferred from the ten most recent commits, and otherwise falls back to conventional commits in the form type scope colon description.
Will it commit directly on the main branch?
No. If the current branch is main, master, or the resolved default branch, it automatically creates a feature branch first before committing.
When does it choose fix versus feat?
When both seem to fit it defaults to fix, treating a change that remedies broken or missing behavior as fix and reserving feat for genuinely new capabilities.
Does it split changes into multiple commits?
It lightly scans for clearly distinct concerns and may create separate commits grouped at the file level only, with two or three logical commits considered the sweet spot.
How does it avoid committing sensitive files?
It prefers staging specific files by name rather than using git add -A or git add ., to avoid accidentally including files like .env or credentials.
Create well-crafted local commit(s) from the current working tree. No push, no PR — use ce-commit-push-pr for the full ship flow.
Done when: each logical change is committed with an explicit file list and a message that states the outcome, and git status is clean of those changes. Stop when: the tree is clean (nothing to commit).
Context
Gather context with each command as its own shell tool call (program + args only). Do not join with ;, &&, ||, pipes, $(...), or redirects — that syntax fails under Windows PowerShell. A non-zero exit is a normal state to interpret, not a failure to suppress.
| Command | Purpose | Non-zero / empty means |
|---|---|---|
git status | Working-tree state | Not a git repo — stop |
git diff HEAD | Uncommitted changes | Unborn repo / no commits yet |
git branch --show-current | Current branch | Empty = detached HEAD |
git log --oneline -10 | Recent message style | Unborn repo — no history |
git rev-parse --abbrev-ref origin/HEAD | Remote default branch | No origin/HEAD / bare HEAD — try gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', else main |
Treat this as a snapshot. Re-read branch and staged set immediately before committing if anything may have changed.
Default branch name: strip a leading origin/ from origin/HEAD (so origin/trunk → trunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.
Workflow
Gather — run every Context command above (own shell call each), then continue.
Nothing to commit — if
git statusshows no staged, modified, or untracked files, report that and stop. Do not usegit diff HEADalone as cleanliness (it misses untracked files).Branch first — if detached HEAD, or on the default branch (
main/master/ the bare default name above), create a feature branch from the change content (git checkout -b <name>), then re-readgit branch --show-current. Do not ask — commit-only still must not leave work only on a detached HEAD or the default branch. If the derived name exists, pick a non-conflicting suffix.Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (
type(scope): description). When using conventional commits andfix/featboth fit, default tofix:(remedying broken or missing behavior); reservefeat:for new capabilities. User override wins.Logical commits — if changed files clearly split into distinct concerns, make separate commits (file level only, 2–3 max, no
git add -p). If ambiguous, one commit.Message — subject is imperative and names the outcome (what is now possible or fixed), not the file list. Body only when motivation or trade-offs are not obvious from the subject. When a plan Implementation Unit ID is already in hand for this commit (conversation, caller, or the files belong to one unit), append that unit's U-ID in parentheses —
(U3)means unit 3. Do not hunt for a plan. Omit when the commit spans units, the unit is unclear, or no plan is in hand.- Bad:
Update checkout.rb/Add tests and fix stuff - Good:
Fix double-submit on checkout - Good:
Add per-subscription mute (U3)
- Bad:
Stage and commit — stage named files only (never
git add -Aorgit add .). Honorexclude:<paths>when the invocation carries it: those files stay uncommitted no matter what else changed; say in the report that they were left out. Prefer one shell call per commit group:
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'type(scope): subject line hereOptional body when the why is not obvious from the subject.EOF)" -- file1 file2 file3
The trailing path list on git commit is load-bearing: a bare git commit takes the whole index, so anything already staged before this run (a caller's exclude: paths, or work the user staged and did not name) would ride into the commit. Naming the paths commits exactly the group and leaves other index entries alone.
- Confirm —
git status; report hash(es) and subject(s).
All Files
0 filesInstall ce-commit
Download and extract the skill files to your .claude/skills/ directory.
Download ZIPClone the repository and copy the skill files to your project.
git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
Copy
