ci: run the Roslyn MCP in the CI @claude agent

[williamdewitt]

Context

We wired dotnet-claude-kit into the repo at repo scope (.claude/settings.json, commit 7300034). Locally the kit's agents, commands, skills, and the 15 Roslyn MCP tools are all live. The CI agent-in-the-loop (.github/workflows/claude.yml) runs in the checked-out repo, so it should inherit the kit's skills/agents/commands for free — but the cwm-roslyn-navigator MCP server needs a .NET runtime to start, which claude.yml does not currently set up.

See docs/design/dotnet-claude-kit-adoption.md → Open items.

Goal

Make the kit — especially the Roslyn MCP tools — available to the @claude agent when it runs in CI, so issue-driven work gets the same navigation/quality tooling we have locally.

Acceptance criteria

• Verify inheritance first. Confirm whether claude-code-action actually picks up the repo's .claude/settings.json (extraKnownMarketplaces + enabledPlugins) in CI — i.e. does the in-CI agent get the kit's skills/agents/commands? Record the finding in the PR description. If it does not, wire the plugin explicitly via the action's inputs instead.
• Add a .NET setup step (actions/setup-dotnet, pinned to global.json) to the claude job, before the Run Claude step, so the cwm-roslyn-navigator MCP server can start.
• Ensure the Roslyn MCP server is available to the in-CI agent (install/restore the cwm-roslyn-navigator tool the way the plugin provides it). Confirm at least one Roslyn tool (e.g. get_project_graph) is callable in a CI run.
• Keep the existing trusted-actor guard, risk:* → model routing, --max-turns cap, and the AGENT_PAT auto-PR step unchanged in behaviour.
• Update docs/design/dotnet-claude-kit-adoption.md (Open items) and docs/design/development-loop.md (step 5) to record the outcome — in the same PR.
• If full MCP-in-CI proves infeasible without disproportionate complexity (e.g. solution-index cold-start cost on every @claude run), document the finding and a recommended deferral in the adoption doc instead of forcing it — a clear "why not yet" is an acceptable outcome.

Definition of done

