conventional-commits

Name: conventional-commits
Author: jgamaraalv

24installs0forks

How to install conventional-commits?

jgamaraalv/ts-dev-kit/conventional-commits

$npx -y skills add jgamaraalv/ts-dev-kit --skill conventional-commits

Installs into the current project.

Summary

Write, review, and validate commit messages following the Conventional Commits v1.0.0 specification. Use when: (1) crafting a git commit message for any change, (2) reviewing or correcting an existing commit message, (3) choosing the right commit type for a change, (4) deciding h

Files · 1

View on GitHub

SKILL.md

1	<live_context>
2	Staged changes (summary):
3	!`git diff --cached --stat 2>/dev/null \|\| echo "(nothing staged)"`
4
5	Staged diff:
6	!`git diff --cached 2>/dev/null \| head -300 \|\| echo "(nothing staged)"`
7
8	Recent commits (style reference):
9	!`git log --oneline -8 2>/dev/null \|\| echo "(no commits yet)"`
10	</live_context>
11
12	## Table of Contents
13
14	- [Format](#format)
15	- [Types and SemVer impact](#types-and-semver-impact)
16	- [Breaking changes](#breaking-changes)
17	- [Examples](#examples)
18	- [Non-obvious rules](#non-obvious-rules)
19	- [Choosing the right type](#choosing-the-right-type)
20	- [SemVer cheatsheet](#semver-cheatsheet)
21
22	## Format
23
24	```
25	<type>[optional scope]: <description>
26
27	[optional body]
28
29	[optional footer(s)]
30	```
31
32	- type: lowercase noun (see table below)
33	- scope: optional noun in parentheses describing the affected section, e.g. `feat(auth):`
34	- description: imperative, present tense, no period at end, immediately after `": "`
35	- body: free-form; begins one blank line after description
36	- footers: one blank line after body; follow git trailer format (`Token: value` or `Token #value`)
37
38	## Types and SemVer impact
39
40	\| Type \| Use for \| SemVer \|
41	\| ---------- \| -------------------------------------------- \| ------ \|
42	\| `feat` \| New feature \| MINOR \|
43	\| `fix` \| Bug fix \| PATCH \|
44	\| `docs` \| Documentation only \| none \|
45	\| `style` \| Formatting, whitespace (no logic change) \| none \|
46	\| `refactor` \| Code restructure (not a fix or feature) \| none \|
47	\| `perf` \| Performance improvement \| none \|
48	\| `test` \| Adding or fixing tests \| none \|
49	\| `build` \| Build system, dependencies (npm, gradle…) \| none \|
50	\| `ci` \| CI configuration (GitHub Actions, CircleCI…) \| none \|
51	\| `chore` \| Maintenance not fitting above types \| none \|
52	\| `revert` \| Reverts a previous commit \| none \|
53
54	Any type + `BREAKING CHANGE` → MAJOR.
55
56	## Breaking changes
57
58	Two ways to signal a breaking change (can combine both):
59
60	1. `!` after type/scope (visible at a glance):
61
62	```
63	feat(api)!: remove deprecated v1 endpoints
64	```
65
66	2. `BREAKING CHANGE:` footer (required if you need a description):
67
68	```
69	feat: allow config object to extend other configs
70
71	BREAKING CHANGE: `extends` key now used for extending config files
72	```
73
74	Both together:
75
76	```
77	chore!: drop support for Node 6
78
79	BREAKING CHANGE: use JavaScript features not available in Node 6.
80	```
81
82	## Examples
83
84	Simple fix:
85
86	```
87	fix: prevent racing of requests
88	```
89
90	Feature with scope:
91
92	```
93	feat(lang): add Polish language
94	```
95
96	Fix with body and footers:
97
98	```
99	fix: prevent racing of requests
100
101	Introduce a request id and a reference to latest request. Dismiss
102	incoming responses other than from latest request.
103
104	Remove timeouts which were used to mitigate the racing issue but are
105	obsolete now.
106
107	Reviewed-by: Z
108	Refs: #123
109	```
110
111	Revert with footer references:
112
113	```
114	revert: let us never again speak of the noodle incident
115
116	Refs: 676104e, a215868
117	```
118
119	Docs with no body:
120
121	```
122	docs: correct spelling of CHANGELOG
123	```
124
125	## Non-obvious rules
126
127	- NEVER add `Co-Authored-By` trailers to commit messages. This project does not use authorship footers.
128	- Types are case-insensitive in parsing, but `BREAKING CHANGE` footer token must be uppercase.
129	- `BREAKING-CHANGE` (hyphen) is a valid synonym for `BREAKING CHANGE` in footers.
130	- Footer tokens use `-` instead of spaces (e.g. `Reviewed-by`), except `BREAKING CHANGE`.
131	- Footer separator is either `": "` (colon-space) or `" #"` (space-hash for issue refs): `Refs #123`.
132	- A footer value may span multiple lines; parsing stops at the next valid `Token: ` or `Token #` pair.
133	- When a commit fits multiple types, split into multiple commits instead of picking one.
134	- 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.
135	- Squash workflows: lead maintainer can rewrite messages at merge time; contributors don't need to follow the spec perfectly on every WIP commit.
136
137	## Choosing the right type
138
139	```
140	Is it a new user-facing capability?

People who liked this also viewed

6 picks

Type

conventional-commits

24installs0forks

View on GitHub

How to install conventional-commits?

jgamaraalv/ts-dev-kit/conventional-commits

$npx -y skills add jgamaraalv/ts-dev-kit --skill conventional-commits

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<live_context>
2	Staged changes (summary):
3	!`git diff --cached --stat 2>/dev/null \|\| echo "(nothing staged)"`
4
5	Staged diff:
6	!`git diff --cached 2>/dev/null \| head -300 \|\| echo "(nothing staged)"`
7
8	Recent commits (style reference):
9	!`git log --oneline -8 2>/dev/null \|\| echo "(no commits yet)"`
10	</live_context>
11
12	## Table of Contents
13
14	- [Format](#format)
15	- [Types and SemVer impact](#types-and-semver-impact)
16	- [Breaking changes](#breaking-changes)
17	- [Examples](#examples)
18	- [Non-obvious rules](#non-obvious-rules)
19	- [Choosing the right type](#choosing-the-right-type)
20	- [SemVer cheatsheet](#semver-cheatsheet)
21
22	## Format
23
24	```
25	<type>[optional scope]: <description>
26
27	[optional body]
28
29	[optional footer(s)]
30	```
31
32	- type: lowercase noun (see table below)
33	- scope: optional noun in parentheses describing the affected section, e.g. `feat(auth):`
34	- description: imperative, present tense, no period at end, immediately after `": "`
35	- body: free-form; begins one blank line after description
36	- footers: one blank line after body; follow git trailer format (`Token: value` or `Token #value`)
37
38	## Types and SemVer impact
39
40	\| Type \| Use for \| SemVer \|
41	\| ---------- \| -------------------------------------------- \| ------ \|
42	\| `feat` \| New feature \| MINOR \|
43	\| `fix` \| Bug fix \| PATCH \|
44	\| `docs` \| Documentation only \| none \|
45	\| `style` \| Formatting, whitespace (no logic change) \| none \|
46	\| `refactor` \| Code restructure (not a fix or feature) \| none \|
47	\| `perf` \| Performance improvement \| none \|
48	\| `test` \| Adding or fixing tests \| none \|
49	\| `build` \| Build system, dependencies (npm, gradle…) \| none \|
50	\| `ci` \| CI configuration (GitHub Actions, CircleCI…) \| none \|
51	\| `chore` \| Maintenance not fitting above types \| none \|
52	\| `revert` \| Reverts a previous commit \| none \|
53
54	Any type + `BREAKING CHANGE` → MAJOR.
55
56	## Breaking changes
57
58	Two ways to signal a breaking change (can combine both):
59
60	1. `!` after type/scope (visible at a glance):
61
62	```
63	feat(api)!: remove deprecated v1 endpoints
64	```
65
66	2. `BREAKING CHANGE:` footer (required if you need a description):
67
68	```
69	feat: allow config object to extend other configs
70
71	BREAKING CHANGE: `extends` key now used for extending config files
72	```
73
74	Both together:
75
76	```
77	chore!: drop support for Node 6
78
79	BREAKING CHANGE: use JavaScript features not available in Node 6.
80	```
81
82	## Examples
83
84	Simple fix:
85
86	```
87	fix: prevent racing of requests
88	```
89
90	Feature with scope:
91
92	```
93	feat(lang): add Polish language
94	```
95
96	Fix with body and footers:
97
98	```
99	fix: prevent racing of requests
100
101	Introduce a request id and a reference to latest request. Dismiss
102	incoming responses other than from latest request.
103
104	Remove timeouts which were used to mitigate the racing issue but are
105	obsolete now.
106
107	Reviewed-by: Z
108	Refs: #123
109	```
110
111	Revert with footer references:
112
113	```
114	revert: let us never again speak of the noodle incident
115
116	Refs: 676104e, a215868
117	```
118
119	Docs with no body:
120
121	```
122	docs: correct spelling of CHANGELOG
123	```
124
125	## Non-obvious rules
126
127	- NEVER add `Co-Authored-By` trailers to commit messages. This project does not use authorship footers.
128	- Types are case-insensitive in parsing, but `BREAKING CHANGE` footer token must be uppercase.
129	- `BREAKING-CHANGE` (hyphen) is a valid synonym for `BREAKING CHANGE` in footers.
130	- Footer tokens use `-` instead of spaces (e.g. `Reviewed-by`), except `BREAKING CHANGE`.
131	- Footer separator is either `": "` (colon-space) or `" #"` (space-hash for issue refs): `Refs #123`.
132	- A footer value may span multiple lines; parsing stops at the next valid `Token: ` or `Token #` pair.
133	- When a commit fits multiple types, split into multiple commits instead of picking one.
134	- 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.
135	- Squash workflows: lead maintainer can rewrite messages at merge time; contributors don't need to follow the spec perfectly on every WIP commit.
136
137	## Choosing the right type
138
139	```
140	Is it a new user-facing capability?

People who liked this also viewed

6 picks

Type