Revise release process to use Copilot CLI release-notes skill

Update the release process documentation to direct maintainers to use the
Copilot CLI release-notes skill for preparing releases instead of manually
drafting release notes through GitHub.com. This change was made as part of
using the new skill to rewrite all past release notes to follow the
standardized template with proper categorization, acknowledgements, and
formatting.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: jeffhandley

.github/skills/breaking-changes/references/classification.md

@@ -49,6 +49,17 @@ Behavioral changes that customers would have reasonably depended on. **Flag and
 ### Bucket 3: Unlikely Grey Area
 Behavioral changes that customers could have depended on but probably wouldn't (e.g., corner case corrections). **Flag with lower confidence.**
 
+### Bug Fixes (Exclude)
+Changes that correct incorrect behavior, fix spec compliance, or address security issues are **not breaking changes** even if they alter observable behavior. Examples:
+- Fixing encoding to match a specification requirement
+- Correcting a logger category or metric name that was wrong
+- Fixing exception message leaks that were a security concern
+- Moving data to the correct location per protocol spec evolution
+- Setting a flag that should have been set automatically (e.g., `IsError` for error content)
+- Returning a more specific/informative exception for better diagnostics
+
+If a change is primarily a bug fix or spec compliance correction, exclude it from the breaking changes list even though the observable behavior changes.
+
 ### Bucket 4: Clearly Non-Public
 Changes to internal surface or behavior (e.g., internal APIs, private reflection). **Generally not flagged** unless they could affect ecosystem tools.
 

.github/skills/release-notes/SKILL.md

