commit-message-generator

Name: commit-message-generator
Author: girijashankarj

27stars3forks

How to install commit-message-generator?

girijashankarj/cursor-handbook/commit-message-generator

$npx -y skills add girijashankarj/cursor-handbook --skill commit-message-generator

Installs into the current project.

Summary

Generate structured Conventional Commit messages from staged changes, diffs, or descriptions. Use when the user asks to write a commit message or needs help with commit formatting.

Files · 1

View on GitHub

SKILL.md

1	# Skill: Commit Message Generator
2
3	Analyze code changes and produce well-structured Conventional Commit messages following project conventions.
4
5	## Trigger
6	When the user asks to generate, write, or improve a commit message — or before committing staged changes.
7
8	## Prerequisites
9	- [ ] Git repository initialized
10	- [ ] Changes staged (`git add`) or described by the user
11
12	## Steps
13
14	### Step 1: Gather Change Context
15	- [ ] Run `git diff --cached --stat` to see staged file summary
16	- [ ] Run `git diff --cached` for detailed diff (limit to first 200 lines if large)
17	- [ ] Check branch name for scope hints: `git branch --show-current`
18	- [ ] If no staged changes, ask the user to describe what changed
19
20	### Step 2: Classify the Change Type
21	Map changes to Conventional Commit types:
22
23	\| Type \| When \|
24	\|------\|------\|
25	\| `feat` \| New feature or capability \|
26	\| `fix` \| Bug fix \|
27	\| `docs` \| Documentation only \|
28	\| `style` \| Formatting, whitespace, semicolons (no logic change) \|
29	\| `refactor` \| Code restructuring without behavior change \|
30	\| `test` \| Adding or updating tests \|
31	\| `chore` \| Build, tooling, dependency updates \|
32	\| `perf` \| Performance improvement \|
33	\| `ci` \| CI/CD pipeline changes \|
34
35	### Step 3: Determine Scope
36	- [ ] Identify the primary module/package affected
37	- [ ] Use project-standard scopes: `rules`, `agents`, `skills`, `commands`, `hooks`, `docs`, `config`
38	- [ ] For cross-cutting changes, use the most significant scope or omit
39
40	### Step 4: Write Subject Line
41	- [ ] Format: `type(scope): imperative description`
42	- [ ] Keep under 72 characters
43	- [ ] Use imperative mood ("add", "fix", "update" — not "added", "fixes")
44	- [ ] Lowercase, no trailing period
45	- [ ] Focus on what changed, not how
46
47	### Step 5: Write Body (if needed)
48	Include a body when:
49	- The why isn't obvious from the subject
50	- Multiple files or concerns are involved
51	- There are breaking changes
52
53	Body rules:
54	- [ ] Blank line between subject and body
55	- [ ] Wrap at 72 characters
56	- [ ] Use bullet points for multiple items
57	- [ ] Explain motivation and contrast with previous behavior
58
59	### Step 6: Add Footer (if needed)
60	- [ ] Breaking changes: `BREAKING CHANGE: description`
61	- [ ] Issue references: `Closes #123`, `Refs #456`
62	- [ ] Co-authors: `Co-authored-by: Name <email>`
63
64	### Step 7: Validate & Output
65	- [ ] Verify subject ≤ 72 chars
66	- [ ] Verify type is valid Conventional Commit type
67	- [ ] Verify no secrets, PII, or internal hostnames in message
68	- [ ] If changes span multiple concerns, suggest splitting into separate commits
69	- [ ] Present the final message in a copyable code block
70
71	## Rules
72	- ALWAYS use Conventional Commits format
73	- NEVER include secrets, API keys, or internal URLs in commit messages
74	- NEVER reference specific infrastructure names — use placeholders
75	- Prefer atomic commits: one logical change per commit
76	- If the diff is too large (>500 lines), suggest splitting
77
78	## Examples
79
80	### Simple feature
81	```
82	feat(skills): add commit-message-generator skill
83
84	Step-by-step workflow for generating Conventional Commit messages
85	from staged changes or user descriptions.
86	```
87
88	### Bug fix with issue reference
89	```
90	fix(auth): handle expired refresh tokens gracefully
91
92	Previously, expired refresh tokens caused a 500 error.
93	Now returns 401 with a clear message prompting re-authentication.
94
95	Closes #247
96	```
97
98	### Breaking change
99	```
100	feat(api)!: change pagination from offset to cursor-based
101
102	BREAKING CHANGE: All list endpoints now use cursor-based pagination.
103	Replace `page` and `limit` params with `cursor` and `pageSize`.
104
105	Migration guide: docs/migration/v2-pagination.md
106	```
107
108	## Completion
109	One or more commit messages ready to copy-paste. If changes span multiple concerns, provide separate messages for each suggested split.
110
111	## If a Step Fails
112	- No staged changes: Ask the user to describe the change, or run `git add` first
113	- Ambiguous type: Default to `chore` and ask the user for clarification
114	- Large diff: Summarize themes and suggest `feat` vs `fix` based on behavior change
115	- Multi-concern diff: Suggest `git add -p` to stage partial changes for atomic commits

People who liked this also viewed

