Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

release-notes

Étoiles4

Forks0

Mis à jour14 juin 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

RoderAI

RoderAI/roder

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.