Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →runkids/skillshare-changelog
Generate CHANGELOG.md entry from recent commits in conventional format. Also syncs the website changelog page.
Passed 15 of 18 test cases with the skill, and 6 of 18 without it.
and 10 more in the full report
11 fixed7 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/2/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
What code verification step must be performed before documenting a new feature in the changelog entry?
| Checked | Without skill | With skill |
|---|---|---|
| Requires inspecting or grepping source code to verify feature existence. | Missed | Passed |
The instructions your model reads when the skill loads.
Review or generate a user-facing changelog entry. Prefer the open Release Please PR and its manifest version for an upcoming release. For historical work, $ARGUMENTS specifies the requested tag or commit range.
Scope: This skill updates CHANGELOG.md and syncs the website changelog (website/src/pages/changelog.md). It does NOT generate RELEASE_NOTES, choose a new version, or handle the full release workflow — use /release for that.
Before acting, run python3 scripts/ai-context.py release. That topic is the source of truth for authorization, changelog content and synchronization rules; this skill retains the entry-generation workflow.
For an upcoming release, work on the Release PR branch and read .github/release-please-manifest.json. Verify the latest published tag and use its range to the Release PR head. Keep the proposed version; this skill does not authorize a version change. Tags may exist for unpublished drafts, so do not assume the highest local tag is the latest published release.
For historical work, use the user-requested tags or range.
git log <previous-published-tag>..<release-pr-head-or-requested-tag> --oneline --no-merges
Review the generated Release Please entry before writing. Preserve useful manual examples and migration notes. Do not add a second entry for the same version.
Group commits by conventional commit type:
| Prefix | Category |
|---|---|
feat | New Features |
fix | Bug Fixes |
perf | Performance |
| breaking change | Breaking Changes and migration notes |
revert | Reverts, when user-visible |
Exclude test-only, CI-only, pure refactoring, documentation-only and internal maintenance entries from published notes.
Before writing, read the most recent 2-3 entries in CHANGELOG.md to match the established tone and structure. The style evolves over time — always match the latest entries, not a hardcoded template.
test cases passed, vs 6 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.