The dotnet11/system-text-json-net11 skill scored 0%% pass across all five model families (issue #902, ADD-DECISIVENESS): it read as reference prose and the judge saw no behavior change vs baseline (7 ties, 67%% invocation).
Rewrite it into imperative when-A-do-B-verify-C guidance:
- Sharper frontmatter USE FOR / DO NOT USE FOR with trigger keywords to improve discovery.
- Decision table mapping each request to the exact API and the anti-pattern to avoid.
- Explicit DO/DON'T that target the eval's failure modes: no custom JsonNamingPolicy subclass, no cast of non-generic JsonTypeInfo, no try/catch to probe metadata.
- net11.0 run instructions (file-based app + project) so the program is actually executed.
- Verification checklist and common-pitfalls table.
Validated with skill-validator check (all checks passed).
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
* Add automated per-plugin versioning (NBGV) with /version-bump + weekly backstop
WHY
Tools that surface skills (Copilot CLI, Claude Code, Codex, Cursor) read a
plugin's version directly from its checked-in manifest. With no versioning
discipline, a plugin's behavior can change while its advertised version stays
flat, so clients never learn to re-pull, and there is no human-readable signal
of what changed. We want correct, current versions in the repo with minimal
manual work and without bloating the marketplace clone.
WHAT
- Per-plugin semantic versioning via Nerdbank.GitVersioning (NBGV). Each plugin
owns a version.json whose pathFilters exclude the generated manifests and the
version.json itself, so version height tracks real content changes only.
- The computed version is materialized into the checked-in manifests
(plugin.json and .codex-plugin/plugin.json) so every consumer reads a current
value with no build step on their side.
- eng/version/Sync-PluginVersions.ps1 is the single workhorse. It resolves the
set of changed plugins from a git diff, computes each version with nbgv
(predicting the squash-merge height for PRs), and either reports or stamps.
AUTOMATIONS (two, low-touch by design)
- /version-bump: an admin/maintainer comments the command on a PR and the
affected plugins are stamped on the PR branch. Gated on collaborator
permission (admin/write/maintain); forks are rejected before any privileged
step. No other PRs are auto-modified.
- weekly-version-sync: a Monday backstop (and workflow_dispatch) that stamps any
drift on main, opens/updates a single bot PR, and explains the per-plugin
reason. This self-heals anything that merged without a bump.
We deliberately did NOT auto-edit contributor PRs or add a noisy advisory
comment bot; maintainers stay in control and the signal stays clean.
SECURITY (multi-model adversarial review: GPT-5.5 + Gemini 3.1 Pro)
- Supply chain (High, both models): dotnet tool restore would have honored a
nuget.config authored in the PR tree, letting an attacker remap the nbgv
package source to a malicious feed and run code in the privileged
contents:write context. Mitigated with a trusted eng/version/nuget.config
(clear + nuget.org-only + packageSourceMapping), overlaid from main and used
via --configfile so PR-supplied configs are ignored. No nuget.config is
tracked in the repo today, so this path was genuinely exploitable.
- TOCTOU (Medium): /version-bump now checks out the authorized head SHA rather
than the mutable branch name; a racing push fails non-fast-forward, which is
the safe outcome.
- Injection: Set-ManifestVersion uses a MatchEvaluator (not a replacement
string) so a "$"-bearing version cannot re-expand, plus a strict
major.minor.patch guard that throws on a malformed base, leaving manifests
untouched.
- A base-only version.json bump (0.1 -> 0.2) is correctly detected and stamped.
VERIFIED
End-to-end against a real NBGV git harness: content-scoped predict, base-only
bump -> x.y.0, docs-only -> [], weekly drift stamping, malformed-base guard,
and --configfile restore (exit 0). actionlint passes on both workflows.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Address Copilot review feedback
- Add missing plugins/dotnet-test-migration/version.json so it participates
in versioning (it was the only plugin without one; manifests are at 0.1.0).
- CONTRIBUTING: the two manifests are not byte-identical; say the version is
duplicated across two manifest files instead.
- weekly-version-sync: include version.json in commit attribution so a
base-only bump is explained rather than showing 'no attributable commits'.
- Get-NbgvInfo: capture nbgv stderr and include it in the thrown error so CI
failures are diagnosable, while keeping stdout clean for JSON parsing.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The Codex CLI requires .codex-plugin/plugin.json as the plugin manifest
entry point. Without it, 'codex plugin add' fails with 'missing plugin.json'
even though the marketplace listing works.
This adds .codex-plugin/plugin.json to all 14 plugin directories, with paths
relative to the plugin root per the Codex docs. Also updates the agents
marketplace to use dotnet-aspnetcore (per #711 rename) and adds missing
dotnet-blazor and dotnet11 entries.
Fixes#578Fixes#724
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* add a new dotnet11 plugin and a new system text json skill to it.
* Update plugins/dotnet11/skills/system-text-json-net11/SKILL.md
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* added the option to run dotnet11 skills. by default they don't get included
* Update tests/dotnet11/system-text-json-net11/eval.yaml
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Add JSON output assertions to system-text-json-net11 eval.yaml
Agent-Logs-Url: https://github.com/dotnet/skills/sessions/8e302f3f-4328-44a0-845d-4eb0c930af63
Co-authored-by: ManishJayaswal <9527491+ManishJayaswal@users.noreply.github.com>
* addressed CR comments
* addressed more CR comments
* fixed agument to pass while enabling dotnet11 skills
* Remove dotnet11-specific filtering from skill-validator and evaluation workflow
Now that .NET 11 is the default SDK for the repo (global.json updated on main),
there is no need for special dotnet11 exclusion logic. The dotnet11 plugin skills
are treated like any other plugin and included in all evaluation runs.
Changes:
- Remove --include-dotnet11 CLI option and filtering logic from EvaluateCommand.cs
- Remove IncludeDotnet11 from ValidatorConfig model
- Remove --dotnet11 flag parsing from evaluation workflow gate job
- Remove dotnet11 exclusion logic from discover job
- Remove conditional .NET 11 preview SDK install step (global.json handles it)
- Remove dotnet11 from excludeFromSchedule list
- Remove all dotnet11-specific warning/status messages
- Remove section 9 from InvestigatingResults.md
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* address code review comments after rebase
* added the plugin to cursor and added MIT license to skill
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: [Manish Jayaswal] <[manishj@microsoft.com]>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ManishJayaswal <9527491+ManishJayaswal@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions[bot]