PluginBench
Skill
Pass
Audit score 90

outdated

codewithmukesh/dotnet-claude-kit

Audit .NET NuGet packages for vulnerabilities, staleness, and commercial-license traps.

What is outdated?

Generates a prioritized dependency health report for .NET solutions by inventorying NuGet packages, checking for known CVEs and outdated versions, and flagging packages that moved to commercial licenses. Use it before upgrades, after inheriting codebases, or on a quarterly cadence for long-lived projects.

  • Inventories all PackageReference entries per project with target frameworks and central package management awareness
  • Detects outdated packages and known CVEs via dotnet CLI
  • Screens for commercial-license traps (MediatR, MassTransit, FluentAssertions, AutoMapper) that naive upgrades could trigger
  • Produces a single prioritized table ordered by vulnerability, license risk, then staleness
  • Flags mixed target frameworks across projects and CPM configuration issues

How to install outdated

npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill outdated
Prerequisites
  • A .NET solution with restorable packages (dotnet restore must succeed)
  • Access to the get_nuget_packages MCP tool
  • dotnet CLI installed and in PATH
Claude Code
Cursor
Windsurf
Cline

How to use outdated

  1. 1.Run get_nuget_packages() to inventory all packages and detect CPM usage
  2. 2.Execute dotnet list package --outdated to check for staleness
  3. 3.Execute dotnet list package --vulnerable --include-transitive to detect CVEs
  4. 4.Cross-reference the inventory against known commercial-license moves (MediatR 13+, MassTransit 9+, FluentAssertions 8+, AutoMapper 15+)
  5. 5.Review the prioritized report table and decide per-package actions (update now, pin, or plan migration)

Use cases

Good for
  • Audit dependencies before a .NET version upgrade
  • Review package health after inheriting an unfamiliar codebase
  • Respond to Dependabot or NuGet audit warnings with full context
  • Quarterly dependency review on long-lived projects
  • Verify no silent legal-position changes from routine package updates
Who it's for
  • Backend engineers maintaining .NET solutions
  • Tech leads reviewing codebase health before major upgrades
  • Teams using central package management (Directory.Packages.props)
  • Projects with strict licensing compliance requirements

outdated FAQ

Why does this skill care about commercial licenses?

A naive dotnet outdated --upgrade can silently move a project from a free license (Apache, MIT) to a commercial one (Lucky Penny, RPL) without warning. This skill flags that boundary so you can decide intentionally.

What if dotnet list package fails?

The solution likely has a broken restore state. Fix that first (missing dependencies, network issues, or lock-file corruption) before auditing — version output is unreliable otherwise.

Should I batch major version updates together?

No. Apply major updates one at a time with dotnet build && dotnet test between each. Batched failures are unattributable and harder to debug.

What are the priority levels in the report?

VULNERABLE (known CVE, update now), LICENSE (next major crosses commercial boundary, pin or migrate), MAJOR (breaking changes likely, one at a time), MINOR/PATCH (routine drift, can batch patches).

Can this skill apply the updates automatically?

It recommends actions and can offer to execute updates via the /migrate Flow C, which applies them one package at a time with testing between each.

Full instructions (SKILL.md)

Source of truth, from codewithmukesh/dotnet-claude-kit.


name: outdated description: > Dependency health report for .NET solutions: outdated NuGet packages, vulnerable versions, and commercial-license traps (MediatR, MassTransit, FluentAssertions, AutoMapper) — powered by the get_nuget_packages MCP tool. Invoke when: "outdated packages", "check dependencies", "stale packages", "package audit", "dependency health", "are my packages up to date", "license check", "vulnerable packages", "nuget audit".

/outdated

What

A three-layer dependency health report:

  1. Inventory — every PackageReference per project, with TFMs and central package management awareness, via the get_nuget_packages MCP tool (no network, token-cheap).
  2. Staleness + vulnerabilities — current vs latest stable, and known CVEs, via the dotnet CLI.
  3. License screen — flags packages that moved to commercial licenses so an innocent dotnet outdated --upgrade doesn't silently change your legal position.

