// Create a release branch for SkiaSharp. Use when user says "release X", "start release X", "create release branch for X", "I want to release", or "release now". This is the FIRST step of releasing - creates branch and pushes to trigger CI. Can auto-detect next preview version from main branch.
Check the CI build health and automation status of SkiaSharp across main and recent release branches. Collects the last N builds from the AzDO pipeline chain (Public + Native → Managed → Tests) and all GitHub Actions workflows from mono/SkiaSharp and mono/SkiaSharp-API-docs, providing a daily dashboard view with AI-powered analysis of failures, regressions, and flakes. Use when user asks to: - Check overall CI health - See build status across branches - Get a daily CI summary - Check if main is green - See recent build failures - Monitor branch health - Identify flaky tests or chronic failures - Determine if a release branch is shippable - Check GitHub Actions workflow health - See what automation is failing Triggers: "CI status", "build health", "is main green", "CI dashboard", "daily build status", "check builds", "are builds passing", "CI overview", "pipeline health", "branch build status", "CI report", "why is CI red", "what automation is failing", "GitHub Actions status".
Audit SkiaSharp's native dependencies for security vulnerabilities and CVEs, including Component Governance (CG) alerts from the SkiaSharp-Native and SkiaSharp Azure DevOps pipelines. Read-only investigation that produces a status report with recommendations. Use when user asks to: - Audit security issues or CVEs - Check CVE status across dependencies - Find security-related issues and their PR coverage - Get an overview of open vulnerabilities - See what security work is pending - Check Component Governance alerts - Review CG alerts from the native build pipeline Triggers: "security audit", "audit CVEs", "CVE status", "what security issues are open", "check vulnerability status", "security overview", "what CVEs need fixing", "CG alerts", "component governance", "check container CVEs". This skill is READ-ONLY. To actually fix issues, use the `native-dependency-update` skill.
Fix bugs in SkiaSharp C# bindings. Structured workflow for investigating, fixing, and testing bug reports. Triggers: Crash, exception, AccessViolationException, incorrect output, wrong behavior, memory leak, disposal issues, "fails", "broken", "doesn't work", "investigate issue", "fix issue", "look at #NNNN", any GitHub issue number referencing a bug. For adding new APIs, use `api-add-review` skill instead.
Publish SkiaSharp packages and finalize the release. Use when user says "publish X", "finalize X", "tag X", or "finish release X". This is the FINAL step - after release-testing passes. Publishes to NuGet.org, creates tag, GitHub release, and closes milestone. Triggers: "publish the release", "push to nuget", "create github release", "tag the release", "close the milestone", "annotate release notes", "testing passed what's next", "finalize 3.119.2", "release is ready".
Check the status of a SkiaSharp release build pipeline chain. Use when user asks to: - Check release build status - See where the release pipeline is at - Track CI progress for a release - Find out if packages are ready - Get ADO build links for a release Triggers: "check release status", "how is the build", "where is the release", "pipeline status", "is the build done", "check CI", "how is the run doing", "are packages ready", "build progress". This is Step 2 of 4 in the release pipeline — after release-branch creates the branch and before release-testing runs integration tests.
Run integration tests to verify SkiaSharp NuGet packages work correctly before publishing. Use when user asks to: - Test/verify packages before release - Run integration tests - Test on specific device (iPad, iPhone, Android emulator, Mac, Windows) - Verify SkiaSharp rendering works - Check if packages are ready for publishing - Run smoke/console/blazor/maui tests - Continue with release - Test version X Triggers: "test the release", "verify packages", "run tests on iPad", "check ios tests", "test mac catalyst", "run android tests", "continue", "test 3.119.2-preview.2".
| name | release-branch |
| description | Create a release branch for SkiaSharp. Use when user says "release X", "start release X", "create release branch for X", "I want to release", or "release now". This is the FIRST step of releasing - creates branch and pushes to trigger CI. Can auto-detect next preview version from main branch. |
Create release branches for SkiaSharp versions.
⚠️ NO UNDO: This is Step 1 of 4 in the release pipeline. See releasing.md for full workflow.
Pipeline: Step 1 (this skill) → Step 2: release-status → Step 3: release-testing → Step 4: release-publish
🛑 NEVER commit directly to
mainorskiasharpbranches. This is a policy violation.
| Repository | Protected Branches | Required Action |
|---|---|---|
| SkiaSharp (parent) | main | Create release/X.Y.Z branch, never commit to main |
| externals/skia (submodule) | main, skiasharp | Must use feature branch if submodule changes needed |
Release branches are created FROM main, but never modify main directly.
SKIASHARP_VERSION from scripts/azure-templates-variables.ymlgit branch -r | grep "release/{version}-preview"release/{version} branch exists — if it does, the stable release is already cut and you should NOT create another preview. Ask the user to confirm.X.Y.Z-preview.N. Proceed?"Use the provided version directly.
⚠️ Semver ordering: A bare version X.Y.Z is ALWAYS newer than X.Y.Z-preview.N. When listing
branches to find the latest, remember that release/3.119.2 > release/3.119.2-preview.3.
Do NOT use alphabetical sorting — it gives wrong results for semver.
| Version Format | Type | Base | PREVIEW_LABEL |
|---|---|---|---|
X.Y.Z-preview.N | Preview | main | preview.N |
X.Y.Z | Stable | release/X.Y.Z-preview.{latest} | stable |
X.Y.Z.F-preview.N | Hotfix Preview | tag vX.Y.Z | preview.N |
X.Y.Z.F | Hotfix Stable | release/X.Y.Z.F-preview.{latest} | stable |
For stable releases, find latest preview: git branch -r | grep "release/X.Y.Z-preview" | sort -V | tail -1
NuGet version format by release type:
{base}-{PREVIEW_LABEL}.{build} (e.g., 3.119.2-preview.2.3) — build number is part of the prerelease tag{base} only (e.g., 3.119.2) — the build number is NEVER appended to stable versions. On the internal feed, stable builds appear as {base}-stable.{build} but the published version is just {base}.release/{version}scripts/azure-templates-variables.yml: set PREVIEW_LABELgit commit -m "Bump the version to {version}"ask_user before pushinggit push -u origin release/{version}
This triggers the CI pipeline chain (2-4 hours total):
SkiaSharp-Native → SkiaSharp → SkiaSharp-Tests
(~60-90 min) (~30-60 min) (~15-30 min)
Use the release-status skill to track build progress. Quick check:
python3 .agents/skills/release-status/scripts/pipeline-status.py release/{version}
Skip for stable and hotfix releases.
Create branch bump-version-{next} from main
Edit scripts/azure-templates-variables.yml:
SKIASHARP_VERSION to next versionPREVIEW_LABEL to preview.0Edit scripts/VERSIONS.txt:
SkiaSharp file → {next}.0SkiaSharp ... nuget lines → {next}HarfBuzzSharp file → increment 4th digit (e.g., 8.3.1.4 → 8.3.1.5)HarfBuzzSharp ... nuget lines → same as file versionCommit: git commit -m "Bump to the next version ({next}) after release"
Show diff to user, then:
git push -u origin bump-version-{next}
gh pr create --title "Bump to the next version ({next}) after release" --body ""
gh pr merge --merge --delete-branch