rewind: Skill for Claude Code

Changelog Writer

Writes and audits entries in docs-mintlify/changelog.mdx. Enforces a reader-facing voice modeled on Stripe, Linear, Resend, and Mintlify: short, benefit-led, concrete, no vanity.

When to use

• Adding a new entry after a release
• Auditing existing entries for consistency
• Reviewing a draft entry someone wrote for voice and length
• Cleaning up accumulated drift across the file

The core rule

Every sentence must answer: "what can a reader now do, or rely on?" If a line describes how the team built something, cut it.

Writing rules

1. Length. One sentence for minor changes. Two short sentences or ≤6 bullets for major releases. Anything longer is two entries pretending to be one.
2. Voice. Active, present tense, reader as subject. "You can now filter by date" or "Listening endpoints now include apple_music_url" — not "We added date filtering" or "Date filtering has been implemented".
3. Benefit before mechanism. Lead with the capability. Put the tool/endpoint name second. "Full article text via new get_article tool" — not "New Voyage AI integration enables get_article".
4. Concrete nouns. Name the endpoint, field, tool, or parameter explicitly (wrap in backticks). Vague ("improvements to reading") is useless.
5. Link out. For anything with its own doc page, link it. Don't re-explain in the changelog.
6. No emojis. No exclamation marks. Project-wide rule and matches Stripe/Linear convention.

Anti-patterns — always cut

• Version archaeology. "Rolls up v0.3.0 → v0.4.3 into one entry", "this release combines…". The date label does this work.
• Vanity metrics. Coverage percentages, "rescues NYT/Reuters", "3x faster", "now supports 12 providers". Readers don't care about the work; they care about the outcome. If a number matters (a new cap, a new limit), state it flatly — no celebration.
• Future work. "Coming soon", "planned for next release", "future: Goodreads support". Changelogs are for shipped things only. File futures in a roadmap doc.
• Implementation trivia. Embedding model names, algorithm constants (RRF k=60, cosine, 512 dim), tokenizer details, cache TTLs, internal class names (verify_credentials method), framework specifics. Exception: if a reader can pass or observe the thing, it stays.
• Counting the work. "12 new tools", "10 entity resources", "3 new prompts" — numbers without named items are filler. Either name the useful ones or omit.
• Self-reference to prior entries. "As mentioned last release…", "building on the March update…". Each entry stands alone.
• Hedged language. "We've begun rolling out", "some users may see". Either it shipped or it didn't.