The output is a single prioritized table — vulnerabilities first, license traps second, staleness last — with a recommended action per row.

When

  • "check for outdated packages", "package audit", "dependency health"
  • Before a .NET version upgrade (pairs with /migrate Flow B)
  • After inheriting an unfamiliar codebase
  • Dependabot/NuGet audit warnings appeared and you want the full picture
  • Periodically on long-lived projects — quarterly is a good cadence

How

Step 1: Inventory (MCP, no network)

get_nuget_packages()                          -- whole solution
get_nuget_packages(projectFilter: "Api")      -- or one project

Returns per-project {Name, TargetFramework, Cpm, Packages: [{Id, Version}]}. Note Cpm: true — updates then belong in Directory.Packages.props, not the csproj. Flag mixed TFMs across projects while you're here.

Step 2: Staleness and vulnerabilities (CLI)

dotnet list package --outdated
dotnet list package --vulnerable --include-transitive

Both need a successful restore first. If restore fails, fix that before auditing — a broken lock state makes version output unreliable.

Step 3: License screen

Check the inventory against the known commercial moves (full rationale in knowledge/package-recommendations.md):

PackageCommercial fromFree alternative
MediatR13+ (Lucky Penny, RPL)Mediator (martinothamar) — source-generated, MIT
MassTransit9+ (v8 Apache, patches end 2026 then EOL)Wolverine 6.x, or stay on v8 short-term
FluentAssertions8+ (v7 stays Apache, frozen)xUnit built-in Assert (kit default), Shouldly, AwesomeAssertions
AutoMapper15+ (Lucky Penny)Manual mapping (kit default) or Mapperly (MIT)

A license flag fires when the project is on the free major and a naive "update all" would cross the boundary — that is the trap this step exists for.

Step 4: Report

One table, priority-ordered:

PriorityMeaningAction
VULNERABLEKnown CVE in current versionUpdate now, test, deploy
LICENSENext major crosses a commercial boundaryPin below boundary or plan migration
MAJORBehind a major (breaking changes likely)One at a time, release notes first
MINOR/PATCHRoutine driftBatch patches; minors one at a time

Step 5: Act (optional)

Offer to execute updates via /migrate Flow C — one package at a time, dotnet build && dotnet test between each. Never batch major updates: batched failures are unattributable.

MCP Tools Used

  • get_nuget_packages — inventory, CPM detection, TFM audit
  • get_diagnostics — verify the solution still compiles clean after updates

Example

User: /outdated

Claude: Inventorying packages (get_nuget_packages)...
  3 projects, CPM enabled (Directory.Packages.props), all net10.0.

  Checking versions and CVEs...

  | Package                  | Current | Latest  | Priority   | Action                          |
  |--------------------------|---------|---------|------------|---------------------------------|
  | System.Text.Json (trans.)| 10.0.2  | 10.0.10 | VULNERABLE | Update now (CVE-2026-XXXX)      |
  | MassTransit              | 8.3.0   | 9.1.2   | LICENSE    | v9 is commercial. Stay on v8    |
  |                          |         |         |            | (EOL end 2026) or plan Wolverine|
  | Serilog.AspNetCore       | 9.0.0   | 10.0.0  | MAJOR      | Update alone, check sink compat |
  | FluentValidation         | 12.0.1  | 12.1.1  | PATCH      | Batch with other patches        |

  1 vulnerability, 1 license trap, 1 major, 1 patch.
  Want me to apply these via /migrate Flow C?

Related

  • /migrate — Flow C executes the updates this report recommends
  • knowledge/package-recommendations.md — vetted packages + licensing detail
  • knowledge/mediatr-to-mediator-migration.md — step-by-step MediatR exit
  • /verify — full pipeline after applying updates