Stage and commit changes using conventional commits format
Scanned 9/12/2026
Install to Claude Code
npx -y skills add TypedDevs/bashunit --skill commit --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Commit?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/typeddevs-commit)More formats (shields.io, HTML) on the badges page.
---
name: commit
description: Stage and commit changes using conventional commits format
user-invocable: true
argument-hint: "[message hint]"
disable-model-invocation: true
allowed-tools: Bash, Read, Grep, Glob
---
# Commit with Conventional Commits
Stage and commit current changes using the conventional commits format.
> **IMPORTANT:** This skill MUST be used for ALL commits — even when the user says "commit" without `/commit`. Never commit without following these steps.
## Current State
- Branch: !`git branch --show-current`
- Status: !`git status --short`
- Staged diff: !`git diff --cached --stat 2>/dev/null`
- Unstaged diff: !`git diff --stat 2>/dev/null`
- Recent commits: !`git log --oneline -5 2>/dev/null`
## Arguments
- `$ARGUMENTS` - Optional hint for the commit message (e.g., `fix the snapshot comparison`)
## Instructions
1. **Review the state above** — understand what changed and why.
2. **Stage files** — add only the relevant changed files by name. Never use `git add -A` or `git add .`. Never stage files that contain secrets (`.env`, credentials, etc.).
3. **Determine the commit type** from the nature of the changes:
- `feat` — new feature or capability
- `fix` — bug fix
- `docs` — documentation only
- `style` — formatting, whitespace (no logic change)
- `refactor` — code restructuring (no behavior change)
- `test` — adding or updating tests
- `chore` — maintenance, tooling, config
- `perf` — performance improvement
4. **Determine the scope** from the area of the codebase affected:
- `assert` — assertions (`src/assert*.sh`)
- `runner` — test runner
- `cli` — CLI entry point, flags, options
- `doubles` — mocks, spies
- `docs` — documentation site
- `ci` — CI/CD, GitHub Actions
- Use the most specific scope that fits. Omit if changes span many areas.
5. **Write the commit message**:
- Format: `<type>(<scope>): <description>`
- Description: imperative mood, lowercase, no period, under 70 chars
- Focus on **why**, not what
- Add a body (separated by blank line) only if the why isn't obvious from the description
- Never mention AI, Claude, or automation in the message
6. **Create the commit**:
```bash
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>
<optional body>
EOF
)"
```
7. **Verify** the commit was created:
```bash
git log --oneline -1
```
## Examples
```
feat(assert): add assert_json_contains function
fix(runner): resolve parallel execution race condition
test(doubles): add spy verification edge cases
refactor(cli): extract option parsing into helper
docs: update installation instructions
chore(ci): upgrade shellcheck to v0.10
perf(runner): reduce subshell usage in test discovery
```
## Rules
- **One logical change per commit** — don't mix unrelated changes
- **Never use `--no-verify`** — if hooks fail, fix the issue
- **Never amend** unless the user explicitly asks
- **Always create a NEW commit** — even after a hook failure
- **Author**: use the git config identity (never commit as sandbox/default user)
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!