changelog

Name: changelog
Author: tranhieutt

69stars41forks

How to install changelog?

tranhieutt/software_development_department/changelog

$npx -y skills add tranhieutt/software_development_department --skill changelog

Installs into the current project.

Summary

Generates a structured changelog from git history following Keep a Changelog format and conventional commits. Use when creating a CHANGELOG.md, preparing release notes, or when the user mentions changelog or release history.

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	1. Read the argument for the target version or sprint number. If a version
4	is given, use the corresponding git tag. If a sprint number is given, use
5	the sprint date range.
6
7	1b. Check git availability — Verify the repository is initialized:
8	- Run `git rev-parse --is-inside-work-tree` to confirm git is available
9	- If not a git repo, inform the user and abort gracefully
10
11	2. Read the git log since the last tag or release:
12	```
13	git log --oneline [last-tag]..HEAD
14	```
15	If no tags exist, read the full log or a reasonable recent range (last 100
16	commits).
17
18	3. Read sprint reports from `production/sprints/` for the relevant period
19	to understand planned work and context behind changes.
20
21	4. Read completed design documents from `design/docs/` for any new features
22	that were implemented during this period.
23
24	5. Categorize every change into one of these categories:
25	- New Features: Entirely new business systems, modes, or content
26	- Improvements: Enhancements to existing features, UX improvements,
27	performance gains
28	- Bug Fixes: Corrections to broken behavior
29	- Balance Changes: Tuning of business logic values, difficulty, economy
30	- Known Issues: Issues the team is aware of but have not yet resolved
31
32	6. Generate the INTERNAL changelog (full technical detail):
33
34	```markdown
35	# Internal Changelog: [Version]
36	Date: [Date]
37	Sprint(s): [Sprint numbers covered]
38	Commits: [Count] ([first-hash]..[last-hash])
39
40	## New Features
41	- [Feature Name] -- [Technical description, affected systems]
42	- Commits: [hash1], [hash2]
43	- Owner: [who implemented it]
44	- Design doc: [link if applicable]
45
46	## Improvements
47	- [Improvement] -- [What changed technically and why]
48	- Commits: [hashes]
49	- Owner: [who]
50
51	## Bug Fixes
52	- [BUG-ID] [Description of bug and root cause]
53	- Fix: [What was changed]
54	- Commits: [hashes]
55	- Owner: [who]
56
57	## Balance Changes
58	- [What was tuned] -- [Old value -> New value] -- [Design intent]
59	- Owner: [who]
60
61	## Technical Debt / Refactoring
62	- [What was cleaned up and why]
63	- Commits: [hashes]
64
65	## Known Issues
66	- [Issue description] -- [Severity] -- [ETA for fix if known]
67
68	## Metrics
69	- Total commits: [N]
70	- Files changed: [N]
71	- Lines added: [N]
72	- Lines removed: [N]
73	```
74
75	7. Generate the USER-FACING changelog (friendly, non-technical):
76
77	```markdown
78	# What is New in [Version]
79
80	## New Features
81	- [Feature Name]: [User-friendly description of what they can now do
82	and why it is exciting. Focus on the experience, not the implementation.]
83
84	## Improvements
85	- [What improved]: [How this makes the product better for the user.
86	Be specific but avoid jargon.]
87
88	## Bug Fixes
89	- Fixed an issue where [describe what the user experienced, not what was
90	wrong in the code]
91	- Fixed [user-visible symptom]
92
93	## Balance Changes
94	- [What changed in user-understandable terms and the design intent.
95	Example: "Healing potions now restore 50 HP (up from 30) -- we felt
96	users needed more recovery options in late-product encounters."]
97
98	## Known Issues
99	- We are aware of [issue description in user terms] and are working on a
100	fix. [Workaround if one exists.]
101
102	---
103	Thank you for playing! Your feedback helps us make the product better.
104	Report issues at [link].
105	```
106
107	8. Output both changelogs to the user. The internal changelog is the
108	primary working document. The user-facing changelog is ready for
109	community posting after review.
110
111	### Guidelines
112
113	- Never expose internal code references, file paths, or developer names in
114	the user-facing changelog
115	- Group related changes together rather than listing individual commits
116	- If a commit message is unclear, check the associated files and sprint data
117	for context
118	- Balance changes should always include the design reasoning, not just the
119	numbers
120	- Known issues should be honest -- users appreciate transparency
121	- If the git history is messy (merge commits, reverts, fixup commits), clean
122	up the narrative rather than listing every commit literally
123
124	## Protocol
125
126	- Question: Reads version or sprint number from argument; verifies git repo availability before starting
127	- Options: Skip — both internal and user-facing versions always generated
128	- Decision: Skip
129	- Draft: Both changelogs shown in conversation before saving
130	- Approval: "May I write to `production/releases/[version]/changelog.md`?

