Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

release-notes

Estrellas4

Forks0

Actualizado14 de junio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

RoderAI

RoderAI/roder

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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

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.