Run any Skill in Manus with one click

$pwd:

release-branch

Name: Release Branch
Author: mono

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

Run Skill in Manus

$ git log --oneline --stat

stars:5,419

forks:630

updated:May 24, 2026 at 16:19

SKILL.md

readonly

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.

Release Branch Skill

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

⚠️ Branch Protection (COMPLIANCE REQUIRED)

🛑 NEVER commit directly to main or skiasharp branches. 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.

Step 1: Determine Version

Auto-detect (user says "release now")

Fetch main and read SKIASHARP_VERSION from scripts/azure-templates-variables.yml
List existing branches: git branch -r | grep "release/{version}-preview"
Next preview = highest + 1 (or 1 if none)
⚠️ Semver check: Also verify no bare 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.
Confirm with user: "Next release will be X.Y.Z-preview.N. Proceed?"

User provides version

Use the provided version directly.

Step 2: Determine Release Type

⚠️ 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:

Preview: {base}-{PREVIEW_LABEL}.{build} (e.g., 3.119.2-preview.2.3) — build number is part of the prerelease tag
Stable: {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}.

Step 3: Create Branch and Update PREVIEW_LABEL

Checkout the base (main, preview branch, or tag)
Create branch release/{version}
Edit scripts/azure-templates-variables.yml: set PREVIEW_LABEL
Commit: git commit -m "Bump the version to {version}"
Show diff summary to user and confirm with ask_user before pushing

Step 4: Push Branch

git 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}

Step 5: Bump Version on Main (Preview from main only)

Skip for stable and hotfix releases.

Create branch bump-version-{next} from main
Edit scripts/azure-templates-variables.yml:
- Update SKIASHARP_VERSION to next version
- Reset PREVIEW_LABEL to preview.0
Edit scripts/VERSIONS.txt:
- SkiaSharp file → {next}.0
- All SkiaSharp ... nuget lines → {next}
- HarfBuzzSharp file → increment 4th digit (e.g., 8.3.1.4 → 8.3.1.5)
- All HarfBuzzSharp ... nuget lines → same as file version
Commit: 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

Resources

releasing.md — Version patterns, HarfBuzz versioning, workflow diagrams

related-skills.json

same repository

ci-status.md

from "mono/SkiaSharp"

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

2026-05-295.4k

security-audit.md

from "mono/SkiaSharp"

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.

2026-05-295.4k

issue-fix.md

from "mono/SkiaSharp"

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.

2026-05-275.4k

release-publish.md

from "mono/SkiaSharp"

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

2026-05-245.4k

release-status.md

from "mono/SkiaSharp"

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.

2026-05-245.4k

release-testing.md

from "mono/SkiaSharp"

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

2026-05-245.4k

package.json

"author": "mono"

"repository": "mono/SkiaSharp"

View GitHub Repository View Creator Repositories

$ install --global

$ download --local

Run Skill in Manus

$ useful --forSOC

Software DevelopersComputer and Mathematical Occupations15-1252L4

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.

Release Branch Skill

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

⚠️ Branch Protection (COMPLIANCE REQUIRED)

🛑 NEVER commit directly to main or skiasharp branches. 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.

Step 1: Determine Version

Auto-detect (user says "release now")

Fetch main and read SKIASHARP_VERSION from scripts/azure-templates-variables.yml
List existing branches: git branch -r | grep "release/{version}-preview"
Next preview = highest + 1 (or 1 if none)
⚠️ Semver check: Also verify no bare 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.
Confirm with user: "Next release will be X.Y.Z-preview.N. Proceed?"

User provides version

Use the provided version directly.

Step 2: Determine Release Type

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:

Preview: {base}-{PREVIEW_LABEL}.{build} (e.g., 3.119.2-preview.2.3) — build number is part of the prerelease tag
Stable: {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}.

Step 3: Create Branch and Update PREVIEW_LABEL

Checkout the base (main, preview branch, or tag)
Create branch release/{version}
Edit scripts/azure-templates-variables.yml: set PREVIEW_LABEL
Commit: git commit -m "Bump the version to {version}"
Show diff summary to user and confirm with ask_user before pushing

Step 4: Push Branch

git 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}

Step 5: Bump Version on Main (Preview from main only)

Skip for stable and hotfix releases.

Create branch bump-version-{next} from main
Edit scripts/azure-templates-variables.yml:
- Update SKIASHARP_VERSION to next version
- Reset PREVIEW_LABEL to preview.0
Edit scripts/VERSIONS.txt:
- SkiaSharp file → {next}.0
- All SkiaSharp ... nuget lines → {next}
- HarfBuzzSharp file → increment 4th digit (e.g., 8.3.1.4 → 8.3.1.5)
- All HarfBuzzSharp ... nuget lines → same as file version
Commit: 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

Resources

releasing.md — Version patterns, HarfBuzz versioning, workflow diagrams

release-branch

Release Branch Skill

⚠️ Branch Protection (COMPLIANCE REQUIRED)

Step 1: Determine Version

Auto-detect (user says "release now")

User provides version

Step 2: Determine Release Type

Step 3: Create Branch and Update PREVIEW_LABEL

Step 4: Push Branch

Step 5: Bump Version on Main (Preview from main only)

Resources

More from this repository

More from this repository

Release Branch Skill

⚠️ Branch Protection (COMPLIANCE REQUIRED)

Step 1: Determine Version

Auto-detect (user says "release now")

User provides version

Step 2: Determine Release Type

Step 3: Create Branch and Update PREVIEW_LABEL

Step 4: Push Branch

Step 5: Bump Version on Main (Preview from main only)

Resources