New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Release Notes Editorial Review

by dotnet in dotnet/core

Audits a scored features.json file and its draft release notes against editorial examples to catch over-scored, under-scored, or missing entries.

OfficialMITAuto-check passedDevelopment

Install Release Notes Editorial Review

skills CLI
$ npx skills add dotnet/core --skill review-release-notes -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dotnet/core review-release-notes --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/review-release-notes .claude/skills/review-release-notes && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review-release-notes
GitHub stars
22k
Token cost
~1.6k tokens
SKILL.md length
854 words
Files
1
Skills in repo
15
Repo updated
First seen
Licence
MIT

At a glance

Audits a scored features.json file and its draft release notes against editorial examples to catch over-scored, under-scored, or missing entries.

  • Works in 5 steps: changes.json — the source of truth for… → features.json — the shipped-change… → Draft markdown files (libraries.md,… → …
  • Reviewing release notes before a milestone ships
  • SKILL.md covers When to use, Inputs, Core review questions and Common failure modes, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This skill reviews from the reader's perspective rather than the implementer's, reusing a shared editorial-scoring rubric instead of inventing a separate one. It first checks that features.json and changes.json share the same change IDs and commit keys, including when both are empty, and that noteworthy candidates carry a score and a score_reason.

If the scored file is missing, a placeholder, drops shipped entries, or lacks triage for noteworthy candidates, it stops and sends the work back to the feature-generation step rather than inferring scores from the draft. Otherwise it compares noteworthy candidates against the finished component drafts, and for each important omission either updates the notes or records the editorial reasoning in that entry, without assuming every shipped change automatically earns a section.

When your agent uses it

  • Reviewing release notes before a milestone ships
  • Checking a features.json file for miscalibrated scores
  • Deciding whether the selected highlights feel too broad or too narrow

Example prompts

  • “Review this features.json against the quality bar before we publish.”
  • “Check whether the SDK release notes draft missed anything important.”
  • “Compare this draft against the editorial examples and flag gaps.”

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. changes.json — the source of truth for what shipped
  2. features.json — the shipped-change entries with scored candidates
  3. Draft markdown files (libraries.md, runtime.md, sdk.md, etc.) from each
  4. Editorial examples in references/examples/
  5. The scoring and quality bar references

What it can do on your machine

Read from SKILL.md and the folder at commit 44927bc. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Release Notes Editorial Review loads about 1.6k tokens when it runs. Until then it costs about 79 tokens; SKILL.md has 854 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~79
When it runs · the whole SKILL.md, loaded when a task matches
~1.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from dotnet/core at commit 44927bc, republished under its MIT licence (© dotnet). 854 words, ~1,615 tokens.

Download SKILL.mdSave it as .claude/skills/review-release-notes/SKILL.md (or your agent's skills folder).
name
review-release-notes
description
Review `features.json` scores and draft release notes against the editorial examples and the shared `editorial-scoring` rubric. Use it to identify over-scored, under-scored, or missing features before publishing release notes. DO NOT USE FOR: generating `changes.json` or writing the first draft.

Review Release Notes

Audit a scored features.json file and its markdown draft from the perspective of the reader, not the implementer.

This is the editorial QA stage of the pipeline. Its job is to make sure the release notes feel curated, legible, and exciting to the right audience — not like an API inventory.

This skill reuses the shared rubric from editorial-scoring. It critiques the scoring; it does not invent a separate scoring philosophy.

When to use

  • After generate-features produced features.json
  • After release-notes drafted the markdown
  • Before finalizing a milestone or a refreshed draft
  • When the selection feels too broad, too niche, or too internally focused
  • When you want to compare the current draft against the examples and recalibrate the cut

Inputs

Review these, in order:

  1. changes.json — the source of truth for what shipped
  2. features.json — the shipped-change entries with scored candidates
  3. Draft markdown files (libraries.md, runtime.md, sdk.md, etc.) from each component PR branch if unmerged, or the milestone base branch if merged
  4. Editorial examples in references/examples/
  5. The scoring and quality bar references:
    • ../editorial-scoring/SKILL.md
    • references/feature-scoring.md
    • references/quality-bar.md

Before reviewing, compare features.json with changes.json: both must have the same change IDs and commit keys, including when the arrays are empty because nothing shipped. Confirm that noteworthy candidates have a score and score_reason; individual low-value entries may remain unscored, and a milestone with no noteworthy candidates need not invent any. If the file is missing, is a placeholder, drops shipped entries or commit keys, or lacks triage for noteworthy candidates, stop the review and complete generate-features first. Do not infer scores from the draft as a substitute for the shared triage stage.

Compare noteworthy candidates in features.json and changes.json with the completed component drafts. For each important omission, either update the notes or record the editorial reason in the corresponding features.json entry's score_reason, adjusting its score if the review changes the assessment. Do not treat a PR's presence in changes.json as a requirement to give it a release-note section; apply the reader-centric rubric.

Core review questions

Use the shared rubric from ../editorial-scoring/SKILL.md rather than inventing a new one here. In particular:

  • keep the same reader-centric 10 / 8 / 6 / 4 / 2 / 0 scale
  • apply the same 80/20 audience filter
  • compare the draft against the examples to see whether it still teaches instead of merely enumerating
Example check

Compare the draft against the component examples:

  • Does the length match the importance?
  • Are medium-value items grouped instead of getting their own heavyweight sections?
  • Are performance stories backed by evidence?
  • Does the draft teach, not just enumerate?

Common failure modes

  • Over-scoring — too many 4-6 items are promoted to top-level sections
  • Under-explaining — a real 8+ feature is present but buried or not framed clearly
  • API inventory mode — the draft starts mirroring api-diff instead of telling a user story
  • Technical novelty bias — clever implementation details outrank practical user value
  • Missed revert — a promoted feature was later backed out or does not appear in the actual build
Show full SKILL.md (364 more words)Show less

Multi-model review pattern

For the final editorial QA pass, use this skill as a two-reviewer parallel check to get broader viewpoint diversity:

Preferred set:

  1. Claude Opus 4.6
  2. GPT-5.4

Give both reviewers the same inputs and the same requested output:

  • most correct scoring
  • most wrong scoring
  • important omissions
  • cut list

Then synthesize the overlap and disagreements. Treat consensus as a strong signal, but do not turn this into a blind vote — fidelity to changes.json, the shared editorial-scoring rubric, and the repo's editorial rules still wins.

Reviewer checklist

Do not ask reviewers the vague question "do you like this?" Give them the same specific checks instead:

  1. Which headings still sound vague, passive, anthropomorphic, or promotional?
  2. Which sections fail the 80/20 reader-value test and should be cut, grouped, or demoted?
  3. Which sentences infer feelings or outcomes (trust, confidence, easier, better) instead of stating the concrete change?
  4. Which sections drift into API-inventory mode instead of teaching a user-facing story?
  5. Which promoted items were later reverted, backed out, or are missing from the actual build/package set? Cite the revert PR or verification gap.
  6. Which code samples or examples are weak, confusing, or unsupported by the text?
  7. Which links, issue/PR references, or formatting details still violate house style?
  8. What is the single highest-value rewrite still needed in the draft?
  9. Is the wording conventional, or is it inventing non-standard phrasing or terms?
  10. Are the subject and its adjective or adverb paired in a familiar way?
  11. Would this phrasing seem normal in release notes for another developer platform?
  12. If release-notes/features.json lists this feature, does the section begin with the standard preview blockquote?

Ask reviewers to answer with file + heading + issue + suggested rewrite. This produces actionable review instead of general taste feedback.

Output

Return a concise review with:

  1. Most correct scoring — the features that are best prioritized
  2. Most wrong scoring — over-scored and under-scored items
  3. Important omissions — items from changes.json / features.json that should likely be promoted
  4. Cut list — what to group, compress, demote, or drop first

As a working rule of thumb:

  • 8+ — section-worthy
  • 6-7 — grouped paragraph or short section
  • 0-5 — bug-fix bucket, one-liner, or cut

© dotnet, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .github/skills/review-release-notes of dotnet/core.

Open the folder on GitHubat commit 44927bc

Compare with similar skills

Release Notes Editorial Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Release Notes Editorial Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Release Notes Editorial Review this skilldotnet/core22k—~1.6kAutomated safety check: PassMIT
Add Analyzerdotnet/roslynator3.5k—~1.3kAutomated safety check: PassCustom licence
Release Roslynatordotnet/roslynator3.5k—~1kAutomated safety check: PassCustom licence
Open Pull RequestGremlinq/ExRam.Gremlinq187—~1.5kAutomated safety check: PassMIT
Prepare ReleaseGremlinq/ExRam.Gremlinq187—~1.1kAutomated safety check: PassMIT
Maintain DisCatSharpAiko-IT-Systems/DisCatSharp140—~1.2kAutomated safety check: PassMIT

Similar skills

  • Add Analyzer

    dotnet/roslynator

    Official

    A skill your agent uses when adding a new RCS diagnostic in roslynator (RCS0 formatting, RCS1 general, RCS9 code-analysis), wiring roslynator EditorConfig options, or when docs say CHANGELOG.md…

    3.5k GitHub stars~1.3k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Release Roslynator

    dotnet/roslynator

    Official

    A skill your agent uses when shipping a roslynator release, rolling CHANGELOG.md [Unreleased], updating the VS Code extension changelog, creating a GitHub v release, or optionally tagging cli-v.

    3.5k GitHub stars~1k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Open Pull Request

    Gremlinq/ExRam.Gremlinq

    A skill your agent uses when opening a pull request for the current branch, or when an existing pull request needs a better description - including when the check-description CI check has failed.

    187 GitHub stars~1.5k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Prepare Release

    Gremlinq/ExRam.Gremlinq

    A skill your agent uses when preparing a new release. An agent skill from Gremlinq/ExRam.Gremlinq.

    187 GitHub stars~1.1k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Maintain DisCatSharp

    Aiko-IT-Systems/DisCatSharp

    Guides changes to the DisCatSharp C# Discord library: tracing a payload field through parsing, serialization and caches, then validating across target frameworks.

    140 GitHub stars~1.2k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Revit Toolkit Backward Compat

    Nice3point/RevitToolkit

    Evolve the public surface of Nice3point.Revit.Toolkit without breaking downstream consumers: deprecate a renamed or replaced member with [Obsolete] with a JetBrains [CodeTemplate] auto-conversion…

    176 GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed

More from dotnet/core

All 15 skills in this repo

  • Update .NET OS Packages

    dotnet/core

    Official

    Audits and updates os-packages.json files listing the Linux packages each .NET release needs per distro, then regenerates the Markdown from the JSON.

    22k GitHub stars~2.3k tokensUpdated yesterday
    Auto-check passed

  • Update .NET Supported OS Matrix

    dotnet/core

    Official

    Audits and updates the supported-os.json files for .NET releases, checking them against upstream lifecycle data and regenerating the markdown with the release-notes tool.

    22k GitHub stars~4.1k tokensUpdated yesterday
    Auto-check passed

  • .NET Release Verification

    dotnet/core

    Official

    Validates .NET release data with the release-notes CLI: download URL liveness, SHA512 hashes, CDN latest.version files and aka.ms redirects.

    22k GitHub stars~1.8k tokensUpdated yesterday
    Auto-check passed

  • Generate .NET Release changes.json

    dotnet/core

    Official

    Produces the changes.json manifest for a .NET preview, RC or GA milestone by choosing the right VMR base and head refs and running release-notes generate changes.

    22k GitHub stars~1.7k tokensUpdated yesterday
    Auto-check passed

  • Release Feature Scoring

    dotnet/core

    Official

    Ranks the changes in a release manifest and writes a scored features file that release notes, docs and blog posts can each cut at their own threshold.

    22k GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed

  • Update .NET Distro Packages

    dotnet/core

    Official

    Creates and maintains the per-distro JSON files that list the native packages .NET needs on each Linux distribution, scoped to one .NET version.

    22k GitHub stars~4.3k tokensUpdated yesterday
    Auto-check: notes

Works with

Categories

Questions about Release Notes Editorial Review

What does Release Notes Editorial Review do?

Audits a scored features.json file and its draft release notes against editorial examples to catch over-scored, under-scored, or missing entries. This skill reviews from the reader's perspective rather than the implementer's, reusing a shared editorial-scoring rubric instead of inventing a separate one.json share the same change IDs and commit keys, including when both are empty, and that noteworthy candidates carry a score and a score_reason.

When should I use Release Notes Editorial Review?

Release Notes Editorial Review fits situations like: reviewing release notes before a milestone ships; checking a features.json file for miscalibrated scores; deciding whether the selected highlights feel too broad or too narrow.

How do I install Release Notes Editorial Review in Claude Code?

Run `npx skills add dotnet/core --skill review-release-notes -a claude-code`. Or copy the skill folder (.github/skills/review-release-notes in dotnet/core) into .claude/skills/review-release-notes in your project. Claude Code loads it when a task matches its description.

How do I install Release Notes Editorial Review in Codex?

Run `npx skills add dotnet/core --skill review-release-notes -a codex`. Or copy the skill folder (.github/skills/review-release-notes in dotnet/core) into .agents/skills/review-release-notes in your project. Codex loads it when a task matches its description.

Can I use Release Notes Editorial Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dotnet/core --skill review-release-notes -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-release-notes, .gemini/skills/review-release-notes, .github/skills/review-release-notes and .opencode/skills/review-release-notes in your project.

What does Release Notes Editorial Review need to run?

SKILL.md names no scripts, command-line tools or credentials: Release Notes Editorial Review is instructions for the agent only.

Does Release Notes Editorial Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Release Notes Editorial Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Release Notes Editorial Review use?

Release Notes Editorial Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Release Notes Editorial Review use?

About 1.6k tokens (SKILL.md is roughly 6.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Release Notes Editorial Review?

Skills that share tags, products or a category with Release Notes Editorial Review: Add Analyzer (dotnet/roslynator, 3.5k stars), Release Roslynator (dotnet/roslynator, 3.5k stars), Open Pull Request (Gremlinq/ExRam.Gremlinq, 187 stars) and Prepare Release (Gremlinq/ExRam.Gremlinq, 187 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release Notes Editorial Review?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/core, which has 22,038 GitHub stars. The repository holds 15 skills in this directory. The repository was last updated on October 5, 2026.

Source: dotnet/core on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.