원클릭으로 Manus에서 모든 스킬 실행

release-notes

스타4

포크0

업데이트2026년 6월 14일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

RoderAI

RoderAI/roder

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.