Publish Release

Verify the PR is merged. Extract:

• The release version from the PR title and branch name
• The merge commit SHA
• The PR description (which contains draft release notes, ApiCompat, and ApiDiff from the prepare-release skill)

Step 2: Determine Version and Commit Range

1. Read src/Directory.Build.props at the merge commit to confirm <VersionPrefix>. The tag is v{VersionPrefix}.
2. Determine the previous release tag from gh release list (most recent published release — exclude drafts with --exclude-drafts).
3. Identify the full commit range: previous release tag → merge commit.

Step 3: Check for Additional PRs

Compare the PRs included in the original prepare-release PR description with the full set of PRs now merged in the commit range. Use the SemVer assessment guide (owned by the bump-version skill) to evaluate the impact of any new PRs against the version that was committed during preparation.

1. Extract the PR list from the prepare-release PR description (all #NNN references in release notes sections).
2. Get the full set of PRs merged between the previous release tag and the merge commit.
3. Identify any new PRs — PRs present in the full range but not referenced in the prepare-release description.

If new PRs exist, warn the user with details for each new PR:

⚠️ New PRs merged since release preparation:

• #NNN — Title (@author) — [impact assessment]

For each new PR, assess and flag impacts:

• Breaking changes — Does this PR introduce breaking changes not covered by the original audit? If yes, warn that the semantic version may need to be re-assessed. This is a critical warning — the release version may be incorrect.
• API surface changes — Does this PR add new public APIs? If yes, warn that the ApiCompat and ApiDiff results in the prepare-release PR are stale and should not be relied upon.
• Version impact — Does this PR change the SemVer level (e.g., what was assessed as PATCH now warrants MINOR, or MINOR now warrants MAJOR)?

If any new PRs have version-level or breaking change impacts, strongly recommend that the user either:

1. Abort and re-run the prepare-release skill to produce an updated release PR with correct version, ApiCompat, and ApiDiff results
2. Acknowledge the impacts and proceed with the current version, documenting the decision in the release notes

The user must explicitly choose an option before proceeding.

Step 4: Refresh Release Notes

Re-categorize all PRs in the commit range (including any new ones from Step 3). See the categorization guide for detailed guidance.

1. Re-run the breaking change audit using the breaking-changes skill if new PRs were found that may introduce breaks. Otherwise, carry forward the results from the prepare-release PR.
2. Re-categorize all PRs into sections (What's Changed, Documentation, Tests, Infrastructure).
3. Re-attribute co-authors for any new PRs by harvesting Co-authored-by trailers from all commits in each PR.
4. Update acknowledgements to include contributors from new PRs.

Step 5: Validate README Code Samples

Verify that all C# code samples in the package README files compile against the current SDK at the merge commit. Follow the README validation guide for the full procedure.

1. Extract csharp-fenced code blocks from README.md and src/PACKAGE.md
2. Create a temporary test project at tests/ReadmeSnippetValidation/
3. Build and report results
4. Delete the temporary project

Step 6: Review Sections

Present each section for user review:

1. Breaking Changes — sorted most → least impactful
2. What's Changed — chronological
3. Documentation Updates — chronological
4. Test Improvements — chronological
5. Repository Infrastructure Updates — chronological
6. Acknowledgements

Highlight any changes from the prepare-release draft (new entries, reordered entries, updated descriptions) so the user can see what's different.

Step 7: Preamble

Every release must have a preamble — a short paragraph summarizing the release theme that appears before the first ## heading. The preamble is not optional. The preamble may mention the presence of breaking changes as part of the theme summary, but the versioning documentation link belongs under the Breaking Changes heading (see template), not in the preamble.

Extract the draft preamble from the prepare-release PR description and present it alongside a freshly drafted alternative (accounting for any new PRs).

Present both options and let the user choose one, edit one, or enter their own text or markdown.

Step 8: Final Assembly

1. Combine the confirmed preamble with all sections from previous steps.
2. Notable callouts — only if something is extraordinarily noteworthy.
3. Present the complete release notes for user approval.

Follow references/formatting.md when composing and updating the release body.

Step 9: Create Draft Release

Display release metadata for user review:

• Title / Tag: the confirmed version (e.g. v1.1.0)
• Target: merge commit SHA, its message, and the prepare-release PR link

After confirmation:

• Create with gh release create --draft (always --draft)
• Never publish. If the user asks to publish, decline and instruct them to publish manually.

When the user requests revisions after the initial creation, always rewrite the complete body as a file — never perform in-place string replacements. See references/formatting.md.

Edge Cases

• No new PRs since preparation: proceed normally — the prepare-release notes are used as the foundation with no warnings
• New PR introduces breaking changes: strongly recommend aborting and re-running prepare-release; if user chooses to proceed, document the decision and update the breaking changes section
• New PR changes version level: warn that the release tag may not match the expected SemVer level; recommend re-running prepare-release
• Prepare-release PR description is malformed: fall back to gathering all data fresh from the commit range
• PR not found: if the prepare-release PR cannot be identified, offer to proceed manually by specifying a version and target commit
• Draft already exists: if a draft release with the same tag already exists, offer to update it
• PR spans categories: categorize by primary intent
• Copilot timeline missing: fall back to Co-authored-by trailers to determine whether @Copilot should be a co-author; if still unclear, use @Copilot as primary author
• No breaking changes: omit the Breaking Changes section entirely
• Single breaking change: use the same numbered format as multiple

Release Notes Template

Omit empty sections. The preamble is always required — it is not inside a section heading.

[Preamble — REQUIRED. Summarize the release theme.]

## Breaking Changes

Refer to the [C# SDK Versioning](https://csharp.sdk.modelcontextprotocol.io/versioning.html) documentation for details on versioning and breaking change policies.

1. **Description #PR**
   * Detail of the break
   * Migration guidance

## What's Changed

* Description #PR by @author (co-authored by @user1 @Copilot)

## Documentation Updates

* Description #PR by @author (co-authored by @user1 @Copilot)

## Test Improvements

* Description #PR by @author (co-authored by @user1 @Copilot)

## Repository Infrastructure Updates

* Description #PR by @author (co-authored by @user1 @Copilot)

## Acknowledgements

* @user made their first contribution in #PR
* @user submitted issue #1234 (resolved by #5678)
* @user1 @user2 @user3 reviewed pull requests

**Full Changelog**: https://github.com/modelcontextprotocol/csharp-sdk/compare/previous-tag...new-tag