Nuget Manager
Add, remove, or bump NuGet packages in .NET solutions using dotnet CLI rules and a verified restore workflow.
Overview
nuget-manager is an agent skill for the Build phase that manages NuGet packages in .NET projects using dotnet CLI and a strict version-update plus restore workflow.
Install
npx skills add https://github.com/github/awesome-copilot --skill nuget-managerWhat is this skill?
- NEVER hand-edit .csproj/.props to add or remove packages—use dotnet add package and dotnet remove package
- Direct file edits allowed only for changing versions of packages already referenced
- Mandatory version-update workflow: verify on NuGet, locate per-project vs Directory.Packages.props, edit, then dotnet re
- Supports centralized package management via Directory.Packages.props
- Version verification via jq or PowerShell with dotnet package search
- 3 core rules: no direct add/remove edits, version-only direct edits, mandatory verify-edit-restore workflow
Adoption & trust: 11.3k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to change NuGet dependencies but manual csproj edits keep breaking restore or violating central package management.
Who is it for?
Solo builders on .NET 8+ solutions who want enforced CLI usage and safe bumps across csproj or Directory.Packages.props.
Skip if: Node/npm or Python poetry workflows, greenfield repos without the .NET SDK, or teams that insist on editing PackageReference blocks to add new packages by hand.
When should I use this skill?
Adding, removing, or updating NuGet package versions in .NET projects or solutions.
What do I get? / Deliverables
Packages are added or removed via dotnet CLI, versions updated only after NuGet verification, with dotnet restore confirming compatibility.
- Updated PackageReference or central versions with successful dotnet restore
- Documented add/remove operations performed via dotnet CLI
Recommended Skills
Journey fit
Dependency changes belong in Build when you are shaping the .NET codebase that will later ship; this skill is the canonical package-management shelf for that work. Backend subphase covers server-side .NET services and libraries where NuGet versions and central package management directly affect compile and deploy outcomes.
How it compares
Use instead of free-form csproj edits when you want package operations aligned with official dotnet tooling.
Common Questions / FAQ
Who is nuget-manager for?
Indie and solo developers shipping .NET APIs, services, or libraries who delegate package changes to an agent but need guardrails matching Microsoft’s CLI expectations.
When should I use nuget-manager?
During Build backend work when adding integrations, removing unused packages, or pinning/upgrading versions before you run tests or container builds in Ship.
Is nuget-manager safe to install?
It runs dotnet and may edit project files and download packages from NuGet; review the Security Audits panel on this Prism page and commit before bulk version bumps.
SKILL.md
READMESKILL.md - Nuget Manager
# NuGet Manager ## Overview This skill ensures consistent and safe management of NuGet packages across .NET projects. It prioritizes using the `dotnet` CLI to maintain project integrity and enforces a strict verification and restoration workflow for version updates. ## Prerequisites - .NET SDK installed (typically .NET 8.0 SDK or later, or a version compatible with the target solution). - `dotnet` CLI available on your `PATH`. - `jq` (JSON processor) OR PowerShell (for version verification using `dotnet package search`). ## Core Rules 1. **NEVER** directly edit `.csproj`, `.props`, or `Directory.Packages.props` files to **add** or **remove** packages. Always use `dotnet add package` and `dotnet remove package` commands. 2. **DIRECT EDITING** is ONLY permitted for **changing versions** of existing packages. 3. **VERSION UPDATES** must follow the mandatory workflow: - Verify the target version exists on NuGet. - Determine if versions are managed per-project (`.csproj`) or centrally (`Directory.Packages.props`). - Update the version string in the appropriate file. - Immediately run `dotnet restore` to verify compatibility. ## Workflows ### Adding a Package Use `dotnet add [<PROJECT>] package <PACKAGE_NAME> [--version <VERSION>]`. Example: `dotnet add src/MyProject/MyProject.csproj package Newtonsoft.Json` ### Removing a Package Use `dotnet remove [<PROJECT>] package <PACKAGE_NAME>`. Example: `dotnet remove src/MyProject/MyProject.csproj package Newtonsoft.Json` ### Updating Package Versions When updating a version, follow these steps: 1. **Verify Version Existence**: Check if the version exists using the `dotnet package search` command with exact match and JSON formatting. Using `jq`: `dotnet package search <PACKAGE_NAME> --exact-match --format json | jq -e '.searchResult[].packages[] | select(.version == "<VERSION>")'` Using PowerShell: `(dotnet package search <PACKAGE_NAME> --exact-match --format json | ConvertFrom-Json).searchResult.packages | Where-Object { $_.version -eq "<VERSION>" }` 2. **Determine Version Management**: - Search for `Directory.Packages.props` in the solution root. If present, versions should be managed there via `<PackageVersion Include="Package.Name" Version="1.2.3" />`. - If absent, check individual `.csproj` files for `<PackageReference Include="Package.Name" Version="1.2.3" />`. 3. **Apply Changes**: Modify the identified file with the new version string. 4. **Verify Stability**: Run `dotnet restore` on the project or solution. If errors occur, revert the change and investigate. ## Examples ### User: "Add Serilog to the WebApi project" **Action**: Execute `dotnet add src/WebApi/WebApi.csproj package Serilog`. ### User: "Update Newtonsoft.Json to 13.0.3 in the whole solution" **Action**: 1. Verify 13.0.3 exists: `dotnet package search Newtonsoft.Json --exact-match --format json` (and parse output to confirm "13.0.3" is present). 2. Find where it's defined (e.g., `Directory.Packages.props`). 3. Edit the file to update the version. 4. Run `dotnet restore`.