Add nuget-trusted-publishing skill#210
Conversation
Knowledge-driven skill for setting up NuGet trusted publishing (OIDC) on GitHub Actions repos, replacing long-lived API keys with short-lived tokens. Replaces #34 which could not be reopened after history rewrite.
There was a problem hiding this comment.
Pull request overview
Adds a new knowledge-driven .NET skill intended to guide users through setting up NuGet trusted publishing (OIDC) for GitHub Actions, including reference material and an eval scenario suite.
Changes:
- Adds the
nuget-trusted-publishingskill content (SKILL.md) describing a phased setup process for NuGet OIDC/trusted publishing. - Adds reference docs covering package-type detection/requirements and a publish workflow template.
- Adds skill-validator eval scenarios for greenfield setup, implicit OIDC request, and API-key migration.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/dotnet/skills/nuget-trusted-publishing/SKILL.md | New skill instructions for setting up NuGet trusted publishing (OIDC) in GitHub Actions. |
| src/dotnet/skills/nuget-trusted-publishing/references/package-types.md | Reference doc for detecting/validating different NuGet package types before publishing setup. |
| src/dotnet/skills/nuget-trusted-publishing/references/publish-workflow.md | Reference publish workflow template using NuGet/login + id-token: write. |
| src/dotnet/tests/nuget-trusted-publishing/eval.yaml | New eval scenarios intended to validate the skill’s guidance for trusted publishing and migration. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: "Set up trusted publishing for a new NuGet library" | ||
| prompt: | | ||
| I have a .NET class library at src/MyLib/MyLib.csproj that I want to publish | ||
| to nuget.org using trusted publishing (OIDC) instead of an API key. | ||
| The repo is hosted on GitHub at myorg/mylib. Help me set this up. |
There was a problem hiding this comment.
These scenarios reference repo files/structure (e.g., src/MyLib/MyLib.csproj) but the eval has no setup: section. Skill-validator runs scenarios in a fresh temp directory, so the referenced project/workflow files won’t exist unless you create them. Consider adding setup.files for a minimal packable .csproj (and, for the migration scenario, a baseline publish workflow that uses secrets.NUGET_API_KEY) so the skill can actually inspect/modify the repo as instructed.
ViktorHofer
left a comment
There was a problem hiding this comment.
Please update the folder structure. The skill should be under plugins not src. The test should be under the root tests folder.
Eval Results (Run 5 — fresh PR after repo history rewrite)
Model: claude-opus-4.6 | Judge: claude-opus-4.6 | Runs: 3 All three scenarios pass with +1.7 to +2.0 improvement over baseline. No overfitting detected. |
the previous version of the pr was broken by other changes you made, I'm in the process of restoring it. |
…dd CODEOWNERS - Move skill from src/dotnet/skills/ to plugins/dotnet/skills/nuget-trusted-publishing/ - Move eval from src/dotnet/tests/ to tests/dotnet/nuget-trusted-publishing/ - Fix Phase 3/4 sequencing conflict: clarify that drafting the workflow is OK before policy confirmation, but publishing/removing secrets should wait - Add CODEOWNERS entry for nuget-trusted-publishing Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Skill Validation Results
Model: claude-opus-4.6 | Judge: claude-opus-4.6 |
|
Someone from Nuget team should sign off on this IMO |
Add nuget-trusted-publishing skill
Knowledge-driven skill for setting up NuGet trusted publishing (OIDC) on GitHub Actions repos -- replacing long-lived API keys with short-lived tokens.
5-Phase Process
Files
SKILL.md-- orchestrating skill (~1900 tokens)references/package-types.md-- per-type structural requirements and detection logicreferences/publish-workflow.md-- complete tag-triggered workflow templateValidated against
Replaces #34 which could not be reopened after repo history rewrite.