New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Validate Release-Note Code Samples

by dotnet in dotnet/core

Builds and runs the code snippets behind .NET release-note features against the exact milestone SDK, and records what must change to move maintained samples to a new preview.

OfficialMITAuto-check passedDevelopment

Install Validate Release-Note Code Samples

skills CLI
$ npx skills add dotnet/core --skill validate-code-samples -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install dotnet/core validate-code-samples --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/dotnet/core.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/validate-code-samples .claude/skills/validate-code-samples && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
validate-code-samples
GitHub stars
22k
Token cost
~1.4k tokens
SKILL.md length
635 words
Files
1
Skills in repo
15
Repo updated
First seen
Licence
MIT

At a glance

Builds and runs the code snippets behind .NET release-note features against the exact milestone SDK, and records what must change to move maintained samples to a new preview.

  • Checking that a release-note snippet compiles and behaves as documented
  • SKILL.md covers Acquiring a build, Where samples live, What to validate and Recording what you verified, plus 1 more section
  • Reaches ci.dot.net
  • Testing a documented feature against the milestone's exact preview SDK

What it does

This is the runtime verification stage of the .NET release-notes pipeline. It builds and runs what the notes claim, catching what a static ref-pack check cannot: JavaScript APIs, default values and whether a documented call sequence works. It reads build.sdk_version from the milestone's build-metadata.json, installs exactly that SDK with the official dotnet-install script into a fresh temporary directory from the https://ci.dot.net/public feed, sets DOTNET_ROOT and PATH, and stops if the reported version differs.

Maintained validation samples live under release-notes in a folder per major release and component, and they are upgraded from one preview to the next so renamed APIs, changed defaults, analyzer diagnostics and runtime regressions surface. Each major release starts a new sample set, and component owners review changes alongside the notes. The samples are test fixtures, not a reader-facing collection. The skill needs build-metadata.json, network access to the public build artifacts and PowerShell or a POSIX shell.

When your agent uses it

  • Checking that a release-note snippet compiles and behaves as documented
  • Testing a documented feature against the milestone's exact preview SDK
  • Listing what must change to move a maintained sample to the next preview

Example prompts

  • “Build and run the samples for the ASP.NET Core features in the release notes.”
  • “Install the SDK listed in build-metadata.json into a temp folder and test every snippet.”
  • “Document the steps needed to update the runtime samples to the new preview.”

Requirements

  • The milestone's build-metadata.json
  • Network access to the public .NET build artifacts
  • PowerShell or a POSIX shell
  • Compatibility (from SKILL.md): Requires the milestone's build-metadata.json, network access to the public .NET build artifacts, and PowerShell or a POSIX shell. Pairs with api-diff-validation, which covers the static half of the same problem.

What it can do on your machine

Read from SKILL.md and the folder at commit 44927bc. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • ci.dot.net

    Also links to:

    • learn.microsoft.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    Requires the milestone's build-metadata.json, network access to the public .NET build artifacts, and PowerShell or a POSIX shell. Pairs with api-diff-validation, which covers the static half of the same problem.

    From compatibility in the SKILL.md frontmatter.

Context cost

Validate Release-Note Code Samples loads about 1.4k tokens when it runs. Until then it costs about 183 tokens; SKILL.md has 635 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~183
When it runs · the whole SKILL.md, loaded when a task matches
~1.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from dotnet/core at commit 44927bc, republished under its MIT licence (© dotnet). 635 words, ~1,388 tokens.

