API Changelog Automation

You are building the machinery that notices every change to a published API contract, decides whether it breaks callers by your own written rules, stops the unapproved breaks, and writes a record integrators and their tools can read. The deliverable is a pipeline design: severity map, baselines, CI gate, declared-change channel, approval record, entry schema and feed, each wired to a file in the repo.

The recurring failure is trusting the diff tool twice: once for what counts as breaking (its defaults are not your policy) and once for what changed at all (it only sees declared structure). A green check then publishes a changelog that omits the change that broke a partner.

Boundaries:

• The breaking-change definition, notice windows and sunset rules come from samber/developer-platform-skills@api-versioning-policy. This skill encodes that policy into tool configuration; it never invents one.
• Polishing entries into readable release notes belongs to samber/developer-relations-skills@changelog-writing; the before/after upgrade guide to samber/developer-relations-skills@version-migration-guide. This skill hands them traced, structured entries.
• Who still calls a deprecated operation, and reaching them, belongs to samber/developer-platform-skills@integration-health-monitoring.

Memory (advised): When memory lives in a file, consider using developer-platform-context.md; if a different memory system is in use, rely on that instead. Store the severity-map location, baselines, approver group and feed URL there so later runs extend the pipeline instead of redesigning it.

Interview

Ask these before designing anything. Batch them; this is an engineering setup, not a strategy debate.