Run any Skill in Manus with one click

review-changelog

Stars2,235

Forks550

UpdatedApril 15, 2026 at 20:09

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

modrinth

modrinth/code

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

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

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).
Read the standard above in full before reviewing. The bullet rules, section/verb agreement, and "Don't" list are the source of truth.
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.
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.
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.
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.

More from this repository

same repository

cross-platform-pages

modrinth/code

Convert a page to the cross-platform page system so it works in both the website and the desktop app. Use when moving a page into packages/ui/src/layouts/, creating shared or wrapped layouts, or setting up DI contracts for platform abstraction.

2026-04-182.2k

api-module

modrinth/code

Add a new API endpoint module to packages/api-client from an OpenAPI schema. Use when adding new backend endpoints, creating API client modules, or when an openapi.yml is provided.

2026-03-162.2k

figma-mcp

modrinth/code

Use the Figma MCP server to translate a Figma design into a Vue page or component layout. Use when the user provides a Figma URL, asks to implement a design, or wants to draft a page layout from Figma.

2026-03-162.2k

i18n-pass

modrinth/code

Perform an i18n localization pass on changed files or a pull request, converting hard-coded English strings to the @modrinth/ui i18n system. Use when internationalizing a set of changes, reviewing a PR for untranslated strings, or converting a specific component.

2026-03-162.2k

tanstack-query

modrinth/code

Convert a page or component from useAsyncData/manual ref patterns to TanStack Query for server state management. Use when migrating data fetching to useQuery/useMutation, adding cache invalidation, or replacing useAsyncData with TanStack Query.

2026-03-162.2k

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

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).
Read the standard above in full before reviewing. The bullet rules, section/verb agreement, and "Don't" list are the source of truth.
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.
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.
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.
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.