@@ -52,7 +52,12 @@ Sort every PR into one of three categories. See [references/categorization.md](r
 
 ### Step 3: Breaking Change Audit
 
-Invoke the **breaking-changes** skill with the commit range from the previous release tag to the target commit. That skill handles the full audit — examining every PR, assessing impact, reconciling labels, and getting user confirmation.
+Invoke the **breaking-changes** skill with the commit range from the previous release tag to the target commit. The full audit process applies whether creating new release notes or editing existing ones — examine every PR, assess impact, reconcile labels (offering to add/remove labels and comment on PRs), and get user confirmation.
+
+When **editing an existing release**, also extract any breaking changes already documented in the current release notes (`## Breaking Changes` section). These must be preserved — never remove breaking changes from existing notes. Reconcile the existing documented breaks with the audit results:
+- **Previously documented breaks**: keep them, updating formatting if needed
+- **Newly discovered breaks**: add them alongside the existing ones
+- **Audit finds no issue with a documented break**: still keep it (do not remove without explicit user request)
 
 Use the results (confirmed breaking changes with impact ordering and detail bullets) in the remaining steps.
 
@@ -82,12 +87,12 @@ Reviewers go on a single bullet, sorted by number of PRs reviewed (most first),
 
 ### Step 6: Preamble
 
-Compose a short preamble summarizing the release theme.
+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.
 
-- **New release**: Draft a preamble based on the categorized changes. If there are breaking changes, mention them and link to the [C# SDK Versioning](https://modelcontextprotocol.github.io/csharp-sdk/versioning.html) docs.
+- **New release**: Draft a preamble based on the categorized changes.
 - **Editing an existing release**: Extract the current preamble from the release body (text before the first `##` heading) and present it alongside a newly drafted alternative.
 
-Present the options and let the user choose one, edit one, or enter their own text or markdown. Do not repeat preamble text under the Breaking Changes heading.
+Present the options and let the user choose one, edit one, or enter their own text or markdown.
 
 ### Step 7: Final Assembly
 
@@ -121,18 +126,20 @@ After the draft release is created or updated, inform the user that the draft re
 - **PR spans categories**: categorize by primary intent
 - **Copilot timeline missing**: fall back to `Co-authored-by` trailers; if still unclear, use `@Copilot` as primary author
 - **Draft tag changes**: re-fetch the tag before each `gh release edit`
-- **No breaking changes**: omit the Breaking Changes section and breaking change preamble language
+- **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:
+Omit empty sections. The preamble is **always required** — it is not inside a section heading.
 
 ```markdown
-[Preamble — release theme, breaking changes note, versioning docs link]
+[Preamble — REQUIRED. Summarize the release theme.]
 
 ## Breaking Changes
 
+Refer to the [C# SDK Versioning](https://modelcontextprotocol.github.io/csharp-sdk/versioning.html) documentation for details on versioning and breaking change policies.
+
 1. **Description #PR**
    * Detail of the break
    * Migration guidance
@@ -159,5 +166,5 @@ Omit empty sections:
 * @user submitted issue #1234 (resolved by #5678)
 * @user1 @user2 @user3 reviewed pull requests
 
-**Full Changelog**: previous-tag...new-tag
+**Full Changelog**: https://github.com/modelcontextprotocol/csharp-sdk/compare/previous-tag...new-tag
 ```

.github/skills/release-notes/references/categorization.md

@@ -59,6 +59,11 @@ For Dependabot PRs, do not acknowledge @dependabot[bot]:
 * Bump actions/checkout from 5.0.0 to 6.0.0 #1234
 ```
 
+For direct commits without an associated PR (e.g., version bumps merged directly to the branch), use the commit description and `by @author` but omit the `#PR` reference:
+```
+* Bump version to v0.1.0-preview.12 by @halter73
+```
+
 For Copilot-authored PRs, identify who triggered Copilot using the `copilot_work_started` timeline event on the PR. That person becomes the primary author, and @Copilot becomes a co-author:
 ```
 * Add trace-level logging for JSON-RPC payloads #1234 by @halter73 (co-authored by @Copilot)

.github/skills/release-notes/references/formatting.md

@@ -11,6 +11,12 @@ GitHub automatically links `@username`, `#123`, and `@org/repo#123` references i
 
 This keeps the markdown source readable and avoids brittle links.
 
+**Exception — Full Changelog link**: The `**Full Changelog**` compare link at the bottom of the release notes does **not** auto-link. It must use the full URL format:
+```
+**Full Changelog**: https://github.com/modelcontextprotocol/csharp-sdk/compare/previous-tag...new-tag
+```
+A bare `previous-tag...new-tag` will render as plain text, not a clickable link.
+
 ## Writing the Release Body
 
 Always compose the full release body as a complete markdown file before uploading. Never perform incremental string replacements on the body through shell commands or API calls — this risks collapsing newlines, introducing encoding artifacts, or corrupting the markdown structure.
@@ -20,10 +26,12 @@ Always compose the full release body as a complete markdown file before uploadin
 When the user requests changes to existing release notes:
 
 1. Fetch the current release body and save it to a local file
-2. Write the **entire** corrected body to a separate local file (ensuring proper line breaks between all sections, entries, and paragraphs)
-3. **If the release is already published** (not a draft): run `git diff --no-index` between the original and updated files and present the raw diff output directly in the response as a fenced code block with `diff` syntax highlighting. Do not summarize or paraphrase the diff. Require explicit confirmation before uploading. Before uploading, offer to save the original body to a permanent local file, noting that GitHub does not retain prior versions of release notes.
-4. Upload the complete file using `gh release edit --notes-file <file>`
-5. Verify the result by fetching the body again and checking that line count and structure are intact
+2. **Breaking change audit**: Run the full breaking-changes skill audit on the commit range, just as for new release notes — this includes examining PRs, reconciling labels, offering to comment on PRs, and getting user confirmation. Also extract any breaking changes already documented in the existing release body; these must be preserved and reconciled with the audit results.
+3. **Preamble check**: Verify the release has a preamble (text before the first `##` heading). If missing, compose one. The versioning documentation link belongs under the `## Breaking Changes` heading, not in the preamble.
+4. Write the **entire** corrected body to a separate local file (ensuring proper line breaks between all sections, entries, and paragraphs)
+5. Run `git diff --no-index` between the original and updated files and **always** present the raw diff output directly in the response as a fenced code block with `diff` syntax highlighting. Do not summarize or paraphrase the diff — always show the complete diff to the user. Require explicit confirmation before uploading. For published releases (not drafts), also offer to save the original body to a permanent local file, noting that GitHub does not retain prior versions of release notes.
+6. Upload the complete file using `gh release edit --notes-file <file>`
+7. Verify the result by fetching the body again and checking that line count and structure are intact
 
 ### Common Pitfalls
 
@@ -37,6 +45,8 @@ When the user requests changes to existing release notes:
 
 After every release body update:
 
+- [ ] Preamble exists before the first `##` heading
+- [ ] If `## Breaking Changes` section exists, it begins with the versioning docs link paragraph before the numbered list
 - [ ] Line count matches expected structure (~80+ lines for a typical release)
 - [ ] Section headings (`## Breaking Changes`, `## What's Changed`, etc.) each appear on their own line
 - [ ] Bullet entries are each on their own line

.github/workflows/release.md

@@ -7,24 +7,13 @@ The following process is used when publishing new releases to NuGet.org:
     - Once the state of the branch is known to be good, a release can proceed
     - **The release workflow _does not_ run tests**
 
-2. **Create a new Release in GitHub**
-    - Use the link on the repo home page to [Create a new release](https://github.com/modelcontextprotocol/csharp-sdk/releases/new)
-    - Click the 'Choose a tag' dropdown button
-        - Type the name using the `v{major}.{minor}.{patch}-{suffix}` pattern
-        - Click 'Create new tag: ... on publish'
-    - Click the 'Target' dropdown button
-        - Choose the 'Recent Commits' tab
-        - Select the commit to use for the release, ensuring it's one from above where CI is known to be green
-    - The 'Previous tag' dropdown can remain on 'Auto' unless the previous release deviated from this process
-    - Click the 'Generate release notes button'
-        - This will add release notes into the Release description
-        - The generated release notes include what has changed and the list of new contributors
-    - Verify the Release title
-        - It will be populated to match the tag name to be created
-        - This should be retained, using the release title format matching the `v{major}.{minor}.{patch}-{suffix}` format
-    - Augment the Release description as desired
-        - This content is presented used on GitHub and is not persisted into any artifacts
-    - Check the 'Set as a pre-release' button under the release description if appropriate
+2. **Prepare release notes using Copilot CLI**
+    - From a local clone of the repository, use Copilot CLI to invoke the `release-notes` skill
+    - Provide the target commit (SHA, branch, or tag) when prompted, ensuring it's one from above where CI is known to be green
+    - The skill will determine the version from `src/Directory.Build.props`, gather PRs, categorize changes, audit breaking changes, identify acknowledgements, and create a **draft** GitHub release
+    - Review each section as the skill presents it and confirm or adjust as needed
+    - After the draft release is created, review it on GitHub
+    - Check the 'Set as a pre-release' checkbox if appropriate
     - Click 'Publish release'
 
 3. **Monitor the Release workflow**
@@ -33,4 +22,5 @@ The following process is used when publishing new releases to NuGet.org:
     - Verify the package version becomes listed on at [https://nuget.org/packages/ModelContextProtocol](https://www.nuget.org/packages/ModelContextProtocol)
 
 4. **Update the source to increment the version number**
-    - Immediately after publishing a new release, the [`/src/Directory.Build.Props`](../../src/Directory.Build.props) file needs to be updated to bump the version to the next expected release version
+    - The `release-notes` skill will offer to invoke the `bump-version` skill to create a pull request bumping the version
+    - Alternatively, manually update [`/src/Directory.Build.Props`](../../src/Directory.Build.props) to bump the version to the next expected release version