utility-pm-changelog-curator
This Claude Code skill generates draft CHANGELOG entries from git history while enforcing repository hygiene rules such as public paths only and no attribution trailers. Use it when preparing releases or banking unreleased changes, as it produces a layered draft with status summary for maintainer review and refuses to process dirty working trees unless explicitly overridden.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/utility-pm-changelog-curator && cp -r /tmp/utility-pm-changelog-curator/skills/utility-pm-changelog-curator ~/.claude/skills/utility-pm-changelog-curatorSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # PM Changelog Curator (Dispatch Skill) Cross-client dispatch wrapper for the `pm-changelog-curator` sub-agent. Detects runtime; dispatches to the native sub-agent on Claude Code; reads `agents/pm-changelog-curator.md` and executes inline on non-Claude clients. ## When to Use - You are preparing a release and want a CHANGELOG draft from git log between two tags - You are running on a non-Claude AI client without native pm-changelog-curator sub-agent support - You want a draft that respects pm-skills CHANGELOG hygiene rules (no internal-notes references, no em-dashes, public paths only) without manually applying them ## When NOT to Use - You want to commit CHANGELOG entries directly (this skill produces a draft for review, not a commit) - You want to review a PM artifact -> use `utility-pm-critic` instead - You want a repo-wide governance audit -> use `utility-pm-skill-auditor` - You want a full guided release flow -> use `utility-pm-release-conductor` (which chains to this skill at gate G2) ## Instructions **Runtime detection step.** Determine which AI client is invoking this skill. ### If you are running in Claude Code with the pm-skills plugin installed Invoke `@agent-pm-skills:pm-changelog-curator` with the user's arguments. Pass `--since-tag`, `--target-version`, `--committed-only` from `$ARGUMENTS` if present. Return the sub-agent's draft to the user. ### If you are running in any other AI client Codex CLI, Cursor, Windsurf, Copilot, Gemini CLI, or any other client without native pm-skills plugin sub-agent support: 1. Read the canonical sub-agent definition at `agents/pm-changelog-curator.md` 2. Execute the system prompt body in that file as your operating instructions 3. Run the 8-step drafting flow documented in the sub-agent definition (establish range -> read hygiene rules -> check working tree -> enumerate commits -> classify -> group -> rewrite -> determine target version -> emit draft) 4. Apply `--since-tag`, `--target-version`, and `--committed-only` arguments from `$ARGUMENTS` 5. Return the layered output per master plan D26 (full CHANGELOG draft + Status Summary + Status YAML) ## Cross-Client Notes The dispatch skill requires the AI client to: 1. Execute Bash for `git log`, `git describe`, and `git status` invocations 2. Read CLAUDE.md hygiene rules and existing CHANGELOG.md format reference 3. Read the canonical sub-agent definition file 4. Treat the agent body as operating instructions See [Sub-Agent Compatibility Matrix](../../docs/reference/sub-agent-compatibility.md) for the canonical cross-client status. Summary for this skill as of v2.16.0: PRODUCTION on Claude Code + Codex CLI (Codex CLI successfully ran git log + read CLAUDE.md hygiene rules + drafted clean CHANGELOG entries + correct dirty-tree refusal); EXPERIMENTAL on Cursor / Windsurf / Copilot CLI / Gemini CLI. If a client is unreliable, fall back to manual `git log` + manual drafting using CLAUDE.md as the hygiene reference. ## Reference Files - Canonical sub-agent definition: [`agents/pm-changelog-curator.md`](../../agents/pm-changelog-curator.md) - Behavioral spec: [`docs/internal/release-plans/v2.16.0/spec_pm-changelog-curator.md`](../../docs/internal/release-plans/v2.16.0/spec_pm-changelog-curator.md) - CHANGELOG hygiene rules source: `CLAUDE.md` (repo root) - Existing CHANGELOG.md format: `CHANGELOG.md` (root); v2.15.1 + v2.15.2 entries are canonical exemplars - Runtime components catalog: [`docs/reference/runtime-components.md`](../../docs/reference/runtime-components.md) - Output template: `references/TEMPLATE.md` - Worked example: `references/EXAMPLE.md`
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.