Files

T

mohitagw15856 929fa3ad7f Restore trigger phrases as ## Usage Examples across 10 engineering skills

Renamed ## Example Trigger Phrases → ## Usage Examples to make the section
clearly human-facing documentation rather than a system instruction.
Restores content that was removed in the previous quality pass.

Skills updated (both skills/ and plugins/pm-engineering/skills/):
code-review-checklist, debugging-log-analyser, changelog-generator,
pr-description-writer, system-design-interview, test-strategy-doc,
runbook-writer, incident-postmortem, api-docs-writer,
architecture-decision-record

https://claude.ai/code/session_01C3HwChrccJd145vJ6Z7ajF

2026-05-20 12:06:26 +00:00

3.1 KiB

Raw Blame History

name, description

name	description
changelog-generator	Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes.

Changelog Generator Skill

Converts raw git commits, a diff summary, or developer release notes into a polished changelog entry — categorised, user-facing, and following Keep a Changelog conventions.

Required Inputs

Ask for these if not provided:

Commits or release notes (paste git log --oneline, raw commit messages, or a description of what changed)
Version number (e.g. 2.4.0, v1.0.0-beta.2)
Release date (or "today")
Audience (developers using an API / end users of a product / internal team — affects language)
Any breaking changes (flag these explicitly if known)

Output Format

Follow Keep a Changelog format:

[X.Y.Z] — YYYY-MM-DD

Breaking Changes ⚠️

[Only include if there are breaking changes]

[Breaking change]: [What changed and what it breaks]
Migration required: [Specific action the user must take]

Added

[New feature or capability, written from the user's perspective]
[Another addition]

Changed

[Changed behaviour — what it did before vs. what it does now]
[Performance improvement with measurable impact if known]

Fixed

[Bug fixed — describe what was broken, not the fix implementation]
[Another fix]

Deprecated

[Deprecated thing] — use [replacement] instead. Will be removed in [version].

Removed

[Removed thing] — was deprecated in [version]

Security

[Security fix — describe the vulnerability class, not exploit details]

Formatting Rules Applied

Language: Write for the reader, not the committer. "Add dark mode support" not "implement ThemeProvider with dark palette variant".

Breaking changes: Always call these out first with ⚠️. Include a migration path.

Bug fixes: Describe what was broken, not what was changed. "Fix crash when user has no profile picture" not "null-check avatar URL before rendering".

Granularity: Group related commits into one line. Don't list every micro-commit separately.

Tone: Active voice, imperative mood. "Add", "Fix", "Remove" — not "Added", "Fixed", "Removed".

Empty sections: Omit any section with no entries. Don't include empty ### Fixed blocks.

Quality Checks

Breaking changes are at the top with migration instructions
All entries are user-facing language (no internal variable names or implementation details)
Related commits are grouped into single entries (not listed individually)
Version and date header is correct
Empty sections are omitted
Tone is imperative mood throughout

Usage Examples

"Write a changelog for version [X]" + [paste commits]
"Generate release notes from these commits"
"Turn this git log into a CHANGELOG entry"
"Write the CHANGELOG.md update for this release"
"What changed in this release?" + [paste commit list]

3.1 KiB Raw Blame History