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]
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.