Agent-Skills.md

Agent Skills: dotnet-centralise-packages

Converts a .NET solution to use Central Package Management (CPM). Also use when the user mentions "centralize packages," "CPM," "Directory.Packages.props," "unify package versions," "consolidate NuGet," or "central package management." For updating package versions, see dotnet-update-packages.

UncategorizedID: Im5tu/claude/dotnet-centralise-packages

Repository

Im5tu/claude
Im5tuLicense: MIT

Install this agent skill to your local

pnpm dlx add-skill https://github.com/Im5tu/claude/tree/HEAD/skills/dotnet-centralise-packages

Skill Files

Browse the full folder contents for dotnet-centralise-packages.

Download Skill

Loading file tree…

skills/dotnet-centralise-packages/SKILL.md

Skill Metadata

Name
dotnet-centralise-packages
Description
Converts a .NET solution to use Central Package Management (CPM). Also use when the user mentions "centralize packages," "CPM," "Directory.Packages.props," "unify package versions," "consolidate NuGet," or "central package management." For updating package versions, see dotnet-update-packages.

Convert the current .NET solution to use Central Package Management, centralizing all package versions in a single Directory.Packages.props file.

Steps

  1. Find the solution file (*.sln) in the current directory

    • If no .sln found, warn and stop

  2. List all packages (including transitive)

    dotnet package list --include-transitive --format json

  3. Parse JSON output to extract:

    • All unique packages across all projects
    • Their versions
    • Whether each package is direct or transitive
    • If same package has different versions, use the highest version

  4. Check for existing CPM files

    • If Directory.Packages.props exists, ask user: overwrite or merge
    • Note existing Directory.Build.props content if present

  5. Create Directory.Packages.props next to the .sln file:

    <Project>
  <ItemGroup>
    <PackageVersion Include="PackageName" Version="X.Y.Z" />
    <!-- one entry per unique package -->
  </ItemGroup>
</Project>

  6. Create or update Directory.Build.props next to the .sln file:

    • If file exists, add the property to existing content
    • If file doesn't exist, create it:
    <Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
</Project>

  7. Update all .csproj files:

    • Remove Version attribute from all <PackageReference> elements
    • Before: <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
    • After: <PackageReference Include="Newtonsoft.Json" />

  8. Run build to verify:

    dotnet build

  9. If build fails, ask the user:

    • Fix automatically: Review errors and attempt fixes
    • Fix manually: Show errors and let user handle

  10. Report results:

    • List all created/modified files
    • Show package count centralized
    • Confirm build status

Transitive vs Direct Packages

  • Direct packages: Explicitly in csproj via <PackageReference>. These get centralized.
  • Transitive packages: Pulled in as dependencies. Generally NOT centralized unless:
    • User explicitly wants to pin a transitive package version
    • A transitive package needs a security update

When centralizing:

  • Only add direct packages to Directory.Packages.props by default
  • Report transitive packages separately for awareness
  • If user wants to pin a transitive, add it as a <PackageVersion> entry

Version Conflict Resolution

When the same package has different versions across projects:

  • Automatically use the highest/latest version
  • No user prompt needed

Error Handling

  • If no .sln found: warn about solution-level CPM requirement
  • If Directory.Packages.props already exists: ask to overwrite or merge
  • If build fails after conversion: offer automatic fix or manual intervention