From roslyn-mcp
Multi-project version bump across a .NET solution. Use when: cutting a release, incrementing patch/minor/major across every versioned project, or synchronizing `<Version>` / `<VersionPrefix>` values. Takes a bump type (patch, minor, or major) as input. Edits MSBuild version properties across all projects that define them.
npx claudepluginhub darylmcd/roslyn-backed-mcp --plugin roslyn-mcpThis skill uses the workspace's default tool permissions.
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.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
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.
$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.
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.
Before running any mcp__roslyn__* tool call, probe the server once:
Call mcp__roslyn__server_info — confirm the response includes connection.state: "ready".
If the call fails OR connection.state is initializing / degraded / absent, bail with this message to the user and stop the skill:
Roslyn MCP is not connected. This skill requires an active Roslyn MCP server. Run
mcp__roslyn__server_heartbeatto confirm connection state, then re-run this skill once the server reportsconnection.state: "ready". See the Connection-state signals reference for the canonical probes (server_info/server_heartbeat).
If connection.state is "ready", proceed with the rest of the workflow. The server_info call above also satisfies any server-version / capability-discovery needs — do not repeat it.
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.
workspace_load with the solution or project path. If no workspace is loaded and the user did not supply a path, ask.workspaceId for all subsequent calls.workspace_status to confirm the workspace is ready and capture any load-time warnings.project_graph to get every project in the solution.For each project from Step 2:
evaluate_msbuild_property for Version. This resolves imports, so values defined in a shared props file are returned.Version is empty or unset, call evaluate_msbuild_property for VersionPrefix as a fallback.(projectName, propertyName, currentValue) for every project that yields a non-empty result.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.
For each discovered project, parse currentValue as semver and apply the bump:
patch: MAJOR.MINOR.PATCH+1minor: MAJOR.(MINOR+1).0major: (MAJOR+1).0.0Pre-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.
For each project, call set_project_property_preview:
projectName: the project name from the graphpropertyName: whichever of Version / VersionPrefix was authoritative in Step 3newValue: the computed new versionCapture the preview token returned by each call. Do not proceed to apply until every project in the set has a valid preview token.
Present a summary to the user:
Project, Property, Old Version, New VersionAsk the user for explicit confirmation before applying. If they decline, discard the preview tokens and stop.
After confirmation, for each preview token from Step 5:
apply_project_mutation with the preview token.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.
compile_check to confirm the solution still compiles after all property mutations.revert_last_apply.Call workspace_close to release resources.
Refuse (or halt and ask) in these cases:
<Version> and <VersionPrefix>. Report this and stop — there is nothing to bump.1.2.3 and 0.9.0. Ask whether to unify or bump independently.MAJOR.MINOR.PATCH (with optional pre-release/build tags). Report the offending project and value, and ask the user for the intended target.$ARGUMENTS is empty, or is not exactly one of patch / minor / major. Ask for the bump type and stop until answered.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.