Simplify SemVer assessment: remove prerelease material, streamline criteria

- Remove all prerelease/preview version references from skill docs
- Consolidate MINOR criteria to 'Any new public APIs' instead of enumerating
  specific kinds (types, methods, properties, events, overloads, extensions)
- Make PATCH the catch-all ('Everything Else') instead of qualifying what it includes
- Remove prerelease suffix handling from version computation examples

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

Author: jeffhandley

.github/skills/bump-version/SKILL.md

@@ -16,9 +16,8 @@ Assess and bump the SDK version in `src/Directory.Build.props` to prepare for th
 
 Read `src/Directory.Build.props` on the default branch and extract:
 - `<VersionPrefix>` — the `MAJOR.MINOR.PATCH` version
-- `<VersionSuffix>` — the prerelease suffix (e.g. `preview.1`), if present
 
-Display the current version to the user: `{VersionPrefix}-{VersionSuffix}` or `{VersionPrefix}` if no suffix.
+Display the current version to the user.
 
 Determine the previous release tag from `gh release list` (most recent **published** release). Draft releases must be ignored — they represent a pending release that has not yet shipped. Use `--exclude-drafts` or filter to only published releases when querying.
 
@@ -33,30 +32,28 @@ When context about queued changes is available or can be gathered, assess the ve
 1. Get the list of PRs merged between the previous release tag and the target commit (typically HEAD).
 2. Classify the release level:
    - **MAJOR** — if any confirmed breaking changes (API or behavioral), excluding `[Experimental]` APIs
-   - **MINOR** — if new public API surface, features, or obsoletion warnings are present
-   - **PATCH** — if only backward-compatible bug fixes, documentation, tests, or infrastructure changes
-3. Compute the recommended version from the previous release tag (see the assessment guide for increment rules and pre-release suffix handling).
+   - **MINOR** — if new public APIs, features, or obsoletion warnings are present
+   - **PATCH** — otherwise
+3. Compute the recommended version from the previous release tag (see the assessment guide for increment rules).
 4. Compare against the current version in `Directory.Build.props` and flag any discrepancy.
 5. Present the assessment with a summary table and rationale, then get user confirmation.
 
 #### Default Suggestion (Fallback)
 
-When a quick bump is needed without full change analysis, suggest the next **minor** version with the same suffix pattern:
+When a quick bump is needed without full change analysis, suggest the next **minor** version:
 
-- Current `0.9.0` with suffix `preview.1` → suggest `0.10.0-preview.1`
-- Current `1.0.0` with no suffix → suggest `1.1.0`
-- Current `1.2.3` with suffix `rc.1` → suggest `1.3.0-rc.1`
+- Current `1.0.0` → suggest `1.1.0`
+- Current `1.2.3` → suggest `1.3.0`
 
 Present the suggestion and let the user confirm or provide an alternative.
 
-In either case, parse the confirmed version into its `VersionPrefix` and `VersionSuffix` components.
+Parse the confirmed version into its `VersionPrefix` component.
 
 ### Step 3: Create Pull Request
 
-1. Create a new branch named `bump-version-to-{version}` (e.g. `bump-version-to-0.10.0-preview.1`) from the default branch
+1. Create a new branch named `bump-version-to-{version}` (e.g. `bump-version-to-1.1.0`) from the default branch
 2. Update `src/Directory.Build.props`:
-   - Set `<VersionPrefix>` to the new prefix
-   - Set `<VersionSuffix>` to the new suffix, or remove the element if there is no suffix
+   - Set `<VersionPrefix>` to the new version
    - Update `<PackageValidationBaselineVersion>` if the MAJOR version has changed
 3. Commit with message: `Bump version to {version}`
 4. Push the branch and create a pull request:

.github/skills/bump-version/references/semver-assessment.md

@@ -37,38 +37,24 @@ Recommend a MAJOR version increment if **any** of the following are present:
 
 Recommend a MINOR version increment if no MAJOR criteria are met but **any** of the following are present:
 
-- New public types, methods, properties, or events
-- New overloads or extension methods
-- New configuration options or parameters with default values
+- Any new public APIs
 - New MCP capabilities or protocol features
 - Addition of `[Obsolete]` attributes producing build warnings (step 1 of obsoletion lifecycle)
-- Addition of `[Experimental]` attributes on new APIs
-- New interfaces implemented by existing types
-- Performance improvements that introduce new API surface
 - Changes to `[Experimental]` APIs (regardless of whether they would be breaking outside the experimental surface)
 
-### PATCH — Backward-Compatible Bug Fixes Only
+### PATCH — Everything Else
 
