Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →rait-09/release-notes
Generate a GitHub release note draft for this Obsidian plugin repository.
Passed 10 of 16 test cases with the skill, and 11 of 16 without it.
3 fixed11 passed either way4 still failing4 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
We need to inspect our repository tags to determine the previous release tag for drafting release notes. How should tag listing be sorted to ensure higher version numbers appear first?
| Checked | Without skill | With skill |
|---|---|---|
| The response uses `--sort=-v:refname` when listing git tags. | Missed | Passed |
The instructions your model reads when the skill loads.
Generate a release note draft for this repository by analyzing git changes since the previous release. The output is a Markdown code block ready to paste into a GitHub release — do NOT create the release itself.
The version number is provided as an argument (e.g. /release-notes 0.11.0). If no version is given, ask for one before proceeding.
The "previous release" depends on the version type being drafted:
-preview): Find the most recent stable tag, skipping all prereleases. This is because stable release notes cover everything since the last stable release — they aggregate all prerelease changes into one cohesive set of notes.-preview.N): Find the most recent tag of any kind (stable or prerelease). Prerelease notes only cover the incremental delta since the last tag.Use git tag --sort=-v:refname to list tags and pick the right one. Confirm the previous tag to the user before continuing (e.g. "Previous release: v0.10.2 — generating notes for changes since then.").
Run these in parallel where possible:
git log {prev_tag}..HEAD --oneline — the list of changesgit diff --stat {prev_tag}..HEAD — which files changedsrc/, styles.css, manifest.json, etc.) to understand what each change actually does at the code level. This is critical — commit messages alone are not enough to write accurate user-facing descriptions.#NNN references from commit messages. Note: commit messages often contain PR numbers (from merge commits), not the original issue numbers. Use whatever #NNN is in the commit message as-is — the author will verify and correct these during review.git log --format='%aN' {prev_tag} | sort -u # existing contributors
git log --format='%aN' {prev_tag}..HEAD | sort -u # contributors in this range
git log --format='%aN <%aE>' {prev_tag}..HEAD and cross-reference with #NNN in their commit messages. The GitHub username may differ from the git author name — check the commit on GitHub if needed.gh release view {tag}. This helps identify bugs that were introduced and fixed within the prerelease cycle — those should be excluded from the stable release notes since they never affected stable users.Before writing, think through what each change means from a user's perspective:
test cases passed, vs 11 / 16 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.