draft-release-notes
The draft-release-notes skill transforms structured changelog data into a formatted release notes document, organizing changes by category (breaking changes, features, bug fixes, performance, security, documentation) with concise one-line entries and PR links. Use this skill after running a changelog scan to convert raw commit metadata into a human-readable draft that's ready for editorial review before publication, following a consistent template that emphasizes breaking changes and security updates at the top.
git clone --depth 1 https://github.com/cobusgreyling/loop-engineering /tmp/draft-release-notes && cp -r /tmp/draft-release-notes/starters/changelog-drafter/.grok/skills/draft-release-notes ~/.claude/skills/draft-release-notesSKILL.md
# Draft Release Notes Skill ## Inputs - Structured output from `changelog-scan` (the list of items + summary) - Previous release version (from state) - Target next version (or "unreleased" / "next") - Optional: short "Release voice" guidance from AGENTS.md or a project skill (tone, what to highlight, what to omit) ## Output Write a ready-to-review draft to `RELEASE_NOTES_DRAFT.md` (or print it clearly so the loop can save it). Use this structure (adapt section names to what actually exists; omit empty sections): ```markdown # Release Notes — vX.Y.Z (unreleased) ## Breaking Changes - ... ## Features - ... ## Bug Fixes - ... ## Performance - ... ## Security - ... ## Documentation & Examples - ... ## Internal / Maintenance (usually omitted from public notes) - ... **Thanks** to @contributor1, @contributor2 for contributions to this release. **Full changelog**: https://github.com/ORG/REPO/compare/vPREV...HEAD ``` ## Rules - Be concise and scannable. One line per item when possible, with link to PR. - Use the actual title / one-sentence summary from the scan. Do not embellish or add marketing fluff unless the project voice explicitly wants it. - Always call out breaking changes and security items at the top. - If a change has a user upgrade step that is obvious from the PR, include a one-sentence "Upgrade note". - Never claim a change was made if it was not in the scanned input. - At the very end of the draft, include a short "Draft generated by loop — please review for accuracy and tone before publishing." ## When to Escalate Instead of Drafting - More than ~40 items in one window → suggest splitting the release or human curation. - Any breaking or security item → include prominent callout and recommend human wordsmithing. - The scan summary says "human review needed first". After writing the draft, the loop should update state with the draft location and "pending human review".
Check token budget and run-log spend before and after a loop run. Enforces early exit when over budget or when there is no actionable work.
>
Independent checker for loop-produced changes. Rejects unless tests pass and scope is minimal. Never implement fixes.
>
>
>
>
>