Download SKILL.mdSave it as .claude/skills/validate-code-samples/SKILL.md (or your agent's skills folder).
name
validate-code-samples
description
Validate every release-note feature and its code snippets against the milestone build, and identify preview-to-preview migration steps when updating maintained samples. Reads the exact SDK version from build-metadata.json and installs it in a scoped location with the official dotnet-install script. USE FOR - building and running samples for release-note features, testing documented snippets and behavior, and documenting changes needed to update maintained samples to a new preview. DO NOT USE FOR - generating build-metadata.json or the API diff (use the release-notes workflow and api-diff), confirming a managed API exists in a ref pack (use api-diff-validation), scoring features (use generate-features).
compatibility
Requires the milestone's build-metadata.json, network access to the public .NET build artifacts, and PowerShell or a POSIX shell. Pairs with api-diff-validation, which covers the static half of the same problem.

Validate Code Samples

Build and run what the release notes claim. This is the runtime verification stage of the pipeline, and it is the last line of defence before a component PR goes to its owner.

api-verification.md covers the static half of this problem: does a managed type or member exist in the ref pack? That check is necessary and cheap, but it is not sufficient. It cannot see JavaScript APIs, it cannot tell you what a default value is, and it cannot tell you whether a documented sequence of calls actually works.

Acquiring a build

Use build.sdk_version from the milestone's existing build-metadata.json. If the file or version is missing, generate the metadata through the release-notes workflow before validating samples; see api-verification.md. Do not substitute the machine SDK or a latest-channel build.

Install that exact version into a fresh, empty temporary directory with the official public dotnet-install script for the host OS. Pass the exact version (-Version or --version), the https://ci.dot.net/public feed (-AzureFeed or --azure-feed), and the temporary install directory (-InstallDir or --install-dir); stop if installation fails. Set DOTNET_ROOT to that directory and prepend it to PATH for sample builds and runs. Do not install the preview SDK machine-wide.

Verify the installed SDK reports build.sdk_version; stop if it does not.

Where samples live

Keep maintained validation samples in this repository under release-notes/<major>.0/samples/<component>/, for example release-notes/11.0/samples/aspnetcore/. These are executable fixtures primarily for verifying release notes, not a general-purpose or reader-facing samples collection. They do not replace the officially documented samples maintained by the relevant product and documentation teams.

Use one working sample set per major release and component. Upgrade it from preview to preview so API renames, changed defaults, analyzer diagnostics, and runtime regressions surface naturally. Start each major release with a new sample set instead of copying or retargeting scenarios from the previous release. Component owners review changes to their sample set alongside the corresponding release notes.

Keep samples for release-note features in the maintained component set so they can be rerun in later previews. For one-off compile checks outside feature validation, use a scratch project and remove it afterward.

Do not commit downloaded SDKs, packages, build outputs, certificates, secrets, or generated assets.

Show full SKILL.md (272 more words)Show less

What to validate

  • Build or update a sample for every feature in the release notes, even if the notes have no code snippet for it. Run each sample against the milestone build and verify the claimed behavior, such as a browser API call, an endpoint response, or an explicitly stated default or flag polarity. A successful build or startup alone is not enough.
  • Test any code snippets from the release notes as part of those samples. Confirm the snippets build, run, and behave as described.
  • As you update existing maintained samples to the new preview, note changes required by the new release. Document the resulting preview-to-preview breaking changes and migration steps in the release notes.

Recording what you verified

Create release-notes/<major>.0/samples/README.md when adding maintained samples. Explain their purpose and record the SDK version against which all component sample sets were last validated. Update the version after validating the sets against a new SDK.

In each <component>/README.md, describe the component's samples, how to run them, and their expected behavior. Keep it current as the samples change.

When a claim fails validation

Follow the escalation in api-verification.md — check the package version, search for a rename, look for a revert, confirm the member is public. Then:

  • Fix the notes, not the sample, when the notes describe an API that does not exist. Rewrite the section around what actually shipped.
  • Update the sample and document the migration when the new release requires changes to an existing sample. Explain the preview-to-preview change in the notes.
  • Drop the claim when neither holds up. A correct prose description with a PR link always beats a confident, wrong code sample.

© dotnet, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .github/skills/validate-code-samples of dotnet/core.

Open the folder on GitHubat commit 44927bc

Compare with similar skills

Validate Release-Note Code Samples next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Validate Release-Note Code Samples compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Validate Release-Note Code Samples this skilldotnet/core22k—~1.4kAutomated safety check: PassMIT
Maintain DisCatSharpAiko-IT-Systems/DisCatSharp140—~1.2kAutomated safety check: PassMIT
Code Reviewpnp/powershell905—~385Automated safety check: PassMIT
Verify Releaseillegalstudio/elephc602—~2.5kAutomated safety check: PassMIT
Try Fix Alternative Approachdotnet/maui23k—~8.4kAutomated safety check: PassMIT
Simple Englishmoeru-ai/airi50k2 repos~4.6kAutomated safety check: PassMIT

Similar skills

  • Maintain DisCatSharp

    Aiko-IT-Systems/DisCatSharp

    Guides changes to the DisCatSharp C# Discord library: tracing a payload field through parsing, serialization and caches, then validating across target frameworks.

    140 GitHub stars~1.2k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Code Review

    pnp/powershell

    Reviews changes to PnP PowerShell, a .NET 8 module of 800+ cmdlets for Microsoft 365.

    905 GitHub stars~385 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Verify Release

    illegalstudio/elephc

    Pre-release verification that first requires a complete release-changelog audit, then checks README, docs, roadmap, test coverage, examples, and the full test suite for regressions.

    602 GitHub stars~2.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Try Fix Alternative Approach

    dotnet/maui

    Official

    Attempts one alternative fix for a bug, runs the given test command against it and reports what happened, always differing from existing PR fixes.

    23k GitHub stars~8.4k tokensUpdated today
    DevelopmentAuto-check passed

  • Simple English

    moeru-ai/airi

    Write or rewrite technical text with the rules of ASD-STE100 Simplified Technical English so it is clear, unambiguous, and free of AI slop.

    50k GitHub starsUsed in 2 repos~4.6k tokens
    DevelopmentAuto-check passed

  • Evaluate PR Tests

    dotnet/maui

    Official

    Reviews the tests added in a pull request for fix coverage, quality, edge cases and test type, and recommends lighter test types where they would do.

    23k GitHub stars~2.9k tokensUpdated today
    Testing & QAAuto-check passed

More from dotnet/core

All 15 skills in this repo

  • Update .NET OS Packages

    dotnet/core

    Official

    Audits and updates os-packages.json files listing the Linux packages each .NET release needs per distro, then regenerates the Markdown from the JSON.

    22k GitHub stars~2.3k tokensUpdated 2 days ago
    Auto-check passed

  • Update .NET Supported OS Matrix

    dotnet/core

    Official

    Audits and updates the supported-os.json files for .NET releases, checking them against upstream lifecycle data and regenerating the markdown with the release-notes tool.

    22k GitHub stars~4.1k tokensUpdated 2 days ago
    Auto-check passed

  • .NET Release Verification

    dotnet/core

    Official

    Validates .NET release data with the release-notes CLI: download URL liveness, SHA512 hashes, CDN latest.version files and aka.ms redirects.

    22k GitHub stars~1.8k tokensUpdated 2 days ago
    Auto-check passed

  • Generate .NET Release changes.json

    dotnet/core

    Official

    Produces the changes.json manifest for a .NET preview, RC or GA milestone by choosing the right VMR base and head refs and running release-notes generate changes.

    22k GitHub stars~1.7k tokensUpdated 2 days ago
    Auto-check passed

  • Release Feature Scoring

    dotnet/core

    Official

    Ranks the changes in a release manifest and writes a scored features file that release notes, docs and blog posts can each cut at their own threshold.

    22k GitHub stars~2.2k tokensUpdated 2 days ago
    Auto-check passed

  • Release Notes Editorial Review

    dotnet/core

    Official

    Audits a scored features.json file and its draft release notes against editorial examples to catch over-scored, under-scored, or missing entries.

    22k GitHub stars~1.6k tokensUpdated 2 days ago
    Auto-check passed

Works with

Categories

Questions about Validate Release-Note Code Samples

What does Validate Release-Note Code Samples do?

Builds and runs the code snippets behind .NET release-note features against the exact milestone SDK, and records what must change to move maintained samples to a new preview. NET release-notes pipeline. It builds and runs what the notes claim, catching what a static ref-pack check cannot: JavaScript APIs, default values and whether a documented call sequence works.

When should I use Validate Release-Note Code Samples?

Validate Release-Note Code Samples fits situations like: checking that a release-note snippet compiles and behaves as documented; testing a documented feature against the milestone's exact preview SDK; listing what must change to move a maintained sample to the next preview.

How do I install Validate Release-Note Code Samples in Claude Code?

Run `npx skills add dotnet/core --skill validate-code-samples -a claude-code`. Or copy the skill folder (.github/skills/validate-code-samples in dotnet/core) into .claude/skills/validate-code-samples in your project. Claude Code loads it when a task matches its description.

How do I install Validate Release-Note Code Samples in Codex?

Run `npx skills add dotnet/core --skill validate-code-samples -a codex`. Or copy the skill folder (.github/skills/validate-code-samples in dotnet/core) into .agents/skills/validate-code-samples in your project. Codex loads it when a task matches its description.

Can I use Validate Release-Note Code Samples in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add dotnet/core --skill validate-code-samples -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/validate-code-samples, .gemini/skills/validate-code-samples, .github/skills/validate-code-samples and .opencode/skills/validate-code-samples in your project.

What does Validate Release-Note Code Samples need to run?

SKILL.md names no scripts, command-line tools or credentials: Validate Release-Note Code Samples is instructions for the agent only. Our summary lists: The milestone's build-metadata.json; Network access to the public .NET build artifacts; PowerShell or a POSIX shell. Compatibility (from SKILL.md): Requires the milestone's build-metadata.json, network access to the public .NET build artifacts, and PowerShell or a POSIX shell. Pairs with api-diff-validation, which covers the static half of the same problem..

Does Validate Release-Note Code Samples access the network?

SKILL.md names 2 domains. In commands or code: ci.dot.net; the agent is likely to contact it when it follows the instructions. As links in the text: learn.microsoft.com. This is read from the text; nothing was executed.

Is Validate Release-Note Code Samples safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Validate Release-Note Code Samples use?

Validate Release-Note Code Samples is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Validate Release-Note Code Samples use?

About 1.4k tokens (SKILL.md is roughly 5.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Validate Release-Note Code Samples?

Skills that share tags, products or a category with Validate Release-Note Code Samples: Maintain DisCatSharp (Aiko-IT-Systems/DisCatSharp, 140 stars), Code Review (pnp/powershell, 905 stars), Verify Release (illegalstudio/elephc, 602 stars) and Try Fix Alternative Approach (dotnet/maui, 23k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Validate Release-Note Code Samples?

dotnet (a GitHub organization, an official publisher) maintains it in dotnet/core, which has 22,038 GitHub stars. The repository holds 15 skills in this directory. The repository was last updated on October 5, 2026.

Source: dotnet/core on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.