Official agent skill

Update .NET Distro Packages

by dotnet in dotnet/core

Creates and maintains the per-distro JSON files that list the native packages .NET needs on each Linux distribution, scoped to one .NET version.

OfficialMITAuto-check: notesDevelopment

Install Update .NET Distro Packages

skills CLI
$ npx skills add dotnet/core --skill update-distro-packages -a claude-code

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

GitHub CLI
$ gh skill install dotnet/core update-distro-packages --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/update-distro-packages .claude/skills/update-distro-packages && 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
update-distro-packages
GitHub stars
22k
Token cost
~4.3k tokens
SKILL.md length
1,420 words
Files
1
Skills in repo
15
Repo updated
First seen
Licence
MIT

At a glance

Creates and maintains the per-distro JSON files that list the native packages .NET needs on each Linux distribution, scoped to one .NET version.

  • Works in 12 steps: Identify source data → Create dependencies.json → Create per-distro files → …
  • Setting up the distros directory for a new .NET version
  • SKILL.md covers Directory structure, When to use, Prerequisites and Inputs, plus 5 more sections
  • Calls curl, python3 and apt-get; reaches packages.ubuntu.com and nuget.pkg.github.com; needs PKGS_ORG_TOKEN

What it does

Inside the release-notes data for each .NET version sits a `distros/` folder, and this skill manages it. It holds a distro-agnostic `dependencies.json` listing what .NET needs, updated once per major release, an `index.json` with the alphabetically sorted per-distro file names, and one JSON file per distribution such as `ubuntu.json`, each with its install command and packages and no version field because the folder gives the version.

It is used to set up `distros/` for a new .NET version, to add or remove a distro release from the support matrix, to rename dependency packages when a distro version changes (for example `libicu74` to `libicu76` on a new Ubuntu), and to audit the data periodically. The `release-notes` .NET global tool must be installed for markdown generation and package availability queries, and the agent checks for it and installs or updates it from the NuGet source given in the skill. Filling in which .NET packages each distro offers is optional and needs a `PKGS_ORG_TOKEN`, which requires a pkgs.org Gold+ subscription. Changes to supported-os.json belong to a separate skill.

When your agent uses it

  • Setting up the distros directory for a new .NET version
  • Adding or removing a Linux distro release from the support matrix
  • Updating dependency package names after a distro version change
  • Auditing the package data to keep it current

Example prompts

  • “Create the distros directory for .NET 11.0 with the current dependency list.”
  • “Ubuntu moved from libicu74 to libicu76; update the dependency package names.”
  • “Add the new Fedora release to the .NET 11.0 distro files.”
  • “Audit the distro package data for .NET 11.0 and tell me what is out of date.”

Requirements

  • The `release-notes` .NET global tool
  • A checkout of the .NET release-notes data
  • A pkgs.org Gold+ subscription and PKGS_ORG_TOKEN, only to update package availability

Workflow steps

12 steps, taken from the step headings in SKILL.md.

  1. Identify source data
  2. Create dependencies.json
  3. Create per-distro files
  4. Create index.json
  5. Validate
  6. Generate markdown
  7. Query package feeds
  8. Read query results
  9. Map into per-distro files
  10. Handle distros not in query results
  11. Query distro package lists directly
  12. Present summary

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

    Shell commands in SKILL.md call:

    • curl
    • python3
    • apt-get
    • dotnet
    • git
    • wget

    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:

    • packages.ubuntu.com
    • nuget.pkg.github.com
    • bodhi.fedoraproject.org
    • src.fedoraproject.org
    • packages.microsoft.com

    Also links to:

    • pkgs.org
    • github.com

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

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • PKGS_ORG_TOKEN

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

Context cost

Update .NET Distro Packages loads about 4.3k tokens when it runs. Until then it costs about 111 tokens; SKILL.md has 1,420 words of instructions outside code blocks.

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

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: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteRuns commands with sudoSKILL.md:144
    install -y software-properties-common && sudo add-apt-repository ppa:dotnet/backports && sudo apt-get update",
  • NoteRuns commands with sudoSKILL.md:327
    install -y software-properties-common && sudo add-apt-repository ppa:dotnet/backports && sudo apt-get update",
  • NoteRuns commands with sudoSKILL.md:428
    sudo apt-get install -y software-properties-common && sudo add-apt-repository ppa:dotnet/backports && sudo apt-get updat
  • NoteRuns commands with sudoSKILL.md:438
    b -O /tmp/packages-microsoft-prod.deb && sudo dpkg -i /tmp/packages-microsoft-prod.deb && rm /tmp/packages-microsoft-pro

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). 1,420 words, ~4,310 tokens.

