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
- zxcvbn-ts/zxcvbntheir own version, first seen Nov 9, 2026
- TechbeeAT/jtxBoardtheir own version, first seen Nov 9, 2026
- ddnexus/pagytheir own version, first seen Nov 9, 2026
- zerx-lab/FluxDowntheir own version, first seen Nov 9, 2026
- orioledb/orioledbtheir own version, first seen Nov 9, 2026
- AmruthPillai/Reactive-Resumetheir own version, first seen Nov 8, 2026
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.
MicrosoftSkillcreate-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
GrinvSkillchangelog-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
GrinvSkilldocs-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 AzureSkillcomponent-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 AzureSkilldocumentation-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-devSkilllaunch-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
Other versions196 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 196
- paperclipai/paperclip★ 112ksame name
- modelcontextprotocol/servers★ 92ksame name
- remotion-dev/remotion★ 72ksame name
- traefik/traefik★ 65ksame name
- usememos/memos★ 64ksame name
- tw93/Pake★ 63ksame name
- AmruthPillai/Reactive-Resume★ 45ksame name
- amruthpillai/reactive-resume★ 45ksame name
- reactive-resume/reactive-resume★ 45ksame name
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
186 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
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
- Very specific: line 11
Must be run from the repo root (E:\midl or equivalent)
- Distinctive: line 27
If the user specified a version, use that.
- Distinctive: line 31
Run all non-E2E tests:
- Very specific: line 54
Write to CHANGELOG.md at the repo root.
- Very specific: line 69
After writing the changelog, show the diff to the user for review using the show_file tool with diff: true on CHANGELOG.md.
- Distinctive: line 73
Update version strings in two files:
- Distinctive: line 102
Run the existing packaging scripts:
- Distinctive: line 120
Create a zip containing the CLI binaries and guide for standalone distribution:
- Very specific: line 183
Create the key at https://www.nuget.org/account/apikeys (scope: "Push new packages and package versions", package: "WinMIDL").
- Distinctive: line 210
If tests fail → stop, report which tests failed
- Distinctive: line 211
If NativeAOT build fails → stop, report the error
- Distinctive: line 212
If packaging fails → stop, report the error
- Distinctive: line 213
If git push fails → report (tag was created locally, can retry)
“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.
Files
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:\midlor equivalent) dotnetmust be on PATHpwsh(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 versionIf 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 qSTOP 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..HEADCategorize 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 testsAfter 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:
editors/vscode/package.json: Change"version": "X.Y.Z"to the new versioneditors/vs/Midl.VsExtension/source.extension.vsixmanifest: ChangeVersion="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 -ForceStep 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 --tagsStep 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 $versionThese 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, andpublish/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 $stagingOutput: publish/winmidl-0.1.13.zip containing:
x64/Midl.Cli.exe
arm64/Midl.Cli.exe
cli-guide.mdNote: 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.jsonThe NuGet API key is resolved in this order:
$env:NUGET_API_KEYenvironment variableGet-Secret NuGetApiKeyfrom PowerShell SecretManagement (recommended — DPAPI-encrypted at rest)- Interactive
Read-Host -AsSecureStringprompt (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 echoedCreate 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/AlexanderSklarMSFTError 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-x64etc. - 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: Copilottrailer is always included in the commit
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
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.

