Regitize release notes
Portable AI-agent skills for auditing and improving Git history
npx -y skills add gadost/regitize --skill regitize-release-notesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate accurate user-focused release notes from a verified Git commit range by inspecting commit messages, patches, tags, and issue references. Use when the user invokes regitize-release-notes, asks for release notes or a changelog draft, wants changes summarized since a tag, or needs cleaned history converted into a publishable release summary.
SKILL.md
1.8 KB, as published. Nobody here has run it
Regitize Release Notes
Draft release notes from repository evidence. Prefer user-visible outcomes over a commit-by-commit transcript.
Workflow
- Determine the range. Respect explicit
fromandtorefs. Otherwise use the latest reachable prior tag throughHEAD; if no tag exists, include all reachable commits. - Locate this skill directory and run
node <skill-dir>/scripts/collect-release-context.mjs, adding--from,--to, and--outputas required. - Read every captured commit and patch. Exclude merge noise, duplicate descriptions, and internal-only work unless the audience needs it.
- Draft using references/release-format.md. Group by impact rather than commit order. Call out breaking changes, migrations, security fixes, and deprecations first.
- Preserve issue or PR identifiers found in history, but do not invent links, identifiers, performance numbers, or compatibility claims.
- Show the selected range and draft. Write the requested file, defaulting to
RELEASE_NOTES.mdonly when the user asked for a file artifact. - Report gaps where the diff demonstrates a change but its user impact cannot be established.
Quality rules
- Combine multiple implementation commits into one outcome.
- Use plain language and active voice.
- Distinguish confirmed behavior from inference.
- Omit empty sections.
- Do not modify Git history, tags, releases, or remotes.