api-changeloglisted

Write a consumer-facing API changelog from OpenAPI or code diffs. Use when shipping API changes, drafting release notes for partners/SDKs, summarizing breaks vs additive changes, or when the user says "/api-changelog", "API changelog", "release notes for the API", or in Chinese "接口变更日志", "API 发布说明", "给调用方写 changelog", "版本更新说明". Prefer pairing with breaking-change-review deltas. Not a git commit message skill and not a marketing blog post.
Wanbinyu/api-platform-skills · ★ 1 · Code & Development · score 69

Install: claude install-skill Wanbinyu/api-platform-skills

# API Changelog > Callers should know what broke, what is new, and what to do next - in one page. ## Overview Turn structural API deltas into a **consumer-facing changelog**: clear sections for breaking / additive / deprecations, migration steps, and rollout timing. Write for SDK authors and integrators, not for internal eng ego. ## When to run - After `breaking-change-review` or `openapi_breaking_diff.py` - Before tagging an API release - When partners ask "what changed in vX?" ## Steps 1. **Collect inputs** - Before/after OpenAPI (or DTO diff) - Optional: tool output from `python scripts/openapi_breaking_diff.py old.yaml new.yaml` - API maturity: shipped | beta | unreleased | internal - Target audience: public partners | first-party only | internal services 2. **Bucket every delta** | Bucket | Examples | |--------|----------| | Breaking | Removed fields, type changes, required adds, auth changes, status renames | | Semantic | Same shape, new meaning (units, status meaning) | | Additive | New endpoints, optional fields, new enum values | | Deprecations | Still works; sunset date announced | | Security / authz | Auth added/removed, oversharing fixes (call out carefully) | | Internal-only | Not for public changelog (omit or label internal) | 3. **Write migration for each breaking/semantic item** - What clients must change - Temporary dual-support if any - Link to deprecation plan if sunsetting 4. **Draft changelog** using