changelog-generator
Transforms raw git commits, release notes, or commit summaries into a polished, user-facing changelog following Keep a Changelog conventions. Use this skill when preparing release notes, writing CHANGELOG.md entries, or documenting version changes for developers or end users. It categorises changes into Breaking Changes, Added, Changed, Fixed, Deprecated, Removed, and Security sections with clear language and migration guidance for breaking changes.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/changelog-generator && cp -r /tmp/changelog-generator/plugins/pm-engineering/skills/changelog-generator ~/.claude/skills/changelog-generatorSKILL.md
# 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) - **Previous version behaviour** (optional — paste the previous changelog entry or describe what is changing; needed for accurate "Changed" entries) - **Scope** (whole product / specific package or module — e.g. "payments SDK only", "iOS app", "all services") ## Output Format Follow [Keep a Changelog](https://keepachangelog.com) 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] --- --- > **Skill guidance — do not include the following section in the delivered changelog:** ## 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 - [ ] No entries start with past-tense verbs (no "Added", "Fixed", "Removed" — use "Add", "Fix", "Remove") - [ ] Every breaking change entry includes a specific migration action (not just "update your code") ## Anti-Patterns - [ ] Do not include implementation details in changelog entries — users need to know what changed for them, not how the code was refactored internally - [ ] Do not list every micro-commit as a separate entry — related commits should be grouped into one user-facing change - [ ] Do not omit the migration path for breaking changes — a breaking change entry without a specific migration action forces users to read the source code - [ ] Do not include empty sections — a "### Fixed" section with no entries signals the template was filled in carelessly - [ ] Do not write breaking changes in the same casual tone as minor additions — breaking changes must be visually prominent and call out migration requirements explicitly ## 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]
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.