Download SKILL.mdSave it as .claude/skills/update-distro-packages/SKILL.md (or your agent's skills folder).
name
update-distro-packages
description
Create and update per-distro package files in release-notes/{version}/distros/ that document .NET runtime dependencies and package availability for each Linux distribution. USE FOR: setting up distros/ for a new .NET version, updating dependency package names when distro versions change, auditing package data. DO NOT USE FOR: supported-os.json changes (use update-supported-os skill), os-packages.json (legacy format).

Update Distro Packages

Create and maintain per-distro JSON files in release-notes/{version}/distros/. Each file declares the native packages .NET depends on for a specific distribution, scoped to a single .NET version.

Directory structure

text
release-notes/{version}/distros/
├── dependencies.json    # distro-agnostic dependency list (what .NET needs)
├── index.json           # lists all per-distro file names
├── alpine.json          # per-distro: dependencies with distro-specific names
├── ubuntu.json
├── fedora.json
└── ...

When to use

  • A new .NET version needs its distros/ directory created for the first time
  • A distro release is added or removed from the support matrix
  • A dependency package name changes (e.g. libicu74 → libicu76 on a new Ubuntu)
  • Periodic audit to keep dependency data current

Prerequisites

The release-notes tool must be installed for markdown generation and package availability queries. The public dotnet-release tool is now for browsing release data and CVEs.

bash
# Check if already installed
release-notes --version

If not installed:

bash
dotnet tool install -g release-notes \
  --add-source https://nuget.pkg.github.com/richlander/index.json

If already installed, update to latest:

bash
dotnet tool update -g release-notes \
  --add-source https://nuget.pkg.github.com/richlander/index.json

Inputs

The user provides:

  • .NET version — which version to work on (e.g. "11.0")
  • Task — what to do: create new distros/ directory, add a distro release, update package names, populate dotnet packages, etc.

Ask the user: Do you want to update dotnet packages (which .NET packages are available in each distro)? If so, ask them to provide or set PKGS_ORG_TOKEN. This requires a pkgs.org Gold+ subscription.

File schemas

dependencies.json

Distro-agnostic list of packages .NET requires. Updated once per major release — rarely changes.

json
{
  "channel_version": "11.0",
  "packages": [
    {
      "id": "libc",
      "name": "C Library",
      "required_scenarios": ["all"],
      "references": ["https://..."]
    },
    {
      "id": "openssl",
      "name": "OpenSSL",
      "required_scenarios": ["https", "cryptography"],
      "min_version": "1.1.1",
      "references": ["https://..."]
    }
  ]
}

Omit min_version and references when null/empty.

index.json
json
{
  "channel_version": "11.0",
  "distros": [
    "alpine.json",
    "azure_linux.json",
    "ubuntu.json"
  ]
}

Alphabetically sorted list of per-distro file names.

Per-distro files (e.g. ubuntu.json)

Scoped to the .NET version of the parent directory. No dotnet_versions field — the version is the directory.

json
{
  "name": "Ubuntu",
  "install_command": "apt-get install -y {packages}",
  "releases": [
    {
      "name": "Ubuntu 24.04 (Noble Numbat)",
      "release": "24.04",
      "dependencies": [
        { "id": "ca-certificates", "name": "ca-certificates" },
        { "id": "libc", "name": "libc6" },
        { "id": "libicu", "name": "libicu74" },
        { "id": "openssl", "name": "libssl3t64" }
      ]
    }
  ]
}

Optional fields on each release (populated by package availability queries):

json
{
  "dotnet_packages": [
    { "component": "sdk", "name": "dotnet-sdk-11.0" },
    { "component": "runtime", "name": "dotnet-runtime-11.0" }
  ],
  "dotnet_packages_other": {
    "backports": {
      "install_command": "sudo apt-get install -y software-properties-common && sudo add-apt-repository ppa:dotnet/backports && sudo apt-get update",
      "packages": [
        { "component": "sdk", "name": "dotnet-sdk-11.0" }
      ]
    }
  }
}

The install_command in dotnet_packages_other is the command to register the feed — it must be run before packages can be installed with the distro's normal install command. This field is required for every alternative feed entry. See Known alternative feed commands for values.

Process

Creating distros/ for a new .NET version
1. Identify source data

Use os-packages.json from the same version (if it exists) or the previous .NET version as the source for dependency data:

bash
cat release-notes/{version}/os-packages.json
# or from a previous version:
cat release-notes/{prev-version}/os-packages.json

Also reference release-notes/{version}/supported-os.json for the list of supported Linux distributions and versions.

2. Create dependencies.json

Extract the packages array from os-packages.json. Convert keys to snake_case:

  • required-scenarios → required_scenarios
  • min-version → min_version

This file changes very rarely — it lists what .NET needs, not what distros call things.

3. Create per-distro files

For each distribution in os-packages.json:

  • File name: lowercase distro name, spaces → _ (e.g. azure_linux.json, centos_stream.json)
  • install_command: From the distro's install-commands — use the last command, format as {command-root} {command-parts}, normalize {packageName} → {packages}
  • releases: One entry per distro release, with dependencies sorted alphabetically by id
  • Do NOT include dotnet_packages or dotnet_packages_other — those are populated separately

The scope of distros/ is broader than supported-os.json. Include pre-release distro versions and permanent rolling channels where the package information is helpful:

  • Alpine edge — always include; it tracks the rolling release
  • Debian sid (Unstable) — always include
  • Pre-release distro versions — e.g. Fedora beta, Ubuntu interim release before GA

These are informational — their presence does not imply official .NET support.

4. Create index.json

List all per-distro file names alphabetically.

5. Validate
bash
# Verify all JSON parses
for f in release-notes/{version}/distros/*.json; do
  python3 -c "import json; json.load(open('$f'))" && echo "OK: $f"
done

Confirm every Linux distro in supported-os.json has a corresponding file.

6. Generate markdown

Regenerate dotnet-dependencies.md from the JSON files:

bash
release-notes generate dotnet-dependencies {version} release-notes

This produces release-notes/{version}/dotnet-dependencies.md with copy-pasteable install commands for each distro and release. Never hand-edit this file — it is generated from the JSON.

Updating existing distros/ files
Adding a new distro release
  1. Check supported-os.json for the new release
  2. In the distro's JSON file, copy the most recent release entry
  3. Update name, release, and any changed package names (e.g. libicu74 → libicu76)
  4. Insert in version order (newest first)
Removing a distro release

Delete the release object from the releases array. If the entire distro is dropped, delete the file and remove it from index.json.

Fixing package names

Update the name field in the relevant dependency entry. Package names change between distro releases due to shared library versioning (e.g. libicu70 on Ubuntu 22.04 → libicu74 on 24.04).

Populating dotnet packages

This populates dotnet_packages and dotnet_packages_other in each per-distro file — recording which .NET packages (SDK, runtime, ASP.NET Core) are available in each distro's package feeds.

Requires PKGS_ORG_TOKEN to be set.

1. Query package feeds
bash
export PKGS_ORG_TOKEN=<token>
release-notes query distro-packages --dotnet-version {version} --output /tmp/distro-packages.json

This queries pkgs.org and supplemental feeds (Ubuntu backports via Launchpad, Homebrew, NixOS) and writes a JSON file with package availability per distro.

2. Read query results

The output file has this structure:

json
{
  "channel_version": "10.0",
  "last_verified": "2026-03-25",
  "distributions": [
    {
      "name": "Ubuntu",
      "releases": [
        {
          "name": "Ubuntu 24.04",
          "release": "24.04",
          "feeds": {
            "builtin": [
              { "component_id": "sdk", "package_name": "dotnet-sdk-10.0" },
              { "component_id": "runtime", "package_name": "dotnet-runtime-10.0" },
              { "component_id": "aspnetcore-runtime", "package_name": "aspnetcore-runtime-10.0" }
            ],
            "backports": [
              { "component_id": "sdk", "package_name": "dotnet-sdk-10.0" }
            ]
          }
        }
      ]
    }
  ]
}
3. Map into per-distro files

For each distro+release in the query results, match it to the corresponding per-distro file and update:

  • feeds["builtin"] → dotnet_packages (flat list)
  • Any other feed (e.g. feeds["backports"]) → dotnet_packages_other["backports"]

Field mapping from query → per-distro file:

Query fieldPer-distro field
component_idcomponent
package_namename

Every dotnet_packages_other entry must include an install_command — the command to register that feed before packages can be installed. See Known alternative feed commands for the values to use.

Example — if the query returns this for Ubuntu 24.04:

json
"feeds": {
  "builtin": [
    { "component_id": "sdk", "package_name": "dotnet-sdk-10.0" }
  ],
  "backports": [
    { "component_id": "sdk", "package_name": "dotnet-sdk-10.0" }
  ]
}

Then ubuntu.json release 24.04 becomes:

json
{
  "name": "Ubuntu 24.04 (Noble Numbat)",
  "release": "24.04",
  "dependencies": [ ... ],
  "dotnet_packages": [
    { "component": "sdk", "name": "dotnet-sdk-10.0" }
  ],
  "dotnet_packages_other": {
    "backports": {
      "install_command": "sudo apt-get install -y software-properties-common && sudo add-apt-repository ppa:dotnet/backports && sudo apt-get update",
      "packages": [
        { "component": "sdk", "name": "dotnet-sdk-10.0" }
      ]
    }
  }
}
4. Handle distros not in query results

Not all distros appear in the query results (e.g. RHEL packages are in a subscription-only repo). Leave dotnet_packages absent for those — do not add an empty list.

Show full SKILL.md (604 more words)Show less
5. Query distro package lists directly

pkgs.org may not have data for newly released distro versions yet. When a supported distro release is missing from the query results, check the distro's own package list as a fallback.

Ubuntu — query packages.ubuntu.com for the release codename:

bash
curl -s "https://packages.ubuntu.com/{codename}/allpackages?format=txt.gz" \
  | gunzip | grep -i "dotnet.*{major}"
curl -s "https://packages.ubuntu.com/{codename}/allpackages?format=txt.gz" \
  | gunzip | grep -i "aspnetcore.*{major}"

For example, to check Ubuntu 26.04 (codename resolute) for .NET 10:

bash
curl -s "https://packages.ubuntu.com/resolute/allpackages?format=txt.gz" \
  | gunzip | grep -iE "(dotnet|aspnetcore).*10"

If the packages are found (e.g. dotnet-sdk-10.0, dotnet-runtime-10.0, aspnetcore-runtime-10.0 in the universe component), add them as dotnet_packages for that release.

Fedora — query the Bodhi update system and source RPM spec:

bash
# Check which Fedora releases have dotnet builds
curl -s "https://bodhi.fedoraproject.org/updates/?packages=dotnet{major}.{minor}&rows_per_page=20" \
  | python3 -c "
import sys, json
for u in json.load(sys.stdin).get('updates', []):
    print(f\"{u['release']['name']}: {u['title']} ({u['status']})\")"

For example, to check .NET 10.0:

bash
curl -s "https://bodhi.fedoraproject.org/updates/?packages=dotnet10.0&rows_per_page=20" \
  | python3 -c "
import sys, json
for u in json.load(sys.stdin).get('updates', []):
    print(f\"{u['release']['name']}: {u['title']} ({u['status']})\")"

Results show each Fedora release with its build status (e.g. F44: dotnet10.0-10.0.104-1.fc44 (testing)). To confirm the subpackage names, check the spec file:

bash
curl -s "https://src.fedoraproject.org/rpms/dotnet{major}.{minor}/blob/f{release}/f/dotnet{major}.{minor}.spec" \
  | grep -E "^%package|^Name:"

Fedora packages follow a consistent naming scheme (dotnet-sdk-{major}.{minor}, dotnet-runtime-{major}.{minor}, aspnetcore-runtime-{major}.{minor}), so this is mainly a confirmation step.

Other distros — Alpine packages can be checked at pkgs.alpinelinux.org. For most other distros, pkgs.org covers them well. Only fall back to direct queries when pkgs.org is missing data for a release you expect to have packages.

6. Present summary

Show the user a summary of which distros+releases have packages and from which feeds, and flag any gaps (supported distro but no packages found).

Regenerate markdown

After any JSON changes, regenerate both markdown files:

bash
release-notes generate dotnet-dependencies {version} release-notes
release-notes generate dotnet-packages {version} release-notes
  • dotnet-dependencies.md — what OS packages .NET requires (from dependency data)
  • dotnet-packages.md — where to get .NET packages (from dotnet_packages / dotnet_packages_other data)

Important: Do not hand-edit these markdown files. They are generated from the distros/ JSON files. If the output needs to change, update the generator or template in dotnet-release.

Commit
bash
git add release-notes/{version}/distros/ release-notes/{version}/dotnet-dependencies.md release-notes/{version}/dotnet-packages.md
git commit -m "Update {version} distro packages — <summary>"

Known alternative feed commands

When packages come from a non-builtin feed, the install_command field tells users how to register that feed before installing packages. Use the exact commands below.

Ubuntu backports PPA

Feed name: backports

bash
sudo apt-get install -y software-properties-common && sudo add-apt-repository ppa:dotnet/backports && sudo apt-get update

This PPA provides .NET packages for older Ubuntu LTS releases that don't carry .NET in the default archive. add-apt-repository comes from software-properties-common, which is often missing in containers and other minimal environments. After registering, packages are installed with the normal apt-get install command.

Microsoft packages.microsoft.com (PMC)

Feed name: microsoft

bash
wget https://packages.microsoft.com/config/{distro}/{version}/packages-microsoft-prod.deb -O /tmp/packages-microsoft-prod.deb && sudo dpkg -i /tmp/packages-microsoft-prod.deb && rm /tmp/packages-microsoft-prod.deb

Replace {distro} and {version} with the distro name and version (e.g. ubuntu/22.04, debian/12). Note: Microsoft is phasing out PMC for Ubuntu 24.04+ — prefer the builtin or backports feed when available.

Other feeds

If the query returns a feed name not listed above, ask the user for the registration command. Do not guess — incorrect feed setup commands are worse than none.

Key facts

  • Files are version-scoped — release-notes/11.0/distros/ubuntu.json is about .NET 11.0 on Ubuntu
  • Dependencies use an agnostic id (e.g. libicu) with a distro-specific name (e.g. libicu74)
  • dependencies.json is the "what .NET needs" list; per-distro files map those to real package names
  • Package names like libicu are versioned on Debian/Ubuntu (e.g. libicu76) but not on Fedora/RHEL (just libicu)
  • Alpine uses a different naming scheme for .NET packages: dotnet{major}-{component} (e.g. dotnet9-sdk)
  • Debian/Ubuntu/Fedora use: dotnet-sdk-{major}.{minor}, dotnet-runtime-{major}.{minor}
  • Microsoft is phasing out packages.microsoft.com for Ubuntu 24.04+ and newer Fedora
  • install_command uses {packages} as a placeholder for the package list

Display name rules

The name fields (both top-level distro name and per-release names) must use full display names, never acronyms. These names appear in generated markdown and user-facing documentation.

❌ Acronym✅ Full display name
RHELRed Hat Enterprise Linux
SLESSUSE Linux Enterprise Server

Examples:

  • Top-level: "name": "Red Hat Enterprise Linux" (not "RHEL")
  • Release: "name": "Red Hat Enterprise Linux 9" (not "RHEL 9")
  • Top-level: "name": "SUSE Linux Enterprise Server" (not "SLES")
  • Release: "name": "SUSE Linux Enterprise Server 15.7" (not "SLES 15.7")

File names (rhel.json, sles.json) remain short — only the name fields inside must use full names. When creating new distro files or adding releases, always verify the display name is the full product name, not an abbreviation.

© 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/update-distro-packages of dotnet/core.

Open the folder on GitHubat commit 44927bc

Compare with similar skills

Update .NET Distro Packages 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.

Update .NET Distro Packages compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Update .NET Distro Packages this skilldotnet/core22k—~4.3kAutomated safety check: NotesMIT
Dotnet Debuggingnovotnyllc/dotnet-artisan233—~2.1kAutomated safety check: PassMIT
GitVersion .NET DevelopmentGitTools/GitVersion3.1k—~1.7kAutomated safety check: PassMIT
Dependency UpdaterAsvarox/allkaraoke2614 repos~3.5kAutomated safety check: PassMIT
RStudio Copilot Language Server Updaterrstudio/rstudio5.1k—~1.1kAutomated safety check: PassCustom licence
Bump LibdatadogDataDog/dd-trace-dotnet573—~1.7kAutomated safety check: PassApache-2.0

Similar skills

  • Dotnet Debugging

    novotnyllc/dotnet-artisan

    Debugs Windows and Linux/macOS applications (native, .NET/CLR, mixed-mode) with WinDbg MCP (crash dumps, !analyze, !syncblk, !dlk, !runaway, !dumpheap, !gcroot, BSOD), dotnet-dump, lldb with SOS…

    233 GitHub stars~2.1k tokensUpdated today
    DevelopmentAuto-check passed
  • GitVersion .NET Development

    GitTools/GitVersion

    Gives repository-specific .NET guidance for GitVersion: build and test commands, central package management, project layout and coding conventions.

    3.1k GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed
  • Dependency Updater

    Asvarox/allkaraoke

    Smart dependency management for any language. An agent skill from Asvarox/allkaraoke.

    261 GitHub starsUsed in 4 repos~3.5k tokens
    DevelopmentAuto-check passed
  • Advances RStudio's pinned copilot-language-server dependency to a specified release, then uploads it to S3, verifies the install, and opens a PR.

    5.1k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed
  • Bump Libdatadog

    DataDog/dd-trace-dotnet

    Official

    Update/bump the libdatadog native library version in dd-trace-dotnet.

    573 GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed
  • Netdaemon Nuget Upgrade

    net-daemon/netdaemon

    Upgrade all or selected NuGet packages in net-daemon/netdaemon with dotnet-outdated, validate the full solution, and optionally publish a dependency-update PR with gh-axi.

    312 GitHub stars~1.4k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

More from dotnet/core

All 15 skills in this repo
  • 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 today
    Auto-check passed
  • 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 today
    Auto-check passed
  • 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 today
    Auto-check passed
  • 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 today
    Auto-check passed
  • 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 today
    Auto-check passed
  • 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 today
    Auto-check passed

Works with

Questions about Update .NET Distro Packages

What does Update .NET Distro Packages do?

Creates and maintains the per-distro JSON files that list the native packages .NET needs on each Linux distribution, scoped to one .NET version. NET version sits a `distros/` folder, and this skill manages it.json`, each with its install command and packages and no version field because the folder gives the version.

When should I use Update .NET Distro Packages?

Update .NET Distro Packages fits situations like: setting up the distros directory for a new .NET version; adding or removing a Linux distro release from the support matrix; updating dependency package names after a distro version change; auditing the package data to keep it current.

How do I install Update .NET Distro Packages in Claude Code?

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

How do I install Update .NET Distro Packages in Codex?

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

Can I use Update .NET Distro Packages 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 update-distro-packages -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/update-distro-packages, .gemini/skills/update-distro-packages, .github/skills/update-distro-packages and .opencode/skills/update-distro-packages in your project.

What does Update .NET Distro Packages need to run?

Going by SKILL.md and its folder, Update .NET Distro Packages needs the command-line tools its instructions call (curl, python3, apt-get, dotnet, git and wget) and credentials named PKGS_ORG_TOKEN. Our summary lists: The `release-notes` .NET global tool; A checkout of the .NET release-notes data; A pkgs.org Gold+ subscription and PKGS_ORG_TOKEN, only to update package availability.

Does Update .NET Distro Packages access the network?

SKILL.md names 7 domains. In commands or code: packages.ubuntu.com, nuget.pkg.github.com, bodhi.fedoraproject.org, src.fedoraproject.org and packages.microsoft.com; the agent is likely to contact these when it follows the instructions. As links in the text: pkgs.org and github.com. This is read from the text; nothing was executed.

Is Update .NET Distro Packages safe to install?

Our automated static check of SKILL.md found notes only (runs commands with sudo), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Update .NET Distro Packages use?

Update .NET Distro Packages 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 Update .NET Distro Packages use?

About 4.3k tokens (SKILL.md is roughly 17k 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 Update .NET Distro Packages?

Skills that share tags, products or a category with Update .NET Distro Packages: Dotnet Debugging (novotnyllc/dotnet-artisan, 233 stars), GitVersion .NET Development (GitTools/GitVersion, 3.1k stars), Dependency Updater (Asvarox/allkaraoke, 261 stars) and RStudio Copilot Language Server Updater (rstudio/rstudio, 5.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Update .NET Distro Packages?

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 7, 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.