Automating our changelog with Cursor commands
By Mike Coutermarsh |
Ever since Cursor commands were released, we've been using them to find ways to shortcut common tasks at PlanetScale.
A Cursor command allows you to add slash (/actions) commands directly into Cursor. Each command guides the LLM on completing a common and repeatable workflow for you.
Updating our changelog
Each time we ship a feature or improvement at PlanetScale, we release an update on our changelog. Each changelog entry is a markdown file in a single directory checked into a Git repository.
Whenever someone wants to write a new entry, they add a markdown file, open a GitHub pull request and merge it. Shortly after, it gets published on our website and sent out on the changelog RSS feed.
Example changelog:
--- title: 'Webhook API endpoints' createdAt: '2025-04-25' --- We've just added new...
Each changelog follows a similar format and almost always ships after we have already written the docs for the feature.
This makes it a perfect use case for Cursor to generate. The format is specific and the context about the feature is already in our documentation repo. Cursor has everything it needs to publish for us.
Iterating to perfection
We found the easiest way to make a rule is to have Cursor create the initial version itself based on a task we just had it complete.
For example, if I recently used Cursor to update our API docs, I'd finish up the conversation by having it make it repeatable with a command in the future.
Please create a new Cursor command for the process we just went through, so that it is easy to replicate in the future for others. Call it
/updateapi.
This gives you a good starting point. From there, each time you run it, you can update the command if the results aren't satisfactory. We've found it only takes a couple tweaks to get the workflow into a place that we can rely on it.
Launching from Slack
Another benefit of using commands is that they can be kicked off from the Slack bot.

This resulted in Cursor automatically opening the pull request on my behalf. All I needed to do was review and merge it.
Our changelog command
Here's an example of what our changelog command looks like.
## Create a changelog This command creates a new changelog entry following PlanetScale's established format and style guidelines. ### Changelog Format Requirements **File Structure:** - Filename: `kebab-case-title.md` (descriptive, lowercase with hyphens) - Location: `content/changelog/` **Frontmatter:** --- title: 'Human-readable title' category: 'Feature|Enhancement|Bug Fix' # Optional createdAt: 'YYYY-MM-DD' # Current date, sometimes with time --- **Content Guidelines:** - **Concise**: 1-3 paragraphs maximum - **Consistent**: Examine recent similar changelogs to understand format - **Simple language**: Avoid jargon, be conversational - **Human tone**: Informal, not corporate-sounding - **Avoid "programmatically"**: Do not use this word in changelog entries - **Clear scope**: Explicitly mention if feature is Vitess-only or Postgres-only - **External links**: Link to relevant documentation when available - **Screenshots**: Include if available, using `` format **Common Patterns:** - Start with what was added/changed - Explain the benefit or use case - Include links to documentation with `**[Read more](/docs/path)**` - For API features, link to API docs - For UI features, include screenshots - Use bullet points for multiple related items