메뉴
Generates a structured CHANGELOG.md from VCS history and PR/issue references, categorized by change type. Use when cutting a release, when the user asks to update CHANGELOG.md, or when backfilling a changelog from git history.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Generates code comments that explain non-obvious intent, constraints, and tradeoffs — not what the code already says. Use when code is correct but opaque, when documenting for future maintainers, or when a function's why is harder to see than its what.
Identifies recurring structural patterns in a codebase — idioms, copy-paste clones, homegrown abstractions — and characterizes each as a reusable template. Use when learning a codebase's conventions, when hunting for copy-paste that should be a function, or when documenting how this team does things.
Finds code by meaning, structure, or text across large codebases — picks the right search strategy (grep, AST query, call graph walk, semantic search) for the question being asked. Use when the user asks where something is implemented, when navigating unfamiliar code, or when a simple grep isn't enough.
Produces natural-language summaries of what code does at the function, class, module, or subsystem level, with length and abstraction scaled to the scope. Explains purpose, side effects, and non-obvious behavior rather than restating syntax. Use when onboarding to unfamiliar code, when the user asks what something does, when generating docstrings or architecture notes, or when preparing a handoff document.
Translates a single function or small code unit between programming languages, mapping idioms and preserving observable behavior. Use when porting one function, when the user pastes code and asks for it in another language, or as the per-unit primitive for larger migrations.
Identifies natural component boundaries inside a monolith by clustering the dependency graph, finding the cuts with minimum coupling. Use when planning to modularize or extract microservices, when deciding what can be deployed independently, or when the user asks where the seams in this codebase are.
| name | change-log-generator |
| description | Generates a structured CHANGELOG.md from VCS history and PR/issue references, categorized by change type. Use when cutting a release, when the user asks to update CHANGELOG.md, or when backfilling a changelog from git history. |
| license | Apache-2.0 |
| metadata | {"category":"devops","suite":"general-secure-coding-agent-skills","version":"0.3.0","related":"release-notes-writer"} |
A changelog is for developers who use your project. It answers one question: what do I need to know before I upgrade?
| This skill (CHANGELOG.md) | → release-notes-writer |
|---|---|
| Developers, maintainers | End users, stakeholders |
| Terse, categorized, complete | Narrative, highlights only |
| Every user-visible change | The 3 things anyone actually cares about |
| Lives in the repo | Goes in the release announcement |
git log <prev-tag>..HEAD --oneline --no-merges
If there's no previous tag, the range is "since the last ## [x.y.z] heading in CHANGELOG.md" — grep it out.
Bucket every commit. One bucket per commit — if a commit is both a feature and a fix, it should have been two commits, but pick the more user-impacting bucket.
| Bucket | Commit message signals | What qualifies |
|---|---|---|
| Breaking | BREAKING CHANGE:, ! after type, removed API | Anything that breaks existing user code — always first, always loud |
| Added | feat:, add, new, implement | New capabilities the user can now use |
| Changed | refactor: (if user-visible), behavior changes | Existing features that work differently now |
| Fixed | fix:, bug, patch, Fixes #N | Things that were broken and now aren't |
| Security | security:, CVE refs, vuln | Separate section — people grep for this |
| Removed | remove, drop, delete (of user-facing things) | Deprecation follow-throughs |
| (drop) | chore:, ci:, docs:, test:, style: | Internal. Changelog readers don't care. |
The commit message is input, not output. Transform:
| Commit says | Changelog says |
|---|---|
fix: handle null in getUserEmail | getUserEmail() no longer throws when user has no email |
feat: add retry param | Client() now accepts retries=N to retry failed calls |
remove v1 endpoints | Breaking: /api/v1/* endpoints removed; use /api/v2/* |
Rules for rewriting:
the billing module not BillingServiceImpl.(#123) at the end.Input commits:
a1b2c3d feat(client): add timeout parameter
b2c3d4e fix: race in connection pool cleanup (fixes #891)
c3d4e5f chore: bump pytest to 8.0
d4e5f6a feat!: drop Python 3.8 support
e5f6a7b docs: fix typo in README
Output:
## [2.4.0] — 2026-03-09
### Breaking
- Dropped Python 3.8 support; minimum is now 3.9 (#94)
### Added
- `Client()` now accepts a `timeout` parameter (seconds, default 30) (#92)
### Fixed
- Connection pool no longer leaks connections under concurrent close (#891)
Two commits dropped (chore:, docs:). Three kept, rewritten, linked.
docs/ is probably docs:. A commit that adds a test and changes one line is probably fix:. Classify by content.v1.0 and v1.1 is the ## [1.1.0] section.fix: thing is not an entry.## [Unreleased] section and call it done. Either pin a version or be explicit that it's unreleased.## [<version>] — <YYYY-MM-DD>
### Breaking
- <entry> (#<pr>)
### Added
- ...
### Changed
- ...
### Fixed
- ...
### Security
- ...
Omit empty sections. Breaking first, always.