SkillsAdd

smithery/dotnet

generate-release-notes

Generate .NET SDK release notes by comparing two git branches, investigating PRs for user-facing changes, and producing a structured markdown document with contributor acknowledgments. Use this when asked to create or draft release notes for a new .NET SDK release.

Installation

$ npx skills add smithery/dotnet --skill generate-release-notes
View on skills.sh ↗ Website ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

azure-ai Same topic
microsoft/azure-skills

Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybr…

568.2K installs
azure-rbac Same topic
microsoft/azure-skills 489K installs
pptx Same topic
anthropics/skills

Use this skill any time a .pptx or .potx file is involved in any way — as input, output, or bot…

216.8K installs
pdf Same topic
anthropics/skills

Use this skill whenever the user wants to do anything with PDF files. This includes reading or …

192.4K installs
docx Same topic
anthropics/skills

Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.do…

184.5K installs
xlsx Same topic
anthropics/skills

Use this skill any time a spreadsheet file is the primary input or output. This means any task …

165K installs

Also in this package

Other skills from smithery/dotnet · top by installs.

npx skills add smithery/dotnet
write-xaml-tests 0 write-ui-tests 0 verify-tests-fail-without-fix 0 use-bootstrap-msbuild 0 update-roslyn-version 0 update-release 0 try-fix 0 run-helix-tests 0 run-device-tests 0 pr-finalize 0

Browse all from smithery/dotnet

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,315 B
  • docs SUMMARY.md 295 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Generate .NET SDK Release Notes

You are generating release notes for the .NET SDK by comparing two git branches. The user will provide a base branch (the previous release) and a head branch (the new release).

Step 1: Discover commits and PRs

  1. Run git log --oneline --no-merges <base>..<head> -- src/ to get the list of commits unique to the head branch.
  2. Extract PR numbers from commit messages using the pattern (#NNNNN).
  3. Filter out noise — skip commits/PRs that are:

- Localization updates (xlf file changes only) - Dependency version bumps from dotnet-maestro[bot] or darc - Backflow merges between branches - Infrastructure-only changes (CI, build scripts) unless they affect user-facing behavior

  1. Record the remaining PR numbers as candidates for investigation.

Step 2: Investigate each PR

For each candidate PR, fetch the PR details from dotnet/sdk on GitHub:

  • Title and description: Understand what the PR does.
  • Author and author_association: Record whether the author is MEMBER, CONTRIBUTOR, or NONE.

- MEMBER = Microsoft employee or org member (has maintainer/contributor access) - CONTRIBUTOR = has previously had a PR merged but is not a member - NONE = first-time or external contributor

  • Labels: Use area labels to help categorize.
  • Linked issues: Follow linked issues in the PR body for specs, documentation, or upstream context.

Determine if the PR is user-facing — does it change CLI behavior, add new commands/options, add analyzers, change MSBuild properties/targets, or otherwise affect how developers use the SDK?

Skip PRs that are purely internal refactoring, test-only changes, or infrastructure fixes with no user-visible impact.

Step 3: Organize into sections

Group the user-facing changes into these four major sections:

1. CLI command improvements

Group by the specific dotnet command affected (dotnet run, dotnet test, dotnet watch, dotnet format, dotnet build, etc.). Each command gets its own ### subsection. Multiple related changes to the same command should be grouped under #### sub-headings within that command's section.

2. Code analyzers

List new or changed analyzers in a table format:

| Analyzer ID | Description | PR |
|-------------|-------------|-----|
| [CAXXXX](docs-link) | Short description | [#NNNNN](pr-link) |

3. MSBuild SDK properties and targets

New or changed MSBuild properties, items, or targets that expose new SDK capabilities. Include XML examples showing usage.

4. Other changes

Infrastructural, niche, or cross-cutting changes that don't fit the above categories but are still user-visible (e.g., encoding changes, verbosity changes).

Step 4: Write feature descriptions

For each feature, write a concise description that includes:

  • What changed: A clear explanation of the new behavior.
  • Why it matters: The user scenario or pain point this addresses.
  • How to use it: Code examples, CLI invocations, or MSBuild XML snippets as appropriate.
  • Links: Link to the PR, and if available, link to specs (check documentation/specs/ in the repo), linked issues, or documentation.

Step 5: Contributor acknowledgments

Inline thanks

For each listed feature where the PR author's author_association is NOT MEMBER (i.e., the contributor does not have maintainer/contributor org access to the SDK repo), add a thank-you line in that feature's section:

Thank you to [@username](https://github.com/username) for this community contribution!

Community contributors section

At the bottom of the document, add a ## Community contributors section listing ALL non-member commit authors from the branch diff (not just featured PR authors). To build this list:

  1. Run git log --no-merges --format="%an|%ae" <base>..<head> -- src/ to get all commit authors.
  2. For each unique author, look up their GitHub username (from noreply email or by fetching the commit from GitHub).
  3. Check their author_association on a PR they authored in dotnet/sdk — exclude MEMBER authors.
  4. Also exclude bots (dotnet-maestro[bot], github-actions[bot], Copilot).
  5. List the remaining community contributors alphabetically by GitHub username.

Step 6: Final document structure

# .NET SDK in .NET <version> - Release Notes

<Intro paragraph>

<Table of contents with nested bullets>

## CLI command improvements
### `dotnet <command>`: Feature title
...

## Code analyzers
### New analyzers
| table |

## New .NET SDK capabilities
### Feature title
...

## Other changes
### Feature title
...

## Community contributors
- [@username](link)
...

.NET SDK updates in .NET <version>:
- [What's new in .NET <version>](docs-link) documentation

Output

Create the release notes as a markdown file at documentation/release-notes/ in the repo. Commit it on a new branch named dev/<user>/release-notes-<version>.