Automated summary

Optionally checks code (lint, build, tests) then commits it with a conventional commit message, creating a feature branch if needed.

When to use it

When you want to commit clean, well-formatted code following a standardized conventional commit style.

When not to use it

If you need to commit quickly without checks (use the `force` option) or if your changes include sensitive files that the skill cannot filter.

name: commit description: Optionally checks, then commits code to the current or a new feature branch.

When asked to commit code, follow these steps:

Arguments

check (default): Run checks first to lint, build, and test the code. Stop if any checks fail.
force: Skip the check step and commit directly.

Run these bash commands in parallel to understand the current state:
- git status to see all untracked files
- git diff HEAD to see both staged and unstaged changes
- git log --oneline -10 to see recent commit messages for style consistency
If you are on the main branch, create a new feature branch using git branch and switch to it.
Analyze all changes and draft a commit message:
- Summarize the nature of the changes (new feature, enhancement, bug fix, refactoring, test, docs, etc.)
- Use the conventional commit format: type(scope): description
- Keep the first line under 72 characters
- Do not commit files that likely contain secrets (.env, credentials.json, etc.)
Stage and commit the changes:
- Add relevant files using git add
- Use a plain string for the commit message (do not use HEREDOCs).
Report the results including:
- The commit hash
- The commit message