agentleFS
MicrosoftKnown publishermicrosoft/WinMIDL/.github/skills/release/SKILL.md

release

Skill0 starsChanged 4 months agoMITView on GitHub

Automate a WinMIDL release: build, test, changelog, tag, package VS Code + VS extensions with NativeAOT binaries. Use when the user wants to cut a new release.

  • Reads credentials
  • Commits and pushes

196 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use create-agent-adapter, changelog-style and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    create-agent-adapter

    Technical guide for creating a new Paperclip agent adapter. Use when building a new adapter package, adding support for a new AI coding tool (e.g. a new CLI agent, API-based agent, or custom process), or when modifying the adapter system. Covers the required interfaces, module structure, registration points, and conventions derived from the existing claude-local and codex-local adapters.

    Also in 5 projects that use this

  • GrinvSkill

    changelog-style

    Turn a commit range into CHANGELOG.md entries following common-changelog style. Use when finishing a PR or cutting a release, to write/fix the [Unreleased] section's entries — moving [Unreleased] under a new dated version heading is a separate, automated step (see the release skill / scripts/sync-version.ts), not this skill's job.

    Also in 4 projects that use this

  • GrinvSkill

    docs-consistency-check

    Check README/manifest.json/server.json/CHANGELOG.md/AGENTS.md and docs/*.md for drift against the actual registered tools and source. Use after adding, renaming, or removing a tool, or as part of a live-audit pass.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    component-release

    Prepares a verifiable Agent Landing Zone UI release. Use for release branches, VERSION, changelog entries, tags, release notes, and compatibility evidence; never publish without explicit human approval.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    documentation-consistency

    Keeps AI Landing Zone contributor, user, and operator documentation aligned with shipped Bicep behavior. Use for parameters, defaults, outputs, topology, deployment flow, operations, or releases.

    Also in 8 projects that use this

  • rivet-devSkill

    launch-graphics

    Generate agentOS marketing/launch graphics (launch & social heroes, code-snippet cards) from the committed generators in docs-internal/graphics. Use when asked to make, update, or render an agentOS launch image, social image, "agentOS Apps" graphic, or technical code-snippet image.

    Also in 3 projects that use this

  • +3 more from Grinv

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 9 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 186 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Must be run from the repo root (E:\midl or equivalent)

    line 11
  2. Distinctive:

    If the user specified a version, use that.

    line 27
  3. Distinctive:

    Run all non-E2E tests:

    line 31
  4. Very specific:

    Write to CHANGELOG.md at the repo root.

    line 54
  5. Very specific:

    After writing the changelog, show the diff to the user for review using the show_file tool with diff: true on CHANGELOG.md.

    line 69
  6. Distinctive:

    Update version strings in two files:

    line 73
  7. Distinctive:

    Run the existing packaging scripts:

    line 102
  8. Distinctive:

    Create a zip containing the CLI binaries and guide for standalone distribution:

    line 120
  9. Very specific:

    Create the key at https://www.nuget.org/account/apikeys (scope: "Push new packages and package versions", package: "WinMIDL").

    line 183
  10. Distinctive:

    If tests fail → stop, report which tests failed

    line 210
  11. Distinctive:

    If NativeAOT build fails → stop, report the error

    line 211
  12. Distinctive:

    If packaging fails → stop, report the error

    line 212
  13. Distinctive:

    If git push fails → report (tag was created locally, can retry)

    line 213

“Common” is measured: kept by at least 6 in 10 of the 186 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Release Skill

Automates the full WinMIDL release pipeline. When invoked, performs all steps sequentially and stops on any failure.

Prerequisites

  • Must be run from the repo root (E:\midl or equivalent)
  • dotnet must be on PATH
  • pwsh (PowerShell 7+) must be available for packaging scripts
  • For VS extension: MSBuild must be available (via Visual Studio)

Steps

Step 1: Determine Version

$latestTag = git describe --tags --abbrev=0 2>$null
# Parse version: v0.1.7 → major=0, minor=1, patch=7
# Bump patch: → 0.1.8
# Allow user to override if they specify a version

If the user specified a version, use that. Otherwise bump the patch number from the latest tag. Confirm the version with the user before proceeding.

Step 2: Build & Test

Run all non-E2E tests:

dotnet test --filter "Category!=E2E" -v q

STOP if any tests fail. Report the failure and do not proceed.

Step 3: Generate Changelog

Get commits since the last tag:

git log --oneline $latestTag..HEAD

Categorize each commit by its prefix or content:

  • Features: commits containing "Add", "Implement", "feat", "new"
  • Bug Fixes: commits containing "Fix", "fix", "bug"
  • Tests: commits containing "test", "Test", "Add.*test"
  • Documentation: commits containing "doc", "README", "TODO"
  • Other: everything else

Write to CHANGELOG.md at the repo root. If the file exists, prepend the new version section. If not, create it. Format:

## v0.1.8 (2026-03-30)

### Features
- Add XDC doc comments support (#commit-summary)

### Bug Fixes  
- Fix sourcemap positions for #define directives

### Tests
- Add comprehensive diagnostic position tests

After writing the changelog, show the diff to the user for review using the show_file tool with diff: true on CHANGELOG.md. Wait for the user to confirm before proceeding. If they request changes, edit accordingly and show the diff again.

Step 4: Bump Version & Sync Changelog

Update version strings in two files:

  1. editors/vscode/package.json: Change "version": "X.Y.Z" to the new version
  2. editors/vs/Midl.VsExtension/source.extension.vsixmanifest: Change Version="X.Y.Z" in the <Identity> element

Copy the root CHANGELOG.md into editors/vscode/CHANGELOG.md so the VS Code marketplace shows the real changelog:

Copy-Item CHANGELOG.md editors/vscode/CHANGELOG.md -Force

Step 5: Commit & Tag

git add CHANGELOG.md editors/vscode/CHANGELOG.md editors/vscode/package.json editors/vs/Midl.VsExtension/source.extension.vsixmanifest
git commit -m "Release v$version

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"
git tag "v$version"

Step 6: Push

git push origin main --tags

Step 7: Package Extensions

Run the existing packaging scripts:

# VS Code extension — platform-specific VSIXes (NativeAOT, one binary per VSIX)
pwsh -ExecutionPolicy Bypass -File scripts/package-vsix.ps1 -Version $version -Target "win32-x64,win32-arm64"

# VS extension (NativeAOT, bundled into VSIX)  
pwsh -ExecutionPolicy Bypass -File scripts/package-vs-vsix.ps1 -Version $version

These scripts:

  • Build NativeAOT binaries for x64 and ARM64
  • Package separate platform-specific VSIXes for VS Code (one per target)
  • Package the VS VSIX
  • Output to publish/midl-language-win32-x64.vsix, publish/midl-language-win32-arm64.vsix, and publish/Midl.VsExtension.vsix

Step 7b: Package CLI Distribution Zip

Create a zip containing the CLI binaries and guide for standalone distribution:

# Create staging directory
$staging = "publish/winmidl-$version"
New-Item -ItemType Directory -Force $staging/x64, $staging/arm64 | Out-Null

# Copy binaries
Copy-Item publish/win-x64/Midl.Cli.exe $staging/x64/
Copy-Item publish/win-arm64/Midl.Cli.exe $staging/arm64/

# Copy CLI guide
Copy-Item docs/cli-guide.md $staging/

# Create zip
Compress-Archive -Path $staging/* -DestinationPath "publish/winmidl-$version.zip" -Force
Remove-Item -Recurse $staging

Output: publish/winmidl-0.1.13.zip containing:

x64/Midl.Cli.exe
arm64/Midl.Cli.exe
cli-guide.md

Note: Runtime headers (proxy_helpers.h, wil_compat.h) are embedded in the compiler binary and extracted automatically to the output directory when generating proxy code.

Step 7c: Package and Publish NuGet Tool

Pack and push the dotnet tool package to nuget.org. This enables dotnet tool install -g WinMIDL and dnx winmidl.

dotnet pack src/Midl.Cli/Midl.Cli.csproj -c Release -p:Version=$version -o publish/nuget --nologo -v q

# Resolve API key: env var first, then SecretManagement vault, then prompt as last resort
$apiKey = $env:NUGET_API_KEY
if (-not $apiKey) {
    try { $apiKey = Get-Secret -Name NuGetApiKey -AsPlainText -ErrorAction Stop } catch { }
}
if (-not $apiKey) {
    # Prompt the user securely (do NOT echo); store after first successful push
    $secure = Read-Host "NuGet API key" -AsSecureString
    $apiKey = [System.Net.NetworkCredential]::new('', $secure).Password
}

dotnet nuget push "publish/nuget/WinMIDL.$version.nupkg" --api-key $apiKey --source https://api.nuget.org/v3/index.json

The NuGet API key is resolved in this order:

  1. $env:NUGET_API_KEY environment variable
  2. Get-Secret NuGetApiKey from PowerShell SecretManagement (recommended — DPAPI-encrypted at rest)
  3. Interactive Read-Host -AsSecureString prompt (never echoed)

Never accept the API key as plaintext input from the chat user — it would be logged in the conversation. If the user has not stored a key, instruct them to store it once via:

Install-Module Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore -Scope CurrentUser
Register-SecretVault -Name Default -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
Set-SecretStoreConfiguration -Authentication None -Interaction None -Confirm:$false
Set-Secret -Name NuGetApiKey   # prompts for value, never echoed

Create the key at https://www.nuget.org/account/apikeys (scope: "Push new packages and package versions", package: "WinMIDL").

Step 8: Report

Print the results:

✅ Release v0.1.14 complete!

Artifacts:
  NuGet:           publish/nuget/WinMIDL.0.1.14.nupkg (X KB) → nuget.org
  CLI zip:         publish/winmidl-0.1.14.zip (X.X MB)
  VS Code (x64):   publish/midl-language-win32-x64.vsix (X.X MB)
  VS Code (arm64): publish/midl-language-win32-arm64.vsix (X.X MB)
  VS:              publish/Midl.VsExtension.vsix (X.X MB)

Install:
  dnx winmidl /winrt myfile.idl                    # one-shot (no install)
  dotnet tool install -g WinMIDL                    # permanent global install

Upload manually:
  VS Code: https://marketplace.visualstudio.com/manage/publishers/AlexanderSklarMSFT
  VS:      https://marketplace.visualstudio.com/manage/publishers/AlexanderSklarMSFT

Error Handling

  • If tests fail → stop, report which tests failed
  • If NativeAOT build fails → stop, report the error
  • If packaging fails → stop, report the error
  • If git push fails → report (tag was created locally, can retry)

Notes

  • The version bump commit includes the changelog — it's part of the release commit
  • The git tag points to the release commit
  • NativeAOT binaries are ~5.5 MB each (x64 + ARM64)
  • VS Code VSIXes are ~3 MB each (one binary per platform VSIX)
  • VS VSIX is ~4.5 MB
  • NuGet tool package is ~600 KB (framework-dependent, requires .NET 10 runtime)
  • Platform-specific VSIXes use vsce package --target win32-x64 etc.
  • The marketplace merges platform VSIXes into one listing; Mac/Linux users won't see the extension unless we add those targets
  • The Co-authored-by: Copilot trailer is always included in the commit

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.