Executes integration tests to ensure SkiaSharp NuGet packages are functional before publishing.
Install
mkdir -p .claude/skills/release-testing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4569" && unzip -o skill.zip -d .claude/skills/release-testing && rm skill.zipInstalls to .claude/skills/release-testing
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
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".Key capabilities
- →Verify SkiaSharp NuGet packages
- →Run integration tests on multiple platforms
- →Execute tests on Android and iOS emulators
- →Check CI pipeline status
- →Validate rendering with screenshots
How it works
It automates the execution of integration tests across various device runtimes and verifies results against expected outputs.
Inputs & outputs
When to use release-testing
- →Testing packages before release
- →Verifying on Android emulator
- →Running cross-platform integration tests
About this skill
Release Testing
This skill is Step 3 of 5:
release-branch → release-status → release-testing → release-publish → release-milestones
Contract
- Run the read-only planner first and preserve its exact source commit, managed run, tests run, and paired package versions throughout testing.
- Obtain user approval for the matrix before preparation or execution.
- Test stable releases with exact
*-stable.{build}packages, never the future bare public version. - Execute every approved item once even when earlier items fail. A failed item blocks publication but does not stop collection of unrelated results.
- Never turn a failure into a skip or silently substitute a runtime, image, device, package version, or expected artifact.
- Each platform runner checks its own prerequisites and owns setup/cleanup. Do not manually duplicate its SDK, Appium, device, Docker, or test commands.
- Run mobile items sequentially. Runners must not delete user-owned devices.
- Invoke release-publish after every approved item and artifact check passes, unless the user explicitly overrides this gate. Record the override and proceed without investigating or challenging it.
- This skill never publishes packages, creates tags/releases, or merges code.
Fixed matrix
| ID | Coverage | Host |
|---|---|---|
smoke | Native loading | All |
console | Console and HarfBuzzSharp | All |
linux | Linux packages in Docker | All |
blazor | Native WASM in Chromium | All |
android-26 | Minimum Android test target | All |
android-37.1 | Maximum Android test target | All |
maccatalyst | Mac Catalyst rendering | macOS |
ios-18.6 | Minimum iOS test target | macOS |
ios-26.5 | Maximum iOS test target | macOS |
windows | MAUI Windows rendering | Windows |
iOS 18.6 and Android 26 are minimum release-test targets, not product support minimums. Exact mobile targets must already be installed. Missing or host-inapplicable coverage must be explicit in the approved plan.
Script contract
| Script | Responsibility |
|---|---|
scripts/plan-release-tests.py | Read-only release-status handoff and exact host matrix. |
scripts/prepare-test-run.py | Restore pinned local tools and clear prior integration output once. |
scripts/run-host-tests.py | Smoke, console, Docker/Linux, Blazor, Mac Catalyst, and Windows host items. |
scripts/run-android-tests.py | Android environment, Appium, temporary/reused emulator, test, and cleanup. |
scripts/run-ios-tests.py | Fresh iOS simulator, Appium test, and cleanup. |
scripts/release_test_common.py | Shared versions, heartbeat execution, validation, package arguments, and test invocation. |
Planner actions:
nextAction | Response |
|---|---|
approve-test-matrix | Present and obtain approval. |
wait-for-tests-trigger / wait-for-tests | Return to release-status, unless the user explicitly overrides only this wait with --allow-incomplete-ci. |
retry-tests | Investigate/retry failed CI tests; never override them here. |
| Anything else | Return to release-status. |
Use setup.md for prerequisites, monitoring.md for live progress, and troubleshooting.md only after failures.
Workflow
1. Plan and approve
python3 .agents/skills/release-testing/scripts/plan-release-tests.py \
{release-branch-or-commit}
If readyToPlan is false, report nextAction and stop. Otherwise render:
## Release test plan
**Release:** `{release.branch}`
**Commit:** `{release.commit}`
**Managed/tests runs:** `{release.managedRunId}` / `{release.testsRunId}`
**Packages:** SkiaSharp `{test version}`, HarfBuzzSharp `{test version}`
**Host:** `{host.os}` / `{host.architecture}`
| ID | Test | Target | Estimate |
|----|------|--------|----------|
| `{id}` | `{label}` | `{target}` | `{estimatedMinutes}` min |
Include every missingCoverage[] and release warning. Use ask_user:
Run the full available matrix (Recommended)Customize the matrixCancel release testing
Confirm the exact final IDs after customization.
2. Prepare once
python3 .agents/skills/release-testing/scripts/prepare-test-run.py
3. Collect every result
For each approved item, run its emitted command sequentially:
- Show the exact command and the full pending/running/passed/failed table.
- Run it in a visible terminal canvas; use an attached async shell only when the canvas is unavailable.
- Relay new
[release-test]output and refresh done/failed/remaining state every five seconds. Never launch a duplicate command after a delayed read. - Record duration, failure phase, diagnostics, artifacts, and result.
- Continue after failure once runner-owned cleanup finishes.
4. Repair and retry
After all initial attempts, present the complete failure inventory and group shared root causes. Apply only concrete, safe environment repairs, then retry affected failed items. Ask before installing/upgrading software, changing permissions, or touching user-owned devices. Preserve initial failures and all retry outcomes.
Product assertions and rendering differences remain failures; do not alter expectations, skips, or package pins to make them pass.
5. Report the gate
Review expected screenshots under output/logs/testlogs/integration/. The final
report must include:
- Immutable release/run/package identity.
- Every approved ID with initial, repair, retry, and final result.
- Missing or intentionally omitted coverage.
- Screenshot paths and review status.
Proceed to release-publish when all final results and artifact checks pass, or when the user explicitly overrides the gate.
When not to use it
- →When CI builds have not completed
- →When hardware for specific tests is unavailable
Prerequisites
Limitations
- →Requires specific hardware or emulators
- →Fails the entire release on any test failure
How it compares
It automates the entire cross-platform test matrix and CI verification process instead of manual verification.
Compared to similar skills
release-testing side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| release-testing (this skill) | 1 | 1mo | Review | Advanced |
| agent-production-validator | 3 | 6mo | Review | Advanced |
| validate-delivery | 1 | 5mo | Review | Beginner |
| documenso-ci-integration | 1 | 27d | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by mono
View all by mono →You might also like
agent-production-validator
ruvnet
Agent skill for production-validator - invoke with $agent-production-validator
validate-delivery
avifenesh
Use when validating task completion before shipping. Runs tests, build, and requirement checks. Returns pass/fail with fix instructions.
documenso-ci-integration
jeremylongshore
Configure CI/CD pipelines for Documenso integrations. Use when setting up automated testing, deployment pipelines, or continuous integration for Documenso projects. Trigger with phrases like "documenso CI", "documenso GitHub Actions", "documenso pipeline", "documenso automated testing".
smoke-check
hoatv2211
Run core path smoke validation before QA handoff or merge.
aidlc-build
aws-samples
Final integration build and test verification. Validates that implemented code compiles, passes all test suites, and meets quality gates before deployment.
release-bump
himatts
Prepare versioned release updates for Lime Pipeline. Use when user-visible behavior changes require bumping `bl_info["version"]`, updating `CHANGELOG.md`, and producing release-ready QA notes.