From dev-toolkit
Use when creating a git commit. Guides intelligent staging, conventional commit message authoring, and pre-commit validation.
npx claudepluginhub aeriondyseti/aeriondyseti-plugins --plugin dev-toolkitThis skill uses the workspace's default tool permissions.
When it's time to commit, don't just `git add -A && git commit`. Be intentional about what goes into each commit and craft a message that helps future readers understand *why* the change was made.
Guides systematic git commits: checks staging status, reviews diffs, splits changes into atomic commits, formats conventional messages. Use before PRs or when committing code.
Manages Git commit workflow using Conventional Commits format with safety protocols. Creates, validates, executes commits; handles hooks, PRs, and safety checks before operations.
Analyzes uncommitted git changes, excludes ephemeral files like node_modules or build/, groups by purpose into atomic conventional commits, validates code, and optionally pushes.
Share bugs, ideas, or general feedback.
When it's time to commit, don't just git add -A && git commit. Be intentional about what goes into each commit and craft a message that helps future readers understand why the change was made.
Run git status (never with -uall) and git diff to understand:
Read the diff carefully. Understand the full scope of changes before deciding how to group them.
Each commit should be a single logical unit of work. Ask:
If changes serve multiple purposes, stage and commit them separately. For example:
# First commit: the actual feature
git add src/search.ts src/index.ts tests/search.test.ts
git commit -m "feat: add vector search endpoint"
# Second commit: cleanup noticed along the way
git add src/utils.ts
git commit -m "refactor: extract shared embedding logic"
Prefer staging specific files by name rather than git add -A or git add ., which can accidentally include:
.env files or credentialsgit add src/feature.ts tests/feature.test.ts
Use git add -p (patch mode) if you need to stage only part of a file's changes.
.env, .env.local, credentials, secrets, API keysnode_modules/, build artifacts, .DS_StoreIf you see these in the diff, warn the user explicitly.
Follow the git-conventions skill for format. The key principles:
Match the type to the change: feat means a wholly new capability. fix means a bug fix. refactor means behavior-preserving restructuring. Don't use feat for a bug fix or fix for a new feature.
Imperative mood, lowercase: add search endpoint, not Added search endpoint or Adds search endpoint.
Focus on "why" over "what": The diff shows what changed. The message should explain why.
fix: update query parameterfix: handle empty search queries that crash the parserKeep it concise: Under 72 characters for the subject line. Add a body only when the reasoning isn't obvious.
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
[Optional body explaining why, not what.
Wrap at 72 characters.]
EOF
)"
After committing:
git log --oneline -5 to confirm the commit looks right--no-verify — fix the issue and create a new commit| Scenario | Approach |
|---|---|
| Single feature with its tests | One commit |
| Feature + unrelated cleanup | Separate commits |
| Bug fix + regression test | One commit |
| Multiple independent fixes | Separate commits |
| Work-in-progress checkpoint | One commit (can squash later) |