KB LabsDocs

Commit Plugin — AI commit messages

Last updated April 7, 2026


Generates conventional commits from git diff using a two-phase LLM strategy.

One line: Look at git status, group related changes, write conventional commit messages, apply them — all from one command.

Source: plugins/commit

The problem

Writing commit messages is the kind of task where the marginal cost of doing it right is annoying enough that most people don't. You either get wip, fixes, more changes — or you get a 30-minute grooming session before every push.

The Commit Plugin makes "doing it right" the path of least resistance.

What it does

Bash
# Generate and apply commits in one shot
pnpm kb commit commit --scope="@kb-labs/your-package"
 
# Or step-by-step
pnpm kb commit generate --scope="src/components/**"   # plan only
pnpm kb commit open                                    # review the plan
pnpm kb commit apply                                   # create the commits
pnpm kb commit push                                    # push (refuses force-push to main)

The plan is stored as an artifact (.kb/commit/current/plan.json) so you can edit it before applying — important when the LLM groups things you wanted to keep separate.

Architecture sketch

commit:commit
  ├─ scan git status (scoped)
  ├─ Phase 1 LLM: analyze file change list (cheap)
  │   └─ confidence < 0.7?
  │       └─ Phase 2 LLM: re-analyze with full diff (expensive)
  ├─ post-process: validate commit types vs git operations
  │     (e.g. block "feat" on a deletion-only commit)
  ├─ secrets scan
  └─ apply: git add + commit per group

KB Labs primitives used

From the manifest, the platform surface is small and focused:

TypeScript
platform: {
  requires: ['storage', 'cache'],
  optional: ['llm', 'analytics', 'logger'],
},

What this gives the plugin:

  • llm (optional) — falls back to a heuristic generator if no LLM is configured. Useful for CI or offline.
  • cache — namespace commit:, used to deduplicate LLM calls when you re-run on the same diff.
  • storage — for the commit plan artifact (.kb/commit/current/plan.json).
  • CLI + REST + Studio — all three interfaces over the same core. Studio ships a commit.overview page; the REST surface (/scopes, /generate, /plan, /apply, /push, /regenerate-commit, ...) is what IDE integrations talk to.
  • Permissions presetsgitWorkflowPreset + kbPlatformPreset cover the boring env vars (HOME, USER, GIT_*, KB_*).

What to steal

The two patterns worth stealing:

  1. Two-phase LLM escalation. Phase 1 sees only file paths and stat lines (cheap, ~500 tokens). If the model is unsure, Phase 2 sees the full diff (expensive, can be 10k+ tokens). On most commits Phase 2 never runs. This is a much better UX than always sending the full diff "to be safe".

  2. Plan-as-artifact. The plugin writes its decision to a file before acting. The user can read it, edit it, regenerate one commit (POST /regenerate-commit), or throw the whole thing away (commit:reset). Any plugin doing destructive operations should follow the same pattern: plan first, apply second, never both in one step without --yes.

Going deeper

Commit Plugin — AI commit messages — KB Labs Docs