Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dotnet/nuget-trusted-publishing
Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.
Passed 19 of 22 test cases with the skill, and 12 of 22 without it.
and 8 more in the full report
8 fixed11 passed either way2 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
On nuget.org trusted publishing setup, it asks for Workflow File. Our GitHub Actions workflow starts with 'name: Build and Deploy NuGet Package' and is stored at .github/workflows/deploy-nuget.yml. Should I enter 'Build and Deploy NuGet Package' or '.github/workflows/deploy-nuget.yml' into the Workflow File field?
| Checked | Without skill | With skill |
|---|---|---|
| Advises entering deploy-nuget.yml as the Workflow File on nuget.org. | Passed | Passed |
| Explicitly directs omitting the .github/workflows/ path prefix from the Workflow File entry. | Missed | Passed |
The instructions your model reads when the skill loads.
Set up NuGet trusted publishing on a GitHub Actions repo. Replaces long-lived API keys with OIDC-based short-lived tokens — no secrets to rotate or leak.
Use this skill when:
secrets.NUGET_API_KEY to OIDC-based publishingNuGet/login@v1 or id-token: write⚠️ Bail-out rule: If any phase fails after one fix attempt on an infrastructure/auth issue, stop and ask the user. Don't loop on environment problems.
⚠️ Never delete or overwrite without confirmation: Removing API key secrets, deleting tags/releases, removing workflow steps, or changing package IDs. NuGet package IDs are permanent — mistakes can't be undone.
Fast-path for greenfield repos: When the user has a simple setup (one packable project, no existing publish workflow), don't gate on multi-turn assessment. Combine phases: create the workflow immediately, include nuget.org policy guidance, local pack recommendation, and filename-matching warning all in one response. The full phased process below is for complex or migration scenarios.
Inspect the repo and report findings before making any changes.
.csproj files and Directory.Build.props (package metadata is often set repo-wide). Classify in this order (earlier matches win):
<PackageType>Template</PackageType> → Template<PackageType>McpServer</PackageType> → MCP server (also a dotnet tool)<PackAsTool>true</PackAsTool> → Dotnet toolIsPackable=true or no OutputType) → Library<OutputType>Exe</OutputType> with <IsPackable>true</IsPackable> → Application package (not a tool, but still publishable)test cases passed, vs 12 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.