agentleFS
Sign inStart free
Baba01hacker666Baba01hacker666/dummyskills/skills/release-notes-drafter/SKILL.md

release-notes-drafter

Skill0 starsChanged 2 months agoMITView on GitHub

Drafts structured, user-facing release notes categorized by impact from git logs or PR descriptions.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when:

    line 14
  2. Very specific:

    Do not use to track ongoing development tasks.

    line 20
  3. Very specific:

    Do not use to review line-by-line diffs.

    line 21
  4. Very specific:

    If version_tag is missing: label version as [Unreleased / Next Version].

    line 28
  5. Distinctive:

    Do not invent features not represented in the input log.

    line 30
  6. Distinctive:

    Follow these numbered actions:

    line 33
  7. Distinctive:

    If any breaking change is present: place Breaking Changes at the very top of the notes.

    line 47
  8. Very specific:

    If an item lacks description (e.g.

    line 48
  9. Distinctive:

    Stop and ask the user when:

    line 83
  10. Distinctive:

    Commit log is empty or lacks all descriptive text.

    line 84

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Release Notes Drafter

Transforms raw git commit logs or PR summaries into user-focused release notes. Categorizes changes by impact (Breaking Changes, Features, Bug Fixes) while filtering out internal developer churn.

1. Purpose

Communicate release changes clearly to end users and developers. "Release Notes" highlight what changed from the user's perspective, separating breaking updates from routine fixes.

2. When to Use

Use this skill when:

  • Preparing a GitHub release or tagging a new version.
  • Updating CHANGELOG.md before deploying.
  • User requests: "Draft release notes for v1.2.0 from these commits."

3. When Not to Use

  • Do not use to track ongoing development tasks; use status-update.
  • Do not use to review line-by-line diffs; use diff-reviewer.

4. Required Inputs

  • changes_list_or_git_log: List of commit messages, PR titles, or bullet points.
  • version_tag: Target release version (e.g., v2.1.0).

5. Missing-Input Behavior

  1. If version_tag is missing: label version as [Unreleased / Next Version].
  2. Filter out trivial chores (e.g. "bump version", "fix typo in readme", "update ci config") from user-facing notes unless they change runtime requirements.
  3. Do not invent features not represented in the input log.

6. Procedure

Follow these numbered actions:

  1. Action 1: Classify Each Item
    • Breaking Changes: Removed API endpoints, altered return formats, increased minimum requirements.
    • Features: New capabilities or flags.
    • Bug Fixes: Resolved errors or edge case crashes.
    • Maintenance / Docs: Internal improvements (omitted if trivial).
  2. Action 2: Rephrase into User-Facing Language
    • Convert internal commit slang (fix(auth): handle null ptr) into clear English (Fixed an issue where unauthenticated requests caused a crash).
  3. Action 3: Highlight Upgrade Actions (if Breaking Changes exist)
    • Provide exact code before/after migration guidance.
  4. Action 4: Emit Release Notes
    • Format using Section 8.

7. Decision Rules

  • If any breaking change is present: place Breaking Changes at the very top of the notes.
  • If an item lacks description (e.g. wip): exclude it or list under Internal Refinements.

8. Output Format

Emit the release notes using this template:

# Release Notes: [Version Tag] - [Date]

#### ⚠️ Breaking Changes
- [Description of breaking change and upgrade action]

#### 🚀 New Features
- [Feature 1 with user benefit]
- [Feature 2]

#### 🐛 Bug Fixes
- [Bug fix 1 with observed symptom that was cured]
- [Bug fix 2]

#### 📦 Internal & Dependencies
- [Runtime upgrades or dependency updates]

9. Verification Checklist

  • Breaking changes are highlighted first.
  • Descriptions explain user impact, not just raw commit hash.
  • Internal noise commits are filtered out.
  • Version tag and date are clearly indicated.

10. Common Failures and Recovery

Failure SymptomCauseRecovery Action
Raw commit hashes in outputCopy-pasting git logRephrase each commit into a clean descriptive bullet.
Missing breaking change alertBurying API change in fixesScan for "remove", "deprecate", "rename" and elevate to Breaking.

11. Stop or Escalation Conditions

Stop and ask the user when:

  • Commit log is empty or lacks all descriptive text.

12. Examples

Example 1: Successful Execution

Input:

Version: v1.3.0
Commits:
- feat: add --csv export option to users command
- fix: resolve memory leak during bulk file uploads
- chore: bump lodash from 4.17.20 to 4.17.21
- feat!: rename /v1/auth to /v1/tokens

Output:

# Release Notes: v1.3.0

#### ⚠️ Breaking Changes
- **Authentication Route Renamed**: `/v1/auth` is now `/v1/tokens`. Update all API clients to target `/v1/tokens`.

#### 🚀 New Features
- **CSV Export**: Added `--csv` flag to the `users` command for exporting user tables directly to CSV format.

#### 🐛 Bug Fixes
- **Memory Leak**: Resolved memory leak during bulk file uploads that caused high RAM usage.

#### 📦 Internal & Dependencies
- Upgraded `lodash` security patch.

Example 2: Ambiguous or Missing Input

Input:

Commits: (Empty list)

Output:

### Release Notes: Halted - No Changes Provided

- **Status**: Halted

Please provide the commit log, PR list, or change descriptions to draft release notes.

Example 3: Expected Final Output

Output:

# Release Notes: v2.0.1

#### 🐛 Bug Fixes
- **Timeout Handling**: Fixed an issue where network timeouts hung indefinitely instead of returning HTTP 504.
- **Header Parsing**: Corrected parsing of case-insensitive custom HTTP headers.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free