conventional-commits
This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.
<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>
Table of Contents
- Format
- Types and SemVer impact
- Breaking changes
- Examples
- Non-obvious rules
- Choosing the right type
- SemVer cheatsheet
Format
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
- type: lowercase noun (see table below)
- scope: optional noun in parentheses describing the affected section, e.g.
feat(auth): - description: imperative, present tense, no period at end, immediately after
": " - body: free-form; begins one blank line after description
- footers: one blank line after body; follow git trailer format (
Token: valueorToken #value)
Types and SemVer impact
| 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.
Breaking changes
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.
Examples
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
Non-obvious rules
- NEVER add
Co-Authored-Bytrailers to commit messages. This project does not use authorship footers. - Types are case-insensitive in parsing, but
BREAKING CHANGEfooter token must be uppercase. BREAKING-CHANGE(hyphen) is a valid synonym forBREAKING CHANGEin footers.- Footer tokens use
-instead of spaces (e.g.Reviewed-by), exceptBREAKING CHANGE. - Footer separator is either
": "(colon-space) or" #"(space-hash for issue refs):Refs #123. - A footer value may span multiple lines; parsing stops at the next valid
Token:orToken #pair. - When a commit fits multiple types, split into multiple commits instead of picking one.
- Wrong type used before merge? Ask the developer to fix manually with an interactive rebase. Claude Code cannot run interactive commands. After release, the commit is simply missed by automation tools — not catastrophic.
- Squash workflows: lead maintainer can rewrite messages at merge time; contributors don't need to follow the spec perfectly on every WIP commit.
Choosing the right type
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
SemVer cheatsheet
fix→PATCH, feat→MINOR, BREAKING CHANGE→MAJOR
More from jgamaraalv/ts-dev-kit
bullmq
BullMQ queue system reference for Redis-backed job queues, workers, flows, and schedulers. Use when: (1) creating queues and workers with BullMQ, (2) adding jobs (delayed, prioritized, repeatable, deduplicated), (3) setting up FlowProducer parent-child job hierarchies, (4) configuring retry strategies, rate limiting, or concurrency, (5) implementing job schedulers with cron/interval patterns, (6) preparing BullMQ for production (graceful shutdown, Redis config, monitoring), or (7) debugging stalled jobs or connection issues
46owasp-security-review
Review code and architectures against the OWASP Top 10:2025 — the ten most critical web application security risks. Use when: (1) reviewing code for security vulnerabilities, (2) auditing a feature or codebase against OWASP categories, (3) providing remediation guidance for identified vulnerabilities, (4) writing new code and needing secure coding patterns. Triggers: 'review for security', 'OWASP audit', 'check for vulnerabilities','security checklist', 'is this code secure', 'security review', 'fix vulnerability'.
42ioredis
ioredis v5 reference for Node.js Redis client — connection setup, RedisOptions, pipelines, transactions, Pub/Sub, Lua scripting, Cluster, and Sentinel. Use when: (1) creating or configuring Redis connections (standalone, cluster, sentinel), (2) writing Redis commands with ioredis (get/set, pipelines, multi/exec), (3) setting up Pub/Sub or Streams, (4) configuring retryStrategy, TLS, or auto-pipelining, (5) working with Redis Cluster options (scaleReads, NAT mapping), or (6) debugging ioredis connection issues. Important: use named import `import { Redis } from 'ioredis'` for correct TypeScript types with NodeNext.
35nextjs-best-practices
Next.js App Router best practices — file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling. Use when writing, reviewing, or debugging Next.js App Router code.
29ui-ux-guidelines
Review UI code for Web Interface Guidelines compliance. Use when asked to review UI, check accessibility, audit design, review UX, or check against best practices.
26service-worker
Service Worker API implementation guide — registration, lifecycle management, caching strategies, push notifications, and background sync. Use when: (1) creating or modifying service worker files (sw.js), (2) implementing offline-first caching (cache-first, network-first, stale-while-revalidate), (3) setting up push notifications or background sync, (4) debugging service worker registration, scope, or update issues, (5) implementing navigation preload, (6) user mentions 'service worker', 'sw.js', 'offline support', 'cache strategy', 'push notification', 'background sync', 'workbox alternative', or 'PWA caching'.
25