-Recommend a PATCH version increment if no MAJOR or MINOR criteria are met. PATCH-level changes include:
-
-- Bug fixes that correct incorrect behavior
-- Spec compliance corrections
-- Security fixes
-- Performance improvements with no API surface changes
-- Documentation changes (XML doc comments shipped in packages)
-- Test-only changes (no impact on shipped packages)
-- Infrastructure-only changes (CI, build system, dependencies)
+Recommend a PATCH version increment if no MAJOR or MINOR criteria are met.
 
 **Note**: Releases that contain _only_ documentation, test, or infrastructure changes may not warrant a release at all. Flag this to the user if no shipped-package changes are present.
 
 ## Computing the Recommended Version
 
-1. Parse the previous release tag to extract `MAJOR.MINOR.PATCH` and any pre-release suffix.
+1. Parse the previous release tag to extract `MAJOR.MINOR.PATCH`.
 2. Apply the assessed level:
    - MAJOR: `(MAJOR+1).0.0`
    - MINOR: `MAJOR.(MINOR+1).0`
    - PATCH: `MAJOR.MINOR.(PATCH+1)`
-3. If the previous release had a pre-release suffix, carry the same suffix pattern forward (e.g., `-preview.1`).
 
 **Examples** from previous release `v1.2.0`:
 
@@ -78,14 +64,6 @@ Recommend a PATCH version increment if no MAJOR or MINOR criteria are met. PATCH
 | MINOR | `v1.3.0` |
 | MAJOR | `v2.0.0` |
 
-**Examples** from previous release `v1.0.0-preview.1`:
-
-| Level | Recommended |
-|-------|-------------|
-| PATCH | `v1.0.1-preview.1` |
-| MINOR | `v1.1.0-preview.1` |
-| MAJOR | `v2.0.0-preview.1` |
-
 ## Comparing Against the Candidate Version
 
 After computing the recommended version:

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

@@ -25,7 +25,7 @@ The user may provide:
 Once the target is established:
 1. Determine the previous release tag from `gh release list` (most recent **published** release — exclude drafts with `--exclude-drafts`).
 2. Get the full list of PRs merged between the previous release tag and the target commit.
-3. Read `src/Directory.Build.props` **at the target commit**. Extract `<VersionPrefix>` and `<VersionSuffix>` as the **candidate version**.
+3. Read `src/Directory.Build.props` **at the target commit**. Extract `<VersionPrefix>` as the **candidate version**.
 
 ### Step 2: Categorize and Attribute
 
@@ -62,11 +62,10 @@ Using the categorized PRs from Step 2 and confirmed breaking changes from Step 3
 
 1. **Classify the release level**:
    - **MAJOR** — if any confirmed breaking changes are present (API or behavioral), excluding changes to `[Experimental]` APIs
-   - **MINOR** — if no breaking changes but new public API surface, features, or obsoletion warnings are introduced
-   - **PATCH** — if only backward-compatible bug fixes, documentation, tests, or infrastructure changes are included
+   - **MINOR** — if no breaking changes but new public APIs, features, or obsoletion warnings are introduced
+   - **PATCH** — otherwise
 2. **Compute the recommended version** from the previous release tag:
    - Increment the appropriate component (MAJOR resets MINOR.PATCH to 0; MINOR resets PATCH to 0)
-   - Carry forward any pre-release suffix pattern from the previous release (e.g., `-preview.1`)
 3. **Compare against the candidate version** from `src/Directory.Build.props`. Flag any discrepancy:
    - **Under-versioned**: The candidate is lower than the recommended level. This is a concern that should be resolved.
    - **Over-versioned**: The candidate is higher than strictly required. This is acceptable under SemVer but worth noting.
@@ -79,8 +78,7 @@ After the version is confirmed:
 
 1. Create a local branch named `release-{version}` from the target commit (e.g., `release-1.1.0`).
 2. Update `src/Directory.Build.props`:
-   - Set `<VersionPrefix>` to the confirmed version prefix
-   - Set or remove `<VersionSuffix>` as appropriate
+   - Set `<VersionPrefix>` to the confirmed version
    - Update `<PackageValidationBaselineVersion>` if the MAJOR version has changed (set to the previous release version)
 3. Build the solution to verify the version change compiles: `dotnet build`
 

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

@@ -28,7 +28,7 @@ Verify the PR is merged. Extract:
 
 ### Step 2: Determine Version and Commit Range
 
-1. Read `src/Directory.Build.props` at the merge commit to confirm `<VersionPrefix>` and `<VersionSuffix>`. The tag is `v{VersionPrefix}-{VersionSuffix}`, or `v{VersionPrefix}` if no suffix. Pre-release if `VersionSuffix` is present.
+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.
 
@@ -109,7 +109,6 @@ Follow [references/formatting.md](references/formatting.md) when composing and u
 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
-- **Pre-release**: yes/no (based on `VersionSuffix`)
 
 After confirmation:
 - Create with `gh release create --draft` (always `--draft`)