People who liked this also viewed

6 picks

Type

changelog

69stars41forks

View on GitHub

How to install changelog?

tranhieutt/software_development_department/changelog

$npx -y skills add tranhieutt/software_development_department --skill changelog

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	When this skill is invoked:
2
3	1. Read the argument for the target version or sprint number. If a version
4	is given, use the corresponding git tag. If a sprint number is given, use
5	the sprint date range.
6
7	1b. Check git availability — Verify the repository is initialized:
8	- Run `git rev-parse --is-inside-work-tree` to confirm git is available
9	- If not a git repo, inform the user and abort gracefully
10
11	2. Read the git log since the last tag or release:
12	```
13	git log --oneline [last-tag]..HEAD
14	```
15	If no tags exist, read the full log or a reasonable recent range (last 100
16	commits).
17
18	3. Read sprint reports from `production/sprints/` for the relevant period
19	to understand planned work and context behind changes.
20
21	4. Read completed design documents from `design/docs/` for any new features
22	that were implemented during this period.
23
24	5. Categorize every change into one of these categories:
25	- New Features: Entirely new business systems, modes, or content
26	- Improvements: Enhancements to existing features, UX improvements,
27	performance gains
28	- Bug Fixes: Corrections to broken behavior
29	- Balance Changes: Tuning of business logic values, difficulty, economy
30	- Known Issues: Issues the team is aware of but have not yet resolved
31
32	6. Generate the INTERNAL changelog (full technical detail):
33
34	```markdown
35	# Internal Changelog: [Version]
36	Date: [Date]
37	Sprint(s): [Sprint numbers covered]
38	Commits: [Count] ([first-hash]..[last-hash])
39
40	## New Features
41	- [Feature Name] -- [Technical description, affected systems]
42	- Commits: [hash1], [hash2]
43	- Owner: [who implemented it]
44	- Design doc: [link if applicable]
45
46	## Improvements
47	- [Improvement] -- [What changed technically and why]
48	- Commits: [hashes]
49	- Owner: [who]
50
51	## Bug Fixes
52	- [BUG-ID] [Description of bug and root cause]
53	- Fix: [What was changed]
54	- Commits: [hashes]
55	- Owner: [who]
56
57	## Balance Changes
58	- [What was tuned] -- [Old value -> New value] -- [Design intent]
59	- Owner: [who]
60
61	## Technical Debt / Refactoring
62	- [What was cleaned up and why]
63	- Commits: [hashes]
64
65	## Known Issues
66	- [Issue description] -- [Severity] -- [ETA for fix if known]
67
68	## Metrics
69	- Total commits: [N]
70	- Files changed: [N]
71	- Lines added: [N]
72	- Lines removed: [N]
73	```
74
75	7. Generate the USER-FACING changelog (friendly, non-technical):
76
77	```markdown
78	# What is New in [Version]
79
80	## New Features
81	- [Feature Name]: [User-friendly description of what they can now do
82	and why it is exciting. Focus on the experience, not the implementation.]
83
84	## Improvements
85	- [What improved]: [How this makes the product better for the user.
86	Be specific but avoid jargon.]
87
88	## Bug Fixes
89	- Fixed an issue where [describe what the user experienced, not what was
90	wrong in the code]
91	- Fixed [user-visible symptom]
92
93	## Balance Changes
94	- [What changed in user-understandable terms and the design intent.
95	Example: "Healing potions now restore 50 HP (up from 30) -- we felt
96	users needed more recovery options in late-product encounters."]
97
98	## Known Issues
99	- We are aware of [issue description in user terms] and are working on a
100	fix. [Workaround if one exists.]
101
102	---
103	Thank you for playing! Your feedback helps us make the product better.
104	Report issues at [link].
105	```
106
107	8. Output both changelogs to the user. The internal changelog is the
108	primary working document. The user-facing changelog is ready for
109	community posting after review.
110
111	### Guidelines
112
113	- Never expose internal code references, file paths, or developer names in
114	the user-facing changelog
115	- Group related changes together rather than listing individual commits
116	- If a commit message is unclear, check the associated files and sprint data
117	for context
118	- Balance changes should always include the design reasoning, not just the
119	numbers
120	- Known issues should be honest -- users appreciate transparency
121	- If the git history is messy (merge commits, reverts, fixup commits), clean
122	up the narrative rather than listing every commit literally
123
124	## Protocol
125
126	- Question: Reads version or sprint number from argument; verifies git repo availability before starting
127	- Options: Skip — both internal and user-facing versions always generated
128	- Decision: Skip
129	- Draft: Both changelogs shown in conversation before saving
130	- Approval: "May I write to `production/releases/[version]/changelog.md`?

People who liked this also viewed

6 picks

Type