6 picks

Type

commit-message-generator

27stars3forks

View on GitHub

How to install commit-message-generator?

girijashankarj/cursor-handbook/commit-message-generator

$npx -y skills add girijashankarj/cursor-handbook --skill commit-message-generator

Installs into the current project.

Summary

Generate structured Conventional Commit messages from staged changes, diffs, or descriptions. Use when the user asks to write a commit message or needs help with commit formatting.

Files · 1

View on GitHub

SKILL.md

1	# Skill: Commit Message Generator
2
3	Analyze code changes and produce well-structured Conventional Commit messages following project conventions.
4
5	## Trigger
6	When the user asks to generate, write, or improve a commit message — or before committing staged changes.
7
8	## Prerequisites
9	- [ ] Git repository initialized
10	- [ ] Changes staged (`git add`) or described by the user
11
12	## Steps
13
14	### Step 1: Gather Change Context
15	- [ ] Run `git diff --cached --stat` to see staged file summary
16	- [ ] Run `git diff --cached` for detailed diff (limit to first 200 lines if large)
17	- [ ] Check branch name for scope hints: `git branch --show-current`
18	- [ ] If no staged changes, ask the user to describe what changed
19
20	### Step 2: Classify the Change Type
21	Map changes to Conventional Commit types:
22
23	\| Type \| When \|
24	\|------\|------\|
25	\| `feat` \| New feature or capability \|
26	\| `fix` \| Bug fix \|
27	\| `docs` \| Documentation only \|
28	\| `style` \| Formatting, whitespace, semicolons (no logic change) \|
29	\| `refactor` \| Code restructuring without behavior change \|
30	\| `test` \| Adding or updating tests \|
31	\| `chore` \| Build, tooling, dependency updates \|
32	\| `perf` \| Performance improvement \|
33	\| `ci` \| CI/CD pipeline changes \|
34
35	### Step 3: Determine Scope
36	- [ ] Identify the primary module/package affected
37	- [ ] Use project-standard scopes: `rules`, `agents`, `skills`, `commands`, `hooks`, `docs`, `config`
38	- [ ] For cross-cutting changes, use the most significant scope or omit
39
40	### Step 4: Write Subject Line
41	- [ ] Format: `type(scope): imperative description`
42	- [ ] Keep under 72 characters
43	- [ ] Use imperative mood ("add", "fix", "update" — not "added", "fixes")
44	- [ ] Lowercase, no trailing period
45	- [ ] Focus on what changed, not how
46
47	### Step 5: Write Body (if needed)
48	Include a body when:
49	- The why isn't obvious from the subject
50	- Multiple files or concerns are involved
51	- There are breaking changes
52
53	Body rules:
54	- [ ] Blank line between subject and body
55	- [ ] Wrap at 72 characters
56	- [ ] Use bullet points for multiple items
57	- [ ] Explain motivation and contrast with previous behavior
58
59	### Step 6: Add Footer (if needed)
60	- [ ] Breaking changes: `BREAKING CHANGE: description`
61	- [ ] Issue references: `Closes #123`, `Refs #456`
62	- [ ] Co-authors: `Co-authored-by: Name <email>`
63
64	### Step 7: Validate & Output
65	- [ ] Verify subject ≤ 72 chars
66	- [ ] Verify type is valid Conventional Commit type
67	- [ ] Verify no secrets, PII, or internal hostnames in message
68	- [ ] If changes span multiple concerns, suggest splitting into separate commits
69	- [ ] Present the final message in a copyable code block
70
71	## Rules
72	- ALWAYS use Conventional Commits format
73	- NEVER include secrets, API keys, or internal URLs in commit messages
74	- NEVER reference specific infrastructure names — use placeholders
75	- Prefer atomic commits: one logical change per commit
76	- If the diff is too large (>500 lines), suggest splitting
77
78	## Examples
79
80	### Simple feature
81	```
82	feat(skills): add commit-message-generator skill
83
84	Step-by-step workflow for generating Conventional Commit messages
85	from staged changes or user descriptions.
86	```
87
88	### Bug fix with issue reference
89	```
90	fix(auth): handle expired refresh tokens gracefully
91
92	Previously, expired refresh tokens caused a 500 error.
93	Now returns 401 with a clear message prompting re-authentication.
94
95	Closes #247
96	```
97
98	### Breaking change
99	```
100	feat(api)!: change pagination from offset to cursor-based
101
102	BREAKING CHANGE: All list endpoints now use cursor-based pagination.
103	Replace `page` and `limit` params with `cursor` and `pageSize`.
104
105	Migration guide: docs/migration/v2-pagination.md
106	```
107
108	## Completion
109	One or more commit messages ready to copy-paste. If changes span multiple concerns, provide separate messages for each suggested split.
110
111	## If a Step Fails
112	- No staged changes: Ask the user to describe the change, or run `git add` first
113	- Ambiguous type: Default to `chore` and ask the user for clarification
114	- Large diff: Summarize themes and suggest `feat` vs `fix` based on behavior change
115	- Multi-concern diff: Suggest `git add -p` to stage partial changes for atomic commits

People who liked this also viewed

6 picks

Type