commit-messages

name	commit-messages
description	Generates conventional commit messages from staged changes. Use when committing and needing a well-formatted message. Do not use for full PR prep; use pr-prep.
alwaysApply	false
category	artifact-generation
tags	["git","commit","conventional-commits"]
tools	[]
complexity	low
model_hint	fast
estimated_tokens	350

Conventional Commit Workflow

When To Use

• Generating conventional commit messages from staged changes

When NOT To Use

• Full PR preparation: use sanctum:pr-prep
• Amending existing commits: use git directly

Steps

1. Gather context (run in parallel):

   • git status -sb
   • git diff --cached --stat
   • git diff --cached
   • git log --oneline -5
   • When sem is available (see leyline:sem-integration): sem diff --staged --json for entity-level changes

   If nothing is staged, tell the user and stop.

   When sem output is available, use entity names (function, class, method) in the commit subject and body instead of parsing raw diff hunks. For example, "add function validate_webhook_url" instead of "add validation logic to notify.py".

2. Classify: Pick type (feat, fix, docs, refactor, test, chore, style, perf, ci) and optional scope.

3. Draft the message:

   • Subject: <type>(<scope>): <imperative summary> (50 chars max)
   • Body: What and why, wrapped at 72 chars
   • Footer: BREAKING CHANGE or issue refs

4. Slop check: reject these words and replace with plain alternatives:

   Reject	Use instead
   leverage, utilize	use
   seamless	smooth
   comprehensive	complete
   robust	solid
   facilitate	enable
   streamline	simplify
   optimize	improve
   delve	explore
   multifaceted