claudegoodies
Skill

draft-release-notes

From cobusgreyling

>

Formats a structured changelog-scan list into a categorized RELEASE_NOTES_DRAFT.md file for human review.

Use it when

  • You already have changelog-scan output listing changes with PR links
  • Preparing release notes and want breaking/security items flagged upfront
  • Need a draft split into Features, Bug Fixes, Security, etc. sections
  • Want contributor thanks and full changelog link auto-formatted

Skip it if

  • Requires changelog-scan output as input, not standalone
  • Only produces a draft, never publishes anything
  • Escalates instead of drafting when over ~40 items or human review flagged

Facts

Repository
cobusgreyling/loop-engineering
Status
Actively maintained
Last commit
Source file
starters/changelog-drafter/.claude/skills/draft-release-notes/SKILL.md

Source preview

The instructions Claude Code reads when this skill runs.

# 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 scan
View full source on GitHub →

Other skills