• claude.yml change merged via the normal gate. This is a .github/workflows/** change → risk:core, CODEOWNERS-reviewed, never auto-merges.
• The adoption + dev-loop docs reflect reality.
• A note in the PR on cold-start cost (the Roslyn MCP indexes the solution) so we can decide whether to gate it behind a label.

Pointers

• .github/workflows/claude.yml — the workflow to change.
• docs/design/dotnet-claude-kit-adoption.md — Open items + the adopt/decline context.
• The kit's MCP config: server id cwm-roslyn-navigator, launched as cwm-roslyn-navigator --solution ${workspaceFolder}.
• global.json — pin setup-dotnet to this.

[claude]

Claude finished @williamdewitt's task in 5m 58s —— View job • claude/issue-29-20260624-1927 • Create PR ➔

---

Roslyn MCP in the CI @claude agent — finding + docs landed

• Gather context (claude.yml, .claude/settings.json, global.json, both design docs, the action's source)
• AC1 — Verify whether the in-CI agent inherits repo-scoped .claude/settings.json plugins → No (confirmed two ways)
• Determine the .NET setup + Roslyn-MCP wiring + cold-start note
• Update docs/design/dotnet-claude-kit-adoption.md (Open items → verified finding)
• Update docs/design/development-loop.md (step 5)
• Push doc changes

AC1 — does the CI agent inherit the repo's plugin config? No.

Two independent, conclusive lines of evidence:

1. Code inspection of anthropics/claude-code-action@v1:
   • setup-claude-code-settings.ts writes ~/.claude/settings.json by merging only the action's settings input (we pass none), then force-sets enableAllProjectMcpServers: true. It never reads the repo's .claude/settings.json.
   • install-plugins.ts is the only code that runs claude plugin marketplace add / install, driven exclusively by the action's plugins / plugin_marketplaces inputs. Both unset → it installs nothing.
2. Empirical, from this @claude run: the job's ~/.claude/settings.json contained exactly {"enableAllProjectMcpServers": true} (the no-input default) — none of the repo's extraKnownMarketplaces / enabledPlugins. Correspondingly zero kit capability was live: no kit agents, none of the 47 skills, none of the 15 cwm-roslyn-navigator MCP tools.

Why: enabledPlugins only enables a plugin from an already-installed marketplace; in a fresh checkout the marketplace was never added. enableAllProjectMcpServers auto-approves project .mcp.json servers, not plugin-provided ones. ⇒ the kit must be wired explicitly via the action's inputs.

What I changed (this PR — docs only)

Recorded the finding, the proposed claude.yml diff, the cold-start analysis, and a recommended rollout in:

• docs/design/dotnet-claude-kit-adoption.md → new "Roslyn MCP (and the whole kit) in CI — verified finding" section (+ corrected the old "reaches the CI agent for free" claim, which was wrong).
• docs/design/development-loop.md → step 5 follow-up note.

Proposed claude.yml change (for a maintainer to apply):

1. actions/setup-dotnet pinned to global.json, before Run Claude (the Roslyn server is a .NET process).
2. On the Run Claude step, add the inputs that actually install the kit:

   plugin_marketplaces: |
     https://github.com/codewithmukesh/dotnet-claude-kit.git
   plugins: |
     dotnet-claude-kit@dotnet-claude-kit

3. Confirm how the plugin provides cwm-roslyn-navigator (bundled binary vs. dotnet tool install -g) and add a restore step if needed. The trusted-actor guard, risk:* → model routing, --max-turns 30, and the AGENT_PAT auto-PR step stay unchanged.

Cold-start cost & recommendation

The Roslyn MCP indexes the whole solution on first use — a per-run cost paid even on a one-line docs PR. That cuts against cost control is gate control. Recommendation: gate the enrichment behind a label (only risk:core/risk:critical, or an explicit opt-in) — the existing route step can emit an enable_roslyn output and pass the plugin inputs conditionally. Always-on is also fine while the solution is tiny; it's a deliberate maintainer call.

Honest limitations

• I cannot apply the claude.yml change. The CI GitHub App token withholds the workflows permission, so a push touching .github/workflows/** is rejected. This PR therefore records the finding + diff; the risk:core workflow edit and the live get_project_graph confirmation are left for a maintainer.
• Could not fetch the plugin repo from inside the CI sandbox (outbound network blocked), so the exact cwm-roslyn-navigator provisioning (bundled vs. global tool) is flagged as a "confirm before applying" step rather than asserted.

Because the change is docs-only, the path classifier will likely mark this PR risk:trivial — the substantive risk:core work is the workflow edit, which is not in this PR.

· branch claude/issue-29-20260624-1927

[williamdewitt]

@claude please pick this up.

Start with acceptance criterion 1: verify whether the in-CI agent actually inherits the repo-scoped .claude/settings.json plugins (skills/agents/commands), and write what you find into the PR description. Then wire the .NET setup + Roslyn MCP server per the criteria, and update both docs in the same PR.

This touches .github/workflows/claude.yml, so it is risk:core — it will not auto-merge; I'll review the PR. If full MCP-in-CI isn't worth the per-run cold-start cost, a documented deferral is a fine outcome.

[williamdewitt]

Update — the cheap half landed (446a5e7 on main).

Split this MLP-style:

✅ Done — kit agents/commands/skills in CI. claude.yml's Run Claude step now passes plugin_marketplaces + plugins, so the in-CI @claude agent installs the dotnet-claude-kit's agents, commands, and skills on every run (a marketplace clone + plugin install of plain-markdown capabilities — no indexing, so it's unconditional, not label-gated). Applied by the maintainer via owner-bypass because the App token lacks workflows permission and can't push .github/workflows/**. Guard / risk:*→model routing / --max-turns / AGENT_PAT auto-PR all unchanged.

⏳ Remaining (this issue stays open) — Roslyn MCP server in CI. The cwm-roslyn-navigator MCP tools are still not wired: that needs actions/setup-dotnet (pinned to global.json), provisioning the tool, and a live get_project_graph confirmation. It pays a per-run whole-solution index cold-start, so when it lands it should be label-gated to risk:core / critical (have the Route step emit an enable_roslyn output and apply the .NET-dependent bits conditionally). On today's M0 one-file shell the index would be near-zero value — hence the deferral.

Full rationale + proposed diff: docs/design/dotnet-claude-kit-adoption.md → "Roslyn MCP (and the whole kit) in CI — verified finding" / "Status / deferral".