// 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.
Run dotnet.Tests incrementally without a full build.cmd rebuild. Use after modifying source code in SDK projects to quickly build only changed projects, deploy their outputs into the redist SDK layout, and run tests against them.
Author end-to-end Static Web Assets integration tests that exercise MSBuild targets through build, publish, or pack. USE FOR: writing new SWA integration tests, choosing a test asset and base class, dynamically modifying projects at runtime, selecting the right manifest to assert on, verifying the full asset pipeline (primary, compressed, endpoints). DO NOT USE FOR: unit tests of individual tasks (write those directly), baseline regeneration (use swa-baseline-regeneration), troubleshooting failures (use swa-troubleshooting).
Regenerate Static Web Assets test baselines. USE FOR: fixing "generated manifest should match the expected baseline" errors, updating baseline JSON files after legitimate build output changes, understanding the baseline comparison system.
Understand and fix Static Web Assets Pack tests. USE FOR: fixing Pack test assertion failures after nupkg content changes, tracing MSBuild conditions to expected nupkg content, updating test assertions for new or changed package layouts, understanding conditional pack logic in .targets files.
Diagnose and fix common Static Web Assets test and build failures. USE FOR: analyzing CI failures, identifying root cause categories from error messages, fixing metadata propagation bugs, timing/ordering issues in MSBuild targets, test assertion mismatches.
Use this skill when you are implementing a change on src\StaticWebAssetsSdk and want to test the behavior locally to validate it works as expected.
| name | generate-release-notes |
| description | 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. |
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).
git log --oneline --no-merges <base>..<head> -- src/ to get the list of commits unique to the head branch.(#NNNNN).dotnet-maestro[bot] or darcFor each candidate PR, fetch the PR details from dotnet/sdk on GitHub:
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 memberNONE = first-time or external contributorDetermine 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.
Group the user-facing changes into these four major sections:
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.
List new or changed analyzers in a table format:
| Analyzer ID | Description | PR |
|-------------|-------------|-----|
| [CAXXXX](docs-link) | Short description | [#NNNNN](pr-link) |
New or changed MSBuild properties, items, or targets that expose new SDK capabilities. Include XML examples showing usage.
Infrastructural, niche, or cross-cutting changes that don't fit the above categories but are still user-visible (e.g., encoding changes, verbosity changes).
For each feature, write a concise description that includes:
documentation/specs/ in the repo), linked issues, or documentation.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!
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:
git log --no-merges --format="%an|%ae" <base>..<head> -- src/ to get all commit authors.author_association on a PR they authored in dotnet/sdk — exclude MEMBER authors.dotnet-maestro[bot], github-actions[bot], Copilot).# .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
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>.