// Create a conventional commit from staged changes, with a diff-derived description body.
| name | commit |
| description | Create a conventional commit from staged changes, with a diff-derived description body. |
Produce a single, well-formed conventional commit from the currently staged changes. The commit message follows the format:
<type>(<scope>): <subject>
<body>
This skill MUST be used whenever a task depends on creating a commit.
Follow these steps strictly and in order.
Run:
git diff --cached --stat
If the output is empty, stop immediately and inform the user:
"No staged changes found. Stage files with
git addbefore committing."
Do not auto-stage files. Do not proceed.
Load and execute the git-changes-context skill to obtain diff_context.
If the skill returns "error": "NO_DIFF_FOUND", fall back to using the staged diff:
git diff --cached
Capture whichever diff is available as diff.
Using diff, determine:
feat, fix, refactor, docs, style, test, chore, perf, ci, build, revert.If the user provided a hint (passed as $ARGUMENTS), use it as the subject line.
Still generate the body from the diff. If the hint already contains a type prefix
(e.g. fix: correct null check), honour it and do not override the type.
Construct the full commit message and run:
git commit -m "<full message>"
Use a HEREDOC to preserve newlines:
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
EOF
)"
Show the user:
Use when AI-generated or AI-modified changes need a Code Health gate before commit, handoff, or pull request.
Run linting and unit tests against the current repository, auto-discovering the correct commands from Justfile, Makefile, pyproject.toml, or package.json.
Reliably obtain a non-empty unified git diff for the current branch using safe fallbacks (origin/HEAD...HEAD, origin/main...HEAD, origin/master...HEAD) and return structured JSON containing the diff and the command used.
Produce an implementation plan with a functional-leaning, idiomatic style mindset; prefers lightweight data structures over dataclasses/pydantic unless justified.
Coding style policy for generated code: prefer idiomatic language conventions with a functional-leaning approach (pure-ish functions, composability), and prefer lightweight data structures over heavy schema/class abstractions unless clearly justified.