changelog-generator

Name: changelog-generator
Author: ECNU-ICALK

524stars49forks

How to install changelog-generator?

ecnu-icalk/autoskill/changelog-generator

$npx -y skills add ECNU-ICALK/AutoSkill --skill changelog-generator

Installs into the current project.

Summary

Generates user-facing changelogs and release notes from git commit history. Parses conventional commits, categorizes changes into features, fixes, breaking changes, and more, then rewrites technical messages into customer-friendly language. Use when the user asks to generate a ch

Files · 1

View on GitHub

SKILL.md

1	# Changelog Generator
2
3	Generate structured, user-facing changelogs from git commit history.
4
5	## Workflow
6
7	### Step 1 — Gather commits
8
9	Determine the commit range from the user's request, then fetch commits:
10
11	```bash
12	# Between tags/versions
13	git log v1.2.0..v1.3.0 --oneline --no-merges
14	# Since a date
15	git log --since="2024-03-01" --oneline --no-merges
16	# Since last tag (default when no range given)
17	git log "$(git describe --tags --abbrev=0)"..HEAD --oneline --no-merges
18	```
19
20	If there are no tags and no range specified, ask the user for a date or count.
21
22	### Step 2 — Categorize each commit
23
24	Apply these rules based on the commit message prefix:
25
26	\| Prefix / pattern \| Category \|
27	\|---\|---\|
28	\| `feat:` `feature:` \| New Features \|
29	\| `fix:` `bugfix:` \| Bug Fixes \|
30	\| `perf:` \| Performance \|
31	\| `BREAKING CHANGE` or `!:` suffix \| Breaking Changes \|
32	\| `security:` `vuln:` \| Security \|
33	\| `docs:` `test:` `ci:` `chore:` `refactor:` `style:` `build:` \| Skip (internal) \|
34
35	For non-conventional messages, infer category from content. Exclude purely internal commits (test infra, CI config, linting, dependency bumps with no user impact).
36
37	### Step 3 — Rewrite for a non-technical audience
38
39	Transform each kept commit into a clear, benefit-focused sentence:
40
41	- Strip scope tags like `(api):` or `(auth):`
42	- Expand abbreviations and jargon
43	- Lead with the user-visible outcome, not the implementation
44	- Use present tense: "Add", "Fix", "Improve"
45	- One sentence per entry
46
47	Example: `fix(auth): race condition in token refresh` becomes
48	"Fix an issue where sessions could expire unexpectedly during use."
49
50	### Step 4 — Format the output
51
52	```markdown
53	# Changelog — vX.Y.Z (YYYY-MM-DD)
54
55	## Breaking Changes
56	- [entry]
57
58	## New Features
59	- [entry]
60
61	## Improvements
62	- [entry]
63
64	## Bug Fixes
65	- [entry]
66
67	## Security
68	- [entry]
69	```
70
71	Omit any empty section. Order: breaking changes, features, improvements, fixes, security. If the repo already has a `CHANGELOG.md` or `CHANGELOG_STYLE.md`, match its existing conventions instead.
72
73	### Step 5 — Validate before presenting
74
75	1. Confirm no internal-only commits leaked through
76	2. Confirm every entry is understandable without reading source code
77	3. Confirm date and version label are correct
78	4. Write to `CHANGELOG.md` (prepend above existing content) or print inline, based on the user's request

People who liked this also viewed

6 picks

Type

changelog-generator

524stars49forks

View on GitHub

How to install changelog-generator?

ecnu-icalk/autoskill/changelog-generator

$npx -y skills add ECNU-ICALK/AutoSkill --skill changelog-generator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Changelog Generator
2
3	Generate structured, user-facing changelogs from git commit history.
4
5	## Workflow
6
7	### Step 1 — Gather commits
8
9	Determine the commit range from the user's request, then fetch commits:
10
11	```bash
12	# Between tags/versions
13	git log v1.2.0..v1.3.0 --oneline --no-merges
14	# Since a date
15	git log --since="2024-03-01" --oneline --no-merges
16	# Since last tag (default when no range given)
17	git log "$(git describe --tags --abbrev=0)"..HEAD --oneline --no-merges
18	```
19
20	If there are no tags and no range specified, ask the user for a date or count.
21
22	### Step 2 — Categorize each commit
23
24	Apply these rules based on the commit message prefix:
25
26	\| Prefix / pattern \| Category \|
27	\|---\|---\|
28	\| `feat:` `feature:` \| New Features \|
29	\| `fix:` `bugfix:` \| Bug Fixes \|
30	\| `perf:` \| Performance \|
31	\| `BREAKING CHANGE` or `!:` suffix \| Breaking Changes \|
32	\| `security:` `vuln:` \| Security \|
33	\| `docs:` `test:` `ci:` `chore:` `refactor:` `style:` `build:` \| Skip (internal) \|
34
35	For non-conventional messages, infer category from content. Exclude purely internal commits (test infra, CI config, linting, dependency bumps with no user impact).
36
37	### Step 3 — Rewrite for a non-technical audience
38
39	Transform each kept commit into a clear, benefit-focused sentence:
40
41	- Strip scope tags like `(api):` or `(auth):`
42	- Expand abbreviations and jargon
43	- Lead with the user-visible outcome, not the implementation
44	- Use present tense: "Add", "Fix", "Improve"
45	- One sentence per entry
46
47	Example: `fix(auth): race condition in token refresh` becomes
48	"Fix an issue where sessions could expire unexpectedly during use."
49
50	### Step 4 — Format the output
51
52	```markdown
53	# Changelog — vX.Y.Z (YYYY-MM-DD)
54
55	## Breaking Changes
56	- [entry]
57
58	## New Features
59	- [entry]
60
61	## Improvements
62	- [entry]
63
64	## Bug Fixes
65	- [entry]
66
67	## Security
68	- [entry]
69	```
70
71	Omit any empty section. Order: breaking changes, features, improvements, fixes, security. If the repo already has a `CHANGELOG.md` or `CHANGELOG_STYLE.md`, match its existing conventions instead.
72
73	### Step 5 — Validate before presenting
74
75	1. Confirm no internal-only commits leaked through
76	2. Confirm every entry is understandable without reading source code
77	3. Confirm date and version label are correct
78	4. Write to `CHANGELOG.md` (prepend above existing content) or print inline, based on the user's request

People who liked this also viewed

6 picks

Type