What this prompt does
This prompt writes a detailed API changelog entry for version [api_version] of the [api_name] API, where the release includes [change_summary]. It targets [audience] and follows [changelog_format], producing the kind of entry that prevents support tickets by spelling out breaking changes and migration paths.
The structure works because it organizes changes the way consumers consume them. A release header classifies the version as major, minor, or patch under semantic versioning. Changes are grouped under standard headings — Breaking Changes, Deprecated, Added, Changed, Fixed, Security — so a reader scans straight to what affects them. Each breaking change gets a before/after example, a migration guide, and a [deprecation_window] deadline. New endpoints document method, path, auth, schemas, rate limits, and [special_headers]. Deprecations state the replacement and sunset timeline, an Impact Assessment estimates how many of [consumer_count] consumers are affected, and a Testing section gives curl examples against [staging_url].
When to use it
- You are shipping a release with breaking changes that consumers must migrate for.
- You want before/after examples and migration paths to cut support load.
- You need new endpoints documented with schemas, auth, and
[special_headers]. - You are deprecating features and need explicit sunset timelines.
- Your changelog must follow a standard like
[changelog_format]. - You want consumers to verify their integration against
[staging_url]before upgrading.
Example output
Expect a structured changelog entry organized the way consumers read it. It opens with a release header for [api_version], the release date, a one-line summary of the most impactful change, and a semantic-versioning classification as major, minor, or patch. Changes are then grouped under standard headings: Breaking Changes with before/after examples and migration steps, Deprecated with replacements and sunset dates, then Added, Changed, Fixed, and Security. Each new endpoint is documented with its HTTP method, path, authentication requirement, request and response schemas with examples, rate limits, and any [special_headers]. An Impact Assessment estimates the share of [consumer_count] consumers affected by breaking changes, and a Testing section provides curl examples consumers can run against [staging_url] to confirm their integration still works.
Pro tips
- Make
[change_summary]accurate, since it drives the version classification and which sections get populated. - Write every breaking change with a concrete before/after; a migration path without code is the top driver of support tickets.
- State the
[deprecation_window]deadline explicitly so consumers cannot claim they were not warned. - Document
[special_headers]precisely — a missing required header is a silent integration failure for consumers. - Treat the Impact Assessment percentage as an estimate unless you back it with real usage analytics, and label it as such.
- Keep the
[staging_url]curl examples runnable so consumers can verify before upgrading production traffic.
