numencore-toolkit/plugins/git-tools/skills/commit-format/SKILL.md

name	description	user-invocable	argument-hint	allowed-tools
commit-format	Generate a conventional commit message from staged changes and commit after user approval. Use when the user wants to commit staged work.	true	[type] [scope] [description]	Bash(git *)

Commit Format

Steps

1. Read the staged change summary:

   • git diff --cached --stat for file summary
   • Do NOT read the full diff — infer intent from the stat summary and file names
   • If nothing is staged, run git status --short and offer:
     • Stage all changes
     • Stage by file type or directory
     • Let the user specify which files
   • Wait for the user's choice and stage accordingly before continuing

2. Determine commit metadata:

   • If arguments were provided, use them as type/scope/description
   • If no arguments, infer from the diff:
     • type: feat, fix, refactor, docs, test, chore, build, ci, perf, style
     • scope: infer from the primary area of change (module, component, file group) — omit if unclear
     • description: one line summarizing what changed

3. Build the commit message:

   • Subject line: type(scope): description or type: description if no scope
   • Subject line must be under 72 characters
   • If the change warrants it, add a body separated by a blank line — short bullet points only
   • No emojis, no attributions, no co-authored-by lines
   • Body is for non-obvious context only — skip it if the subject says enough

4. Present the message to the user in a fenced block:

   feat(parser): add support for nested expressions
   
   - handle recursive descent for grouped terms
   - update token precedence table
   

5. Wait for user response:

   • If confirmed: run git commit -m with the message (use HEREDOC for multiline)
   • If edits requested: revise and present again
   • Never commit without explicit approval

Constraints

• One sentence subject lines — not paragraphs
• Prefer active voice, imperative mood ("add", "fix", "remove" — not "added", "fixes", "removing")
• If the diff is large, focus the message on intent, not listing every file
• When in doubt about type, ask the user rather than guess wrong