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.
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 upThis 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.
Score from the perspective of a developer upgrading to the new release — not from the perspective of the engineer who implemented the feature.
| 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 |
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.
0-4 unless the value is explained clearly1, not to assume hidden importance1 if it only patches an unannounced or niche feature2-4 items together form one intelligible reader story, such as a cluster of "Unsafe evolution" changesSeveral 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.
Use score for reader interest/value, and use breaking_changes: true for reaction/migration significance.
That means:
Do not inflate a narrow breaking change to 7+ just to keep it visible.
../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