From ts-dev-kit
Writes, reviews, and validates git commit messages following Conventional Commits v1.0.0. Helps select types (feat/fix/etc), mark breaking changes, format multi-line commits, and map to SemVer bumps.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ts-dev-kit:conventional-commitsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<live_context>
<live_context>
Staged changes (summary):
!git diff --cached --stat 2>/dev/null || echo "(nothing staged)"
Staged diff:
!git diff --cached 2>/dev/null | head -300 || echo "(nothing staged)"
Recent commits (style reference):
!git log --oneline -8 2>/dev/null || echo "(no commits yet)"
</live_context>
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
feat(auth):": "Token: value or Token #value)| Type | Use for | SemVer |
|---|---|---|
feat | New feature | MINOR |
fix | Bug fix | PATCH |
docs | Documentation only | none |
style | Formatting, whitespace (no logic change) | none |
refactor | Code restructure (not a fix or feature) | none |
perf | Performance improvement | none |
test | Adding or fixing tests | none |
build | Build system, dependencies (npm, gradle…) | none |
ci | CI configuration (GitHub Actions, CircleCI…) | none |
chore | Maintenance not fitting above types | none |
revert | Reverts a previous commit | none |
Any type + BREAKING CHANGE → MAJOR.
Two ways to signal a breaking change (can combine both):
1. ! after type/scope (visible at a glance):
feat(api)!: remove deprecated v1 endpoints
2. BREAKING CHANGE: footer (required if you need a description):
feat: allow config object to extend other configs
BREAKING CHANGE: `extends` key now used for extending config files
Both together:
chore!: drop support for Node 6
BREAKING CHANGE: use JavaScript features not available in Node 6.
Simple fix:
fix: prevent racing of requests
Feature with scope:
feat(lang): add Polish language
Fix with body and footers:
fix: prevent racing of requests
Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.
Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
Reviewed-by: Z
Refs: #123
Revert with footer references:
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
Docs with no body:
docs: correct spelling of CHANGELOG
Co-Authored-By trailers to commit messages. This project does not use authorship footers.BREAKING CHANGE footer token must be uppercase.BREAKING-CHANGE (hyphen) is a valid synonym for BREAKING CHANGE in footers.- instead of spaces (e.g. Reviewed-by), except BREAKING CHANGE.": " (colon-space) or " #" (space-hash for issue refs): Refs #123.Token: or Token # pair.Is it a new user-facing capability? → feat
Is it fixing incorrect behavior? → fix
Is it changing docs/comments only? → docs
Is it improving speed/memory? → perf
Is it reorganizing code (no behavior Δ)? → refactor
Is it adding/fixing tests only? → test
Is it CI pipeline config? → ci
Is it build tooling or dependency updates? → build
Is it undoing a previous commit? → revert
Everything else (scripts, config, etc.)? → chore
fix→PATCH, feat→MINOR, BREAKING CHANGE→MAJOR
npx claudepluginhub jgamaraalv/ts-dev-kit --plugin ts-dev-kitComposes git commit messages following Conventional Commits spec for structured history, changelogs, and semantic versioning. Use when writing commits for semantic-release, commitizen, git-cliff or indicating breaking changes.
Generates concise conventional git commit messages prioritizing 'why' over 'what', with proper types, scopes, imperative mood, and atomic structure. Use when writing commits or learning best practices.
Crafts structured Git commit messages with type-prefixed subjects (feat, fix), explanatory bodies on why changes were made, and footers for issues or breaks, acting as code documentation.