Run any Skill in Manus with one click

release-notes

Stars4

Forks0

UpdatedJune 14, 2026 at 16:51

Draft release notes for Roder releases, new crates or packages, feature additions, behavior changes, and fixes. Use when writing release notes, changelog summaries, release announcements, or explaining what changed in a branch, PR, crate, SDK, or package release.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

RoderAI

RoderAI/roder

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	release-notes
description	Draft release notes for Roder releases, new crates or packages, feature additions, behavior changes, and fixes. Use when writing release notes, changelog summaries, release announcements, or explaining what changed in a branch, PR, crate, SDK, or package release.
metadata	{"short-description":"Draft Roder release notes"}

Release Notes

Use this skill to turn code, changesets, PRs, or changelog entries into clear release notes that explain what was added, what changed, and what was fixed.

Workflow

Identify the release scope:
- Repo-wide release, single crate, SDK, package, PR, or branch.
- Target audience: users, integrators, contributors, or maintainers.
- Source range: tags, commits, PR diff, .changeset/*.md, or existing CHANGELOG.md entries.
Gather evidence before drafting:
- Read relevant .changeset/*.md files first when present.
- Check changed package names in knope.toml or package manifests when scope is unclear.
- Inspect diffs or changelogs for user-visible behavior, APIs, docs, tests, and bug fixes.
- Ignore unrelated dirty-tree work unless it is in the requested release scope.
Categorize changes:
- Added: New crates, packages, commands, APIs, provider support, UI surfaces, docs, or workflows.
- Changed: Behavior differences, renamed concepts, new defaults, protocol shape changes, UX refinements, dependency/runtime changes, or migration-relevant differences.
- Fixed: Bugs, crashes, incorrect output, flaky tests, race conditions, broken docs, compatibility issues, or release automation failures.
- Removed: Deleted APIs, commands, config, docs, packages, or behavior. Include only when relevant.
Write from the user's point of view:
- Prefer concrete outcomes over implementation details.
- Mention affected crates/packages when helpful.
- Call out breaking changes or required user action plainly.
- Do not invent impact. If a change is internal-only, label it as internal or omit it from user-facing release notes.
- Keep each bullet short and specific.

Output Template

Use this shape by default, trimming empty sections:

## Release Notes

### Added
- Added ...

### Changed
- Changed ...

### Fixed
- Fixed ...

### Removed
- Removed ...

### Notes
- Breaking change: ...
- Migration: ...
- Internal: ...

For a single package release, include the package name and version if known:

## `roder-example` v0.1.0

### Added
- Added ...

Roder-Specific Notes

New crates use version = "0.1.0" and require regenerated knope.toml.
Released package changes should have .changeset/*.md coverage. Use $create-changeset when a release note reveals a missing changeset.
This project moves quickly; describe the current canonical behavior instead of documenting legacy shims unless the release actually ships a compatibility path.

More from this repository

same repository

roder-theming

RoderAI/roder

Use when editing TUI rendering code, adding new visible surfaces, or working on themes/CSS in Roder. Keeps class/id taxonomy, cascade order, and the supported CSS subset consistent across sessions.

2026-06-144

changelog

RoderAI/roder

Draft a changelog entry from the latest changes.

2026-06-124

repo-tour

RoderAI/roder

Use when a user asks for an orientation tour of an unfamiliar repository. Produces a structured tour of entry points, key modules, and how to run tests.

2026-06-124

changesets

RoderAI/roder

Use when a PR changes any released package (crates/*, sdk/typescript, sdk/python, packages/edit-tools), when the changeset-gate CI check fails, when adding a new crate or package to the release config, or when working on knope versioning/release automation. For the step-by-step workflow to add a change file, use $create-changeset.

2026-06-124

create-changeset

RoderAI/roder

Use when a PR or branch changes any released package (crates/*, sdk/typescript, sdk/python, packages/edit-tools), when the changeset-gate CI check fails, or before pushing work that touches versioned package directories. Creates the required .changeset/*.md file for knope per-package versioning.

2026-06-124

rust-workspace

RoderAI/roder

Runs and extends the Gode/Roder Rust workspace using mise, lld, Cargo incremental builds, and Makefile test targets. Use when adding crates or dependencies, running Rust tests, building roder-cli, or configuring local Rust tooling in this repo.

2026-06-124

name	release-notes
description	Draft release notes for Roder releases, new crates or packages, feature additions, behavior changes, and fixes. Use when writing release notes, changelog summaries, release announcements, or explaining what changed in a branch, PR, crate, SDK, or package release.
metadata	{"short-description":"Draft Roder release notes"}

Release Notes

Use this skill to turn code, changesets, PRs, or changelog entries into clear release notes that explain what was added, what changed, and what was fixed.

Workflow

Identify the release scope:
- Repo-wide release, single crate, SDK, package, PR, or branch.
- Target audience: users, integrators, contributors, or maintainers.
- Source range: tags, commits, PR diff, .changeset/*.md, or existing CHANGELOG.md entries.
Gather evidence before drafting:
- Read relevant .changeset/*.md files first when present.
- Check changed package names in knope.toml or package manifests when scope is unclear.
- Inspect diffs or changelogs for user-visible behavior, APIs, docs, tests, and bug fixes.
- Ignore unrelated dirty-tree work unless it is in the requested release scope.
Categorize changes:
- Added: New crates, packages, commands, APIs, provider support, UI surfaces, docs, or workflows.
- Changed: Behavior differences, renamed concepts, new defaults, protocol shape changes, UX refinements, dependency/runtime changes, or migration-relevant differences.
- Fixed: Bugs, crashes, incorrect output, flaky tests, race conditions, broken docs, compatibility issues, or release automation failures.
- Removed: Deleted APIs, commands, config, docs, packages, or behavior. Include only when relevant.
Write from the user's point of view:
- Prefer concrete outcomes over implementation details.
- Mention affected crates/packages when helpful.
- Call out breaking changes or required user action plainly.
- Do not invent impact. If a change is internal-only, label it as internal or omit it from user-facing release notes.
- Keep each bullet short and specific.

Output Template

Use this shape by default, trimming empty sections:

## Release Notes

### Added
- Added ...

### Changed
- Changed ...

### Fixed
- Fixed ...

### Removed
- Removed ...

### Notes
- Breaking change: ...
- Migration: ...
- Internal: ...

For a single package release, include the package name and version if known:

## `roder-example` v0.1.0

### Added
- Added ...

Roder-Specific Notes

New crates use version = "0.1.0" and require regenerated knope.toml.
Released package changes should have .changeset/*.md coverage. Use $create-changeset when a release note reveals a missing changeset.
This project moves quickly; describe the current canonical behavior instead of documenting legacy shims unless the release actually ships a compatibility path.