Changelog Generator

Changelog Generator Protocol

This skill bridges the gap between raw git history and consumer-facing API updates. Consumers don't care about "Refactored user service;" they care about "The /users endpoint now returns a profile_pic URL."

Core assumption: A changelog is a communication tool, not a git dump. It must focus on the API interface, not internal implementation tweaks.

1. Input Analysis (Static)

Parse the provided text (Git commits, PR bodies, or OpenAPI diffs) and filter out internal noise.

• Keep: Added fields, new endpoints, deprecated endpoints, bug fixes that changed API behavior.
• Discard: Dependency updates, CI/CD tweaks, internal refactoring (unless it drastically improved performance).

2. Categorization & Formatting

Organize the update into established categories:

• 🚀 Features: New capabilities for the consumer.
• 🛠️ Fixes: Resolved behavior issues.
• ⚠️ Deprecations: Warnings about endpoints/fields being sunset.
• 🚨 BREAKING CHANGES: Red-alert items requiring consumer code updates. (Cross-reference findings with breaking-change-detector).

3. Output Generation

Required Outputs (Must write BOTH to docs/api-report/):

1. Human-Readable Markdown (docs/api-report/api-changelog.md)

# 🌍 API Changelog

## [v1.4.0] - 2024-03-24

### 🚀 Features
- **[Orders]** Added new `POST /v1/orders/{id}/cancel` endpoint. You can now cancel orders within 30 minutes of creation.
- **[Users]** The `GET /v1/users/me` endpoint now includes a `last_login_at` timestamp.

### 🛠️ Fixes
- **[Payments]** Fixed an issue where `GET /v1/payments` would return a 500 error if the user had no payment methods. It now correctly returns an empty array `[]`.

### ⚠️ Deprecations
- **[Products]** The `category_id` field in the `/products` response is deprecated. Please use the new `categories` array instead. `category_id` will be removed in v2.0.0.

2. Machine-Readable JSON (docs/api-report/api-changelog-output.json)

{
  "skill": "changelog-generator",
  "version": "1.4.0",
  "date": "2024-03-24",
  "changes": {
    "features": ["POST /v1/orders/{id}/cancel added", "last_login_at added to GET /v1/users/me"],
    "fixes": ["GET /v1/payments empty state fix"],
    "deprecations": ["category_id in /products response"]
  },
  "breaking_changes": []
}

Guardrails

• Migration Context: If there is a breaking change or a deprecation, always include a 1-2 sentence instruction on what the developer should use instead.
• Tone: Keep it professional, concise, and focused purely on the API consumer's perspective.