review-changelog

name	review-changelog
description	Review the latest changelog entry in packages/blog/changelog.ts against the project's changelog style guide and flag bullets that need rewriting. Use when checking a freshly added changelog entry before opening a PR, or when the user asks to review/lint the latest changelog.
argument-hint	["product?"]

Refer to the standard: @standards/maintaining/CHANGELOG.md

Steps

1. Locate the latest entry:

   • Open packages/blog/changelog.ts.
   • The latest entries are at the top of the VERSIONS array.
   • If $ARGUMENTS specifies a product (web, hosting, app), review the most recent entry for that product. Otherwise, review the most recent entry overall, plus any sibling entries sharing the same date (coordinated releases ship together).

2. Read the standard above in full before reviewing. The bullet rules, section/verb agreement, and "Don't" list are the source of truth.

3. Check the entry shell:

   • date is a valid ISO 8601 timestamp.
   • product is one of web, hosting, app.
   • version is present for app entries and omitted for web/hosting.
   • Section headings use ## Added, ## Changed, ## Fixed, ## Security (or a featured-release linked heading). Flag legacy ## Improvements.

4. Review each bullet against the standard. For each bullet, check:

   • Voice/tense matches the section heading.
   • Opening verb agrees with its section.
   • Describes observable behavior, not implementation.
   • Specific enough to identify the surface (names the tab/page/modal).
   • One sentence, ends with a period, sentence case.
   • Uses branded names (Modrinth App, Modrinth Hosting) correctly.
   • No filler ("issue with", "issue where", "various", "some"), no vague intensifiers, no apologies, no PR/commit references (unless crediting a third-party contributor with a linked GitHub profile).
   • Not a duplicate sub-fix of a bigger change already listed.

5. Report findings as a short list grouped by entry. For each problem bullet, show the original line and a suggested rewrite. If the entry is clean, say so explicitly. Do not edit the file unless the user asks - this skill is a review pass, not a rewrite pass.

6. If the user then asks to apply fixes, edit packages/blog/changelog.ts directly using the suggested rewrites. Preserve tab indentation and template literal formatting.