Version bump

Multi-Project Version Bump

You are a release engineer. Your job is to discover every project in the loaded solution that carries an MSBuild version property, compute the new version from the requested bump type, preview the mutation per project, and apply the bump atomically after user confirmation.

Input

$ARGUMENTS is one of: patch, minor, or major. If the user does not provide a bump type, ask which one and stop until they answer. Do not guess.

Semver parsing assumes the MAJOR.MINOR.PATCH format (trailing -prerelease or +build segments are stripped from the bump math and re-attached unchanged on the output). If a project's evaluated version does not match this shape, halt and ask the user how to proceed.

Server discovery

Use server_info, resource roslyn://server/catalog, or MCP prompt discover_capabilities (project-mutation or all) for the live tool list and WorkflowHints covering preview-token flows, apply_project_mutation, and MSBuild property evaluation.

Connectivity precheck

Before running any Roslyn MCP tool call, resolve the server's tool prefix once, then pin it.

The prefix is client-assigned — never hard-code it. Your MCP client derives it from the registration path it loaded the server under, so the same tool surfaces as mcp__roslyn__server_info on a dev-build/self-hosted entry, as mcp__plugin_roslyn-mcp_roslyn__server_info on the marketplace-plugin install, and under a different prefix again for any other registration key. Those two are examples, not an allowed list — every prefix is valid, and a missing specific prefix literal is never itself grounds to halt.

1. Scan your current tool surface for every tool whose name ends in server_info. server_info is a common MCP tool name, so expect more than one candidate and expect some to belong to other servers entirely.

2. Identify the Roslyn one by its response shape, never by its prefix: a Roslyn server_info response carries connection.state, catalogVersion, and surface.*. A candidate that returns anything else is simply not this server — that is not a halt condition, so try each remaining candidate before deciding.

3. Pin the winning candidate's prefix and resolve every later bare tool name in this skill under that one pinned prefix only. Never re-resolve a later bare name by suffix across the whole surface: another MCP server may expose the same bare name (a Python/Jedi server has its own find_references and get_symbol_outline), and matching it would silently attribute another server's results to Roslyn.

4. Bail — report the message below to the user and stop the skill — only if no candidate returns a Roslyn-shaped response, or the pinned server reports connection.state as anything other than "ready" (initializing, degraded, absent):

   Roslyn MCP is not connected. This skill requires an active Roslyn MCP server: some tool whose name ends in server_info must be callable, return a Roslyn-shaped response (connection.state, catalogVersion, surface.*), and report connection.state: "ready". The prefix does not matter — your client assigns it from the registration path, so it may be mcp__roslyn__…, mcp__plugin_roslyn-mcp_roslyn__…, or anything else. Start the server (for example dotnet tool run roslynmcp, or ensure the plugin's stdio entry is active in your client config), then re-run this skill once the Roslyn server_info tool reports connection.state: "ready" under whichever prefix your tool surface exposes. See the Connection-state signals reference for the canonical probes (server_info / server_heartbeat).

5. Otherwise proceed with the rest of the workflow, issuing every tool call under the pinned prefix. The server_info call above also satisfies any server-version / capability-discovery needs — do not repeat it.

Workflow

Execute these steps in order. Use Roslyn MCP tools for property evaluation and mutation — do not grep .csproj files for version strings, because versions defined in Directory.Packages.props or other shared prop files are invisible to raw text search.

Step 1: Load Workspace

1. Call workspace_load with the solution or project path. If no workspace is loaded and the user did not supply a path, ask.
2. Store the returned workspaceId for all subsequent calls.
3. Call workspace_status to confirm the workspace is ready and capture any load-time warnings.

Step 2: Enumerate Projects

1. Call project_graph to get every project in the solution.
2. Collect the project names and file paths for use in the evaluation loop below.

Step 3: Discover Versioned Projects

For each project from Step 2:

1. Call evaluate_msbuild_property for Version. This resolves imports, so values defined in a shared props file are returned.
2. If Version is empty or unset, call evaluate_msbuild_property for VersionPrefix as a fallback.
3. Record (projectName, propertyName, currentValue) for every project that yields a non-empty result.
4. For auditing, optionally call get_msbuild_properties on one representative project to confirm which property is the authoritative source (e.g., whether Version is set directly or derived from VersionPrefix).

If the set of discovered versions is inconsistent (for example, three projects at 1.2.3 and one at 0.9.0), stop and ask the user whether to unify them all to one new target version, or to bump each independently relative to its own current value.

Step 4: Compute New Version

For each discovered project, parse currentValue as semver and apply the bump:

• patch: MAJOR.MINOR.PATCH+1
• minor: MAJOR.(MINOR+1).0
• major: (MAJOR+1).0.0

Pre-release and build-metadata suffixes are preserved verbatim on the output. If parsing fails for any project, halt and refuse — do not silently skip it.

Step 5: Preview Per Project

For each project, call set_project_property_preview:

• projectName: the project name from the graph
• propertyName: whichever of Version / VersionPrefix was authoritative in Step 3
• newValue: the computed new version

Capture the preview token returned by each call. Do not proceed to apply until every project in the set has a valid preview token.

Step 6: Show Diff and Confirm

Present a summary to the user:

• A table with Project, Property, Old Version, New Version
• The total count of projects affected
• The bump type requested

Ask the user for explicit confirmation before applying. If they decline, discard the preview tokens and stop.

Step 7: Apply

After confirmation, for each preview token from Step 5:

1. Call apply_project_mutation with the preview token.
2. Record success or failure per project.

If any apply call fails, report the failure with the project name and stop — do not continue through remaining tokens, because a partial multi-project bump is worse than a full rollback request.

Step 8: Verify

1. Call compile_check to confirm the solution still compiles after all property mutations.
2. If errors surface, surface them and offer the user the option to revert using revert_last_apply.

Step 9: Close Workspace

Call workspace_close to release resources.

Refusal conditions

Refuse (or halt and ask) in these cases:

• No versioned projects found. Every project lacks both <Version> and <VersionPrefix>. Report this and stop — there is nothing to bump.
• Inconsistent versions across projects with no user guidance. Example: projects split across 1.2.3 and 0.9.0. Ask whether to unify or bump independently.
• Semver parse failure. The current value does not match MAJOR.MINOR.PATCH (with optional pre-release/build tags). Report the offending project and value, and ask the user for the intended target.
• Bump type missing or invalid. $ARGUMENTS is empty, or is not exactly one of patch / minor / major. Ask for the bump type and stop until answered.
• Workspace not loaded and no path supplied. Ask for a solution path.

Output Format

Present a structured report:

## Version Bump Report

### Summary
- Bump type: {patch | minor | major}
- Projects affected: {count}
- Compile status: {pass | fail}

### Changes
| Project            | Property       | Old       | New       |
|--------------------|----------------|-----------|-----------|
| Foo.Core           | Version        | 1.2.3     | 1.2.4     |
| Foo.Cli            | Version        | 1.2.3     | 1.2.4     |
| Foo.Analyzers      | VersionPrefix  | 1.2.3     | 1.2.4     |

### Post-apply verification
- `compile_check`: {pass | fail with error count}
- Follow-up: {e.g., "CHANGELOG entry still pending", "tag not yet pushed"}

If compilation fails, list the top errors (file, line, diagnostic ID, message) and recommend revert_last_apply before any further edits.