Add Analyzer
dotnet/roslynator
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…
Scores candidate features by how much a developer upgrading would care, giving a shared rubric and cut guidance for release notes, blog posts and docs.
Install Release Note Editorial Scoring
$ npx skills add dotnet/core --skill editorial-scoring -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install dotnet/core editorial-scoring --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/editorial-scoring .claude/skills/editorial-scoring && rm -rf skills-srcUse ~/.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/
Install the "editorial-scoring" agent skill from https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoring into .claude/skills/editorial-scoring/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "editorial-scoring", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoringType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add dotnet/core --skill editorial-scoring -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install dotnet/core editorial-scoring --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.github/skills/editorial-scoring .agents/skills/editorial-scoring && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "editorial-scoring" agent skill from https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoring into .agents/skills/editorial-scoring/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "editorial-scoring", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add dotnet/core --skill editorial-scoring -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install dotnet/core editorial-scoring --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.github/skills/editorial-scoring .cursor/skills/editorial-scoring && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "editorial-scoring" agent skill from https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoring into .cursor/skills/editorial-scoring/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "editorial-scoring", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/dotnet/core.git --path .github/skills/editorial-scoring--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add dotnet/core --skill editorial-scoring -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install dotnet/core editorial-scoring --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.github/skills/editorial-scoring .gemini/skills/editorial-scoring && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "editorial-scoring" agent skill from https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoring into .gemini/skills/editorial-scoring/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "editorial-scoring", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install dotnet/core editorial-scoringInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add dotnet/core --skill editorial-scoring -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .github/skills && cp -r skills-src/.github/skills/editorial-scoring .github/skills/editorial-scoring && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "editorial-scoring" agent skill from https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoring into .github/skills/editorial-scoring/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "editorial-scoring", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add dotnet/core --skill editorial-scoring -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install dotnet/core editorial-scoring --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.github/skills/editorial-scoring .opencode/skills/editorial-scoring && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "editorial-scoring" agent skill from https://github.com/dotnet/core/tree/main/.github/skills/editorial-scoring into .opencode/skills/editorial-scoring/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "editorial-scoring", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
editorial-scoring- GitHub stars
- 22k
- Token cost
- ~1.8k tokens
- SKILL.md length
- 899 words
- Files
- 1
- Skills in repo
- 15
- Repo updated
- First seen
- Licence
- MIT
At a glance
Scores candidate features by how much a developer upgrading would care, giving a shared rubric and cut guidance for release notes, blog posts and docs.
- Ranking candidate features before writing .NET release notes
- SKILL.md covers Core question, Reader-centric scale, 80/20 audience filter and Strong positive signals, plus 5 more sections
- Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
- Deciding which items to cut from a release announcement or blog post
What it does
This is a rubric, not a task, and it writes no files on its own. It answers how important a feature is to a reader, scored from the viewpoint of a developer upgrading to the new release rather than the engineer who built the feature, so internal engineering work scores low.
The scale runs from 10, a lead story the reader will enable or test first, through 8 and up for features they expect to use, 6 and up for useful grouped material, 4 and up for optional mentions, and 2 and up for items that are usually skipped, down to 0, which is cut from public content. An 80/20 filter favors features that make sense to roughly 80 percent of the audience and keeps a specialized one only when the rest still see why it matters.
Other skills reuse it: generate-features assigns first-pass scores, review-release-notes audits and recalibrates them, release-notes uses the resulting cut, and future blog or docs workflows can apply the same scale with different thresholds. Other release-notes docs are meant to point back here instead of restating the rubric.
When your agent uses it
- Ranking candidate features before writing .NET release notes
- Deciding which items to cut from a release announcement or blog post
- Recalibrating scores that another workflow assigned to features
Example prompts
- “Score these ten candidate features for the release notes from the point of view of a developer upgrading.”
- “Apply the 80/20 audience filter and tell me which features to cut from the announcement.”
- “Recalibrate the first-pass scores in features.md and flag any that look inflated.”
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 Note Editorial Scoring loads about 1.8k tokens when it runs. Until then it costs about 56 tokens; SKILL.md has 899 words of instructions outside code blocks.
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). 899 words, ~1,787 tokens.
Download SKILL.mdSave it as
.claude/skills/editorial-scoring/SKILL.md (or your agent's skills folder).- name
- editorial-scoring
- description
- Apply the shared reader-centric rubric used to rank candidate features for release notes, blog posts, and docs. Use this when you need scoring and cut guidance independent of any one output format or task.
Editorial Scoring
Use this skill whenever you need to answer "How important is this to a reader?"
This skill is intentionally rubric-focused, not task-focused. It does not generate files on its own. Instead, it provides the shared editorial calibration that other skills should reuse:
generate-features— assigns the first-pass scoresreview-release-notes— audits and recalibrates those scoresrelease-notes— uses the resulting cut to decide what gets written up- future blog/docs workflows — can reuse the same rubric with different thresholds
This is the canonical home for the shared scoring scale and 80/20 audience filter. Other release-notes docs should point back here instead of restating the rubric in full.
Core question
Score from the perspective of a developer upgrading to the new release — not from the perspective of the engineer who implemented the feature.
Reader-centric scale
| Score | Reader reaction | What to do with it |
|---|---|---|
10 | "This is the first feature I'll enable or test." | Lead story |
8+ | "I'm going to use this when I upgrade." | Strong release-note feature |
6+ | "I'm glad I know about this. It will likely come in handy." | Good grouped release-note material |
4+ | "I can see how someone could use this. I'll look up the docs if I ever need it." | Optional mention, grouping candidate, or short paragraph |
2+ | "This one is a mystery to me." | Usually skip unless stronger explanation changes the score |
0 | "This is total gobbledygook — internal .NET engineering work." | Cut it from public-facing content |
80/20 audience filter
Default to features that make sense to roughly 80% of the audience.
Keep a more specialized feature for the other 20% only when the remaining 80% can still understand why it matters and react with something like:
"Not for me, but I'm glad that's there for the people who need it."
This is how foundational but initially niche work can still earn a good score.
Strong positive signals
- New public APIs with obvious user value
- CLI or workflow improvements developers will notice right away
- Features that are easy to explain by anchoring them to a familiar tool or workflow
- Clear performance, reliability, or usability wins
- Features people have been asking for
- Changes that require docs, migration notes, or examples to use well
Strong negative signals
- Test-only work
- Build or infrastructure churn
- Refactoring with no user-visible effect
- VMR sync noise, dependency updates, or repo automation
- Product-boundary mismatch — repo-adjacent IDE/editor/design-time tooling work when the notes are for a different product surface
- Highly specialized implementation details that read like internal jargon
- Features that only matter after several stacked conditions are true (for example: uses single-file publish and cares deeply about startup and is willing to do extra training/tuning)
- PRs with very thin descriptions where the only concrete signal is an internal runtime/tooling term like cDAC
- Existing niche surfaces that are barely documented and are not part of the model's normal customer-facing understanding
- Claimed "new API" features where the actual new public API cannot be identified
- Bug fixes for features that were never really announced or are still obscure to most readers
- Old, low-engagement bugs filed internally that sat for a long time without clear external demand
Show full SKILL.md (386 more words)Show less
Common scoring mistakes
- Technical novelty bias — "this is clever" is not the same as "users will care"
- API inventory mode — listing everything from an API diff is not release-note curation
- Effort bias — a difficult implementation may still score low if the reader value is small
- Insider-language inflation — terms like JIT, LSRA, cDAC, intrinsics, or pipeline details can sound impressive but still be a
0-4unless the value is explained clearly - Audience multiplication blindness — when a feature requires several independent interests or behaviors, multiply those filters together instead of scoring the broadest prerequisite alone
- Description vacuum optimism — if the PR does not explain the user scenario, do not fill in the blanks with a generous story
- Documentation blindness — if an "existing" feature is not findable in Learn docs and does not show up as a known customer scenario, that is a signal to score it around
1, not to assume hidden importance - Phantom API stories — if you cannot identify the concrete new public API, do not give API credit based on a vague title alone
- Promotion by association — a fix in a glamorous subsystem is still just a
1if it only patches an unannounced or niche feature - Demand inversion — do not mistake an old internal bug with no reactions for evidence that many users need to hear about the fix
- Fragmentation bias — do not dismiss each small related item in isolation when several
2-4items together form one intelligible reader story, such as a cluster of "Unsafe evolution" changes
Working thresholds
- 8+ — worthy of its own section
- 6-7 — usually grouped with similar items, sometimes a short standalone section
- 0-5 — bug-fix bucket, one-liner, or cut
Several 3-5 items in the same area can still combine into one worthwhile writeup. Keep the individual scores honest, then let the writing stage roll them up into a single themed section.
Breaking changes are separate from score
Use score for reader interest/value, and use breaking_changes: true for reaction/migration significance.
That means:
- a low-score breaking change often still deserves a short end-of-notes callout
- a high-score breaking change may deserve both a full feature writeup and a migration note
Do not inflate a narrow breaking change to 7+ just to keep it visible.
Canonical references
../release-notes/references/feature-scoring.md— detailed scoring guidance../release-notes/references/quality-bar.md— what good release notes look like../release-notes/references/examples/README.md— editorial examples and why they work
© 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/editorial-scoring of dotnet/core.
Open the folder on GitHubat commit 44927bc
Compare with similar skills
Release Note Editorial Scoring 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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Release Note Editorial Scoring this skilldotnet/core | 22k | — | ~1.8k | Automated safety check: Pass | MIT | |
| Add Analyzerdotnet/roslynator | 3.5k | — | ~1.3k | Automated safety check: Pass | Custom licence | |
| Release Postquarto-dev/quarto-r | 160 | 1 repos | ~2.5k | Automated safety check: Pass | MIT | |
| Release Roslynatordotnet/roslynator | 3.5k | — | ~1k | Automated safety check: Pass | Custom licence | |
| Open Pull RequestGremlinq/ExRam.Gremlinq | 187 | — | ~1.5k | Automated safety check: Pass | MIT | |
| Prepare ReleaseGremlinq/ExRam.Gremlinq | 187 | — | ~1.1k | Automated safety check: Pass | MIT |
Similar skills
- Official
Release Post
quarto-dev/quarto-r
Create professional package release blog posts following Tidyverse or Shiny blog conventions.
- Official
Release Roslynator
dotnet/roslynator
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.
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.
Prepare Release
Gremlinq/ExRam.Gremlinq
A skill your agent uses when preparing a new release. An agent skill from Gremlinq/ExRam.Gremlinq.
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.
More from dotnet/core
All 15 skills in this repo- Official
Update .NET OS Packages
dotnet/core
Audits and updates os-packages.json files listing the Linux packages each .NET release needs per distro, then regenerates the Markdown from the JSON.
- Official
Update .NET Supported OS Matrix
dotnet/core
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.
- Official
.NET Release Verification
dotnet/core
Validates .NET release data with the release-notes CLI: download URL liveness, SHA512 hashes, CDN latest.version files and aka.ms redirects.
- Official
Generate .NET Release changes.json
dotnet/core
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.
- Official
Release Feature Scoring
dotnet/core
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.
- Official
Release Notes Editorial Review
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.
Related
Works with
Categories
Questions about Release Note Editorial Scoring
What does Release Note Editorial Scoring do?
Scores candidate features by how much a developer upgrading would care, giving a shared rubric and cut guidance for release notes, blog posts and docs. This is a rubric, not a task, and it writes no files on its own. It answers how important a feature is to a reader, scored from the viewpoint of a developer upgrading to the new release rather than the engineer who built the feature, so internal engineering work scores low.
When should I use Release Note Editorial Scoring?
Release Note Editorial Scoring fits situations like: ranking candidate features before writing .NET release notes; deciding which items to cut from a release announcement or blog post; recalibrating scores that another workflow assigned to features.
How do I install Release Note Editorial Scoring in Claude Code?
Run `npx skills add dotnet/core --skill editorial-scoring -a claude-code`. Or copy the skill folder (.github/skills/editorial-scoring in dotnet/core) into .claude/skills/editorial-scoring in your project. Claude Code loads it when a task matches its description.
How do I install Release Note Editorial Scoring in Codex?
Run `npx skills add dotnet/core --skill editorial-scoring -a codex`. Or copy the skill folder (.github/skills/editorial-scoring in dotnet/core) into .agents/skills/editorial-scoring in your project. Codex loads it when a task matches its description.
Can I use Release Note Editorial Scoring 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 editorial-scoring -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/editorial-scoring, .gemini/skills/editorial-scoring, .github/skills/editorial-scoring and .opencode/skills/editorial-scoring in your project.
What does Release Note Editorial Scoring need to run?
SKILL.md names no scripts, command-line tools or credentials: Release Note Editorial Scoring is instructions for the agent only.
Does Release Note Editorial Scoring 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 Note Editorial Scoring 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 Note Editorial Scoring use?
Release Note Editorial Scoring 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 Note Editorial Scoring use?
About 1.8k tokens (SKILL.md is roughly 7.1k 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 Note Editorial Scoring?
Skills that share tags, products or a category with Release Note Editorial Scoring: Add Analyzer (dotnet/roslynator, 3.5k stars), Release Post (quarto-dev/quarto-r, 160 stars), Release Roslynator (dotnet/roslynator, 3.5k stars) and Open Pull Request (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 Note Editorial Scoring?
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.