toolchain: dotnet.md references dotnet-msbuild:* plugin skills that do not exist in this marketplace

[kyle-sexton]

Plugin: toolchain · Category: cross-plugin coupling (1/2)
Source: work-readiness sweep (read-only audit vs docs/PLUGIN-PHILOSOPHY.md + docs/MIGRATION-PLAYBOOK.md)

Findings

• plugins/toolchain/skills/check/context/dotnet.md:72-76 — "Marketplace plugin skills for build diagnostics (invoke only when installed)" listing dotnet-msbuild:build-perf-diagnostics, dotnet-msbuild:binlog-failure-analysis, etc.

Why flagged

The references are correctly presence-gated ("invoke only when installed") and degrade to prose — that part is compliant. However, verified during this sweep: no dotnet-* plugin exists in this marketplace (no plugins/dotnet* directory, no marketplace.json entry). The references point at plugins a consumer of this marketplace can never install, so the gate can never open. Either the plugins live in another (private/planned) marketplace — in which case the provenance should be stated — or the refs are stale.

Related: implementation has the same pattern (see the .NET-only marketplace-skill refs issue for that plugin).

Fix direction

Either add/publish the referenced plugins, note the external marketplace they come from, or replace the tool-specific names with capability descriptions resolved from what is actually installed.

[kyle-sexton]

This was generated by AI during triage.

Triage → needs-human. The fix is a 3-way choice: (a) publish the dotnet-* plugins, (b) declare the external/private marketplace they come from, or (c) replace the tool-specific skill names with capability descriptions resolved from what's installed. Which is correct depends on product intent not derivable from the codebase (confirmed absent: no plugins/dotnet* dir, no marketplace.json entry). Human decision required. Priority: high (north-star cross-plugin coupling on a priority plugin). Same pattern flagged in implementation.

[kyle-sexton]

Maintainer answer (2026-07-19; relayed by planning session) — the dotnet-*/cloudflare references are FORWARD references to planned plugins, not stale. .NET is the maintainer's primary application stack (day job: .NET 10, Azure, Pulumi, Duende IdentityServer, SQL Server, Azure Service Bus, Blazor UIs), so dotnet-* tooling plugins are intended future work.

Disposition for the reference-hygiene issues (#405, #412, #422): treat every dotnet-*/cloudflare plugin reference as an OPTIONAL forward dependency — presence-gate it ("when installed, use X; otherwise the generic path") and keep the generic path first-class. No reference removal; no unguarded reference survives.

[kyle-sexton]

This was generated by AI during triage. · Category: cross-plugin coupling · Priority: priority: high (toolchain is north-star). Self-labeled severity: low (refs are already gated + degrade to prose). Routed status: ready.

Plan (1 surface)

toolchain check's dotnet.md lists dotnet-msbuild:* build-diagnostics skills that are correctly presence-gated ("invoke only when installed") — but no dotnet-* plugin exists in this marketplace (no plugins/dotnet*, no marketplace.json entry), so the gate can never open. #501 confirms these are forward references to a planned .NET plugin family, not stale.

Fix: add explicit provenance so the refs read as anticipated rather than dangling — note in dotnet.md that these anticipate the planned dotnet-* family (#501) and, until it ships, the section falls back to the project's own build-diagnostics tooling. Optionally capability-name the section (e.g. "build-failure / perf diagnostics") and resolve the concrete skill from what is installed, consistent with the agnosticism contract.

Acceptance

• dotnet.md's dotnet-msbuild:* references carry a provenance note (forward ref to roadmap: dotnet plugin family (dotnet-msbuild, dotnet-test, …) — first-class .NET toolchain support #501) and a stack-neutral fallback so a marketplace consumer isn't pointed at an uninstallable plugin with no signal.

Decision defaulted: annotate as forward references to the #501 family + add a stack-neutral fallback, rather than deleting the anticipatory refs — veto before merge