New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Cross-Platform Cloud Verification

by warpdotdev in warpdotdev/warp

Picks the smallest useful set of cloud OS and architecture runners to verify a change after local checks pass, then fans out child runs and aggregates the results.

AGPL-3.0Auto-check passedTesting & QA

Install Cross-Platform Cloud Verification

skills CLI
$ npx skills add warpdotdev/warp --skill cross-platform-cloud-verification -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev/warp cross-platform-cloud-verification --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev/warp.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/cross-platform-cloud-verification .claude/skills/cross-platform-cloud-verification && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
cross-platform-cloud-verification
GitHub stars
65k
Used in
1 other repo
Token cost
~2.6k tokens
SKILL.md length
1,234 words
Files
1
Skills in repo
46
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Picks the smallest useful set of cloud OS and architecture runners to verify a change after local checks pass, then fans out child runs and aggregates the results.

  • Works in 8 steps: Establish the local verification gate → Delegate test design to verification… → Discover runners at execution time → …
  • A bug fix or build change that may behave differently on another operating system or CPU architecture
  • SKILL.md covers Workflow and Cost and scope guardrails
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This skill is the last verification layer, used only after cheaper checks pass because cloud runs consume remote compute and credits. First it finishes the local gate: build, focused tests, lint and type checks, fixing deterministic failures and confirming that the exact commit or branch can be checked out by cloud agents. It will not commit or push for you without authorization, and it skips cloud runs when the change is already broken locally.

It does not decide what to test. Instead it reads the other verification skills that apply (GUI computer-use, TUI, integration, unit, CI diagnosis, packaging) and merges their setup, commands, pass criteria and required captures into one shared procedure for each child run. Runners are discovered at run time with oz-dev runner list rather than hard-coded, and the agent then picks platforms, launches child agents and gathers what they report.

When your agent uses it

  • A bug fix or build change that may behave differently on another operating system or CPU architecture
  • Verifying native dependency, packaging or filesystem changes across platforms
  • Running a final cross-platform check after local tests pass
  • Deciding which runners are worth the credits for a given change

Example prompts

  • “Verify my branch fix-pty-resize on every platform that matters, now that local tests pass.”
  • “This packaging change touches native dependencies, so check it on the smallest set of cloud runners.”
  • “List the available cloud runners and pick the cheapest platforms that cover the filesystem change.”

Requirements

  • The Oz CLI (oz-dev) for runner discovery
  • run_agents support for remote.runner_id
  • A commit or branch that cloud agents can check out
  • Compatibility (from SKILL.md): Requires the Oz CLI (`oz-dev`) for runner discovery and `run_agents` support for `remote.runner_id`.

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Establish the local verification gate
  2. Delegate test design to verification skills
  3. Discover runners at execution time
  4. Infer the affected platform dimensions
  5. Select the minimal runner matrix
  6. Construct verification-only child prompts
  7. Launch with run_agents
  8. Aggregate without hiding gaps

What it can do on your machine

Read from SKILL.md and the folder at commit f571865. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    Requires the Oz CLI (`oz-dev`) for runner discovery and `run_agents` support for `remote.runner_id`.

    From compatibility in the SKILL.md frontmatter.

Context cost

Cross-Platform Cloud Verification loads about 2.6k tokens when it runs. Until then it costs about 129 tokens; SKILL.md has 1,234 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~129
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from warpdotdev/warp at commit f571865, republished under its AGPL-3.0 licence (© warpdotdev). 1,234 words, ~2,647 tokens.

Download SKILL.mdSave it as .claude/skills/cross-platform-cloud-verification/SKILL.md (or your agent's skills folder).
name
cross-platform-cloud-verification
description
Orchestrates cost-conscious cloud verification across available operating-system and architecture runners after cheaper checks pass. Use whenever a code change, bug fix, build, packaging flow, native dependency, UI behavior, filesystem behavior, or test has material cross-platform implications, even if the user only asks to verify or test the change. Consult domain verification skills for what to test; use this skill to choose and access the smallest relevant set of platforms.
compatibility
Requires the Oz CLI (`oz-dev`) for runner discovery and `run_agents` support for `remote.runner_id`.

Cross-platform cloud verification

Verify a change on the smallest useful set of cloud platforms. This skill owns runner discovery, platform selection, child orchestration, and result aggregation. It does not define the product-specific verification procedure.

Cross-platform execution consumes remote compute and credits, so use it as the last verification layer rather than as an exploratory first step.

Workflow

1. Establish the local verification gate

Finish the cheaper feedback loops first:

  1. Inspect the change and identify the behavior being verified.
  2. Run the relevant local build, focused tests, lint, type checks, or manual verification.
  3. Fix deterministic local failures before launching cloud runs.
  4. Confirm the exact commit or branch containing the change can be checked out by cloud agents. Do not test the default branch when the intended change is only local.

Do not commit or push changes merely to satisfy this workflow unless the user has authorized that action. If the change is not remotely reachable, report the precondition and ask for the minimum action needed.

Skip cloud fan-out when local verification already shows the change is broken. Do not use remote platforms as a substitute for diagnosing an ordinary local failure.

2. Delegate test design to verification skills

Inspect the available skill descriptions and read every skill that materially defines how to verify the affected surface. Examples include GUI computer-use verification, TUI live verification, integration testing, unit testing, CI diagnosis, packaging, or repository-specific validation.

Extract from those skills:

  • setup and authentication requirements
  • commands or interactions to perform
  • expected observations and pass criteria
  • required screenshots, recordings, logs, or text captures
  • platform-specific caveats

Build one shared verification procedure from that guidance. Tell each child which verification skill to read when it is available in the child environment, and include the essential procedure directly so the run remains actionable if the skill is unavailable there.

This skill decides where to run that procedure, not what the procedure should be.

3. Discover runners at execution time

List runners immediately before selecting platforms:

sh
oz-dev runner list --output-format json

Use the returned runner metadata rather than hard-coding names or IDs. Relevant fields include uid, name, os, arch, compute capacity, image or macOS version, and setup commands.

If runner discovery fails because of authentication, permissions, or service availability, report the blocker instead of inventing a runner matrix.

4. Infer the affected platform dimensions

Determine which dimensions the change can plausibly affect from the diff, repository configuration, reported bug, and verification guidance.

Treat the change as OS-sensitive when it touches or depends on items such as:

  • OS-gated code or platform modules
  • windowing, desktop integration, installers, packaging, or signing
  • shells, process creation, permissions, filesystems, paths, or line endings
  • OS-specific APIs, toolchains, or user-facing behavior

Treat the change as architecture-sensitive only with evidence such as:

  • architecture gates or assembly
  • unsafe code, FFI, ABI, alignment, endianness, or binary serialization
  • SIMD, native libraries, architecture-specific dependencies, or packaging
  • an architecture-specific bug report or explicit user requirement

Do not infer architecture sensitivity merely because both x86-64 and AArch64 runners exist.

5. Select the minimal runner matrix

Filter discovered runners to those that can execute the verification procedure, then apply these defaults:

  1. Select only affected operating systems.
  2. Select one representative runner per affected OS.
  3. Add another architecture for an OS only when the change is architecture-sensitive.
  4. Do not add an unaffected control platform by default.
  5. Deduplicate equivalent OS/architecture candidates.

When several runners cover the same platform, prefer in order:

  1. the exact OS/version/architecture from the bug report or target
  2. the repository's normal CI or release platform
  3. a runner whose image, setup, capacity, and tools match the procedure
  4. the lower-setup-cost candidate

For architecture-insensitive Linux changes, prefer the repository's primary Linux architecture; if the repository gives no signal, use x86-64 as the single representative.

Before launching, record a concise selection rationale and explicitly list relevant platforms omitted because no runner is available. Missing runners do not block useful verification on available relevant platforms.

State each omission once. After the matrix is decided, do not keep repeating that an irrelevant or redundant platform was not selected in child prompts, result rows, evidence, and the conclusion.

Show full SKILL.md (552 more words)Show less
6. Construct verification-only child prompts

Every child prompt should contain:

  • repository, branch, and exact commit to check out
  • selected runner name, OS, and architecture
  • verification skill names and the distilled procedure
  • setup and state preconditions
  • exact commands or interactions
  • expected results and required evidence
  • a prohibition on fixing or pushing code

Trust orchestration to route the child to the requested runner. Do not make every child re-confirm its OS and architecture. Ask for platform introspection only when the verification depends on an exact OS version or capability, or when there is evidence of a routing problem.

Ask each child to return:

text
Platform: <runner name; OS; architecture; version if relevant>
Commit: <tested SHA>
Status: <passed | failed | blocked>
Checks:
- <command or interaction>: <result>
Evidence:
- <artifact, screenshot, log, or concise observation>
Deviations:
- <difference from the requested procedure, or none>

Children may make temporary, uncommitted setup adjustments required by the verification skill, but they must report them and must not push source changes.

7. Launch with run_agents

Use run_agents so child IDs, messages, lifecycle events, and artifacts remain part of the parent orchestration flow. Use the same repository environment for every selected platform and set remote.runner_id to the discovered runner UID.

text
summary: Verifying the change on <OS/architecture>.
base_prompt: <shared verification-only instructions>
remote:
  environment_id: <repository environment ID>
  runner_id: <selected runner UID>
  computer_use_enabled: <true only when the verification procedure needs it>
agent_run_configs:
- name: <short platform-specific name>
  prompt: <platform-specific procedure and expected evidence>

If no suitable repository environment is already known, inspect oz-dev environment list and choose one that checks out the target repository. Do not silently create or mutate an environment.

remote.runner_id is run-wide, so runners with different UIDs require separate run_agents calls. Use one single-child batch per selected runner, or group multiple independently useful children only when they share the same runner and run-wide configuration. Distinct runner IDs are a legitimate reason for separate batches; do not place children for different platforms in one batch.

Omit model_id and remote.harness unless the user requested them. Attach relevant verification skills when the children need them. If an approved orchestration config is active, ensure its resolved runner matches the selected runner because config resolution takes precedence over call fields.

Capture each trusted agent_id from the launched result. Coordinate through pushed child messages and lifecycle events; do not poll oz-dev run get or list_messages_from_agents. Read notified messages, intervene only for a failure or actionable block, and use wait_for_events when no other work can proceed. Allow at most one retry for a clearly transient infrastructure failure. A product failure is evidence, not a reason to spend more credits repeating the same check.

8. Aggregate without hiding gaps

Wait for every launched child, then report:

text
Cross-platform verification: <passed | failed | incomplete>
Local gate: <checks completed before cloud launch>
Results:
- <OS/arch; runner>: <why selected> - <passed/failed/blocked>
Unverified:
- <relevant OS/arch>: unverified because no suitable runner was available

Evidence:
- <platform>: <commands, observations, and artifact/run links>

Conclusion:
- <what the results establish and what remains unverified>

Use passed only when every selected platform passed and no required platform is unavailable. Use failed when any verification check failed. Use incomplete when runs were blocked or a relevant platform lacked a runner.

Keep dry-run proposals and final summaries compact. Include the local gate, the selected matrix, one concise omission rationale when it is material, the verification procedure, and verdict rules. Do not repeat setup mechanics or platform exclusions in multiple sections. A dry-run proposal should usually fit in roughly 300-500 words; expand only when the domain verification procedure genuinely requires more detail.

Cost and scope guardrails

  • Run this workflow after local verification, not during implementation.
  • Choose platforms from evidence in the change, not from runner availability.
  • Keep one child per selected platform unless distinct state variants are independently necessary.
  • State runner-selection and omission decisions once.
  • Preserve negative results and platform gaps; do not broaden the matrix merely to obtain a passing result.
  • Do not let children implement fixes. Return failures to the parent workflow, fix locally, rerun cheap checks, and only then decide whether another cloud verification pass is justified.

© warpdotdev, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/cross-platform-cloud-verification of warpdotdev/warp.

Open the folder on GitHubat commit f571865

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in warpdotdev/warp, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Cross-Platform Cloud Verification next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Cross-Platform Cloud Verification compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cross-Platform Cloud Verification this skillwarpdotdev/warp65k1 repos~2.6kAutomated safety check: PassAGPL-3.0
Cicd Pipeline Qe Orchestratorproffesor-for-testing/agentic-qe494—~2.7kAutomated safety check: PassMIT
Prompt Generatorcatlog22/Claude-Code-Workflow2.1k1 repos~4.7kAutomated safety check: NotesMIT
Verify Tests Catch the Bugdotnet/maui23k—~2.7kAutomated safety check: PassMIT
cmux Testing Rulesdisler/learning-cmux-with-agents115—~1.2kAutomated safety check: PassMIT
Multi Agent Task Orchestratorsickn33/agentic-awesome-skills47k2 repos~1.5kAutomated safety check: PassMIT

Similar skills

  • Cicd Pipeline Qe Orchestrator

    proffesor-for-testing/agentic-qe

    Orchestrate quality engineering across CI/CD pipeline phases.

    494 GitHub stars~2.7k tokensUpdated 3 days ago
    Testing & QAAuto-check passed

  • Prompt Generator

    catlog22/Claude-Code-Workflow

    Generate or convert Claude Code prompt files — command orchestrators, skill files, agent role definitions, or style conversion of existing files.

    2.1k GitHub starsUsed in 1 repo~4.7k tokens
    Testing & QAAuto-check: notes

  • Verify Tests Catch the Bug

    dotnet/maui

    Official

    Confirms that newly added tests actually fail without the fix, auto-detecting UI, device, unit or XAML tests and running the matching runner.

    23k GitHub stars~2.7k tokensUpdated today
    Testing & QAAuto-check passed

  • cmux Testing Rules

    disler/learning-cmux-with-agents

    Testing rules for the cmux Swift codebase: Swift Testing as the default framework, a two-commit regression policy, and tests that check runtime behavior, not source text.

    115 GitHub stars~1.2k tokensUpdated 3 mo ago
    Testing & QAAuto-check passed

  • Multi Agent Task Orchestrator

    sickn33/agentic-awesome-skills

    Route tasks to specialized AI agents with anti-duplication, quality gates, and 30-minute heartbeat monitoring

    47k GitHub starsUsed in 2 repos~1.5k tokens
    Testing & QAAuto-check passed

  • Agent Team Orchestration

    aAAaqwq/AGI-Super-Team

    Orchestrate multi-agent teams with defined roles, task lifecycles, handoff protocols, and review workflows.

    105 GitHub starsUsed in 3 repos~1.4k tokens
    Testing & QAAuto-check passed

More from warpdotdev/warp

All 46 skills in this repo

  • Figma Design System Builder

    warpdotdev/warp

    Builds or updates a design system in Figma from a codebase in ordered phases: discovery, variables and tokens, components, theming and documentation, with checkpoints.

    65k GitHub starsUsed in 2 repos~4.4k tokens
    Auto-check passed

  • Figma use_figma Plugin API Rules

    warpdotdev/warp

    Required groundwork before any use_figma call: the rules and reference files for running JavaScript in a Figma file through the Plugin API without common failures.

    65k GitHub starsUsed in 4 repos~4.4k tokens
    Auto-check passed

  • Warp Factory Files

    warpdotdev/warp

    Authors and edits file-based Warp software factory definitions rooted at factory.yaml, covering agents, automations, scorers and webhooks, and validates them before a pull request.

    65k GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed

  • Figma Design to Code

    warpdotdev/warp

    Turns a Figma frame or component into production code that matches the design, using the Figma MCP server and the project's own design system.

    65k GitHub starsUsed in 4 repos~2.9k tokens
    Auto-check passed

  • Warp GUI to Agent CLI Migration

    warpdotdev/warp

    Migrates the compatible subset of settings and global file-based MCP servers from the Warp desktop app into Warp Agent CLI without exposing credentials or state.

    65k GitHub starsUsed in 1 repo~2.1k tokens
    Auto-check passed

  • Figma Design System Rules Generator

    warpdotdev/warp

    Creates project-specific design system rules from your codebase so coding agents implement Figma designs with your components, naming and tokens.

    65k GitHub starsUsed in 3 repos~4.6k tokens
    Auto-check passed

Categories

Questions about Cross-Platform Cloud Verification

What does Cross-Platform Cloud Verification do?

Picks the smallest useful set of cloud OS and architecture runners to verify a change after local checks pass, then fans out child runs and aggregates the results. This skill is the last verification layer, used only after cheaper checks pass because cloud runs consume remote compute and credits. First it finishes the local gate: build, focused tests, lint and type checks, fixing deterministic failures and confirming that the exact commit or branch can be checked out by cloud agents.

When should I use Cross-Platform Cloud Verification?

Cross-Platform Cloud Verification fits situations like: A bug fix or build change that may behave differently on another operating system or CPU architecture; verifying native dependency, packaging or filesystem changes across platforms; running a final cross-platform check after local tests pass; deciding which runners are worth the credits for a given change.

How do I install Cross-Platform Cloud Verification in Claude Code?

Run `npx skills add warpdotdev/warp --skill cross-platform-cloud-verification -a claude-code`. Or copy the skill folder (.agents/skills/cross-platform-cloud-verification in warpdotdev/warp) into .claude/skills/cross-platform-cloud-verification in your project. Claude Code loads it when a task matches its description.

How do I install Cross-Platform Cloud Verification in Codex?

Run `npx skills add warpdotdev/warp --skill cross-platform-cloud-verification -a codex`. Or copy the skill folder (.agents/skills/cross-platform-cloud-verification in warpdotdev/warp) into .agents/skills/cross-platform-cloud-verification in your project. Codex loads it when a task matches its description.

Can I use Cross-Platform Cloud Verification in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev/warp --skill cross-platform-cloud-verification -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cross-platform-cloud-verification, .gemini/skills/cross-platform-cloud-verification, .github/skills/cross-platform-cloud-verification and .opencode/skills/cross-platform-cloud-verification in your project.

What does Cross-Platform Cloud Verification need to run?

SKILL.md names no scripts, command-line tools or credentials: Cross-Platform Cloud Verification is instructions for the agent only. Our summary lists: The Oz CLI (oz-dev) for runner discovery; run_agents support for remote.runner_id; A commit or branch that cloud agents can check out. Compatibility (from SKILL.md): Requires the Oz CLI (`oz-dev`) for runner discovery and `run_agents` support for `remote.runner_id`..

Does Cross-Platform Cloud Verification access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Cross-Platform Cloud Verification safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Cross-Platform Cloud Verification use?

Cross-Platform Cloud Verification is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Cross-Platform Cloud Verification use?

About 2.6k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Cross-Platform Cloud Verification?

Skills that share tags, products or a category with Cross-Platform Cloud Verification: Cicd Pipeline Qe Orchestrator (proffesor-for-testing/agentic-qe, 494 stars), Prompt Generator (catlog22/Claude-Code-Workflow, 2.1k stars), Verify Tests Catch the Bug (dotnet/maui, 23k stars) and cmux Testing Rules (disler/learning-cmux-with-agents, 115 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cross-Platform Cloud Verification?

warpdotdev (a GitHub organization) maintains it in warpdotdev/warp, which has 65,380 GitHub stars. The repository holds 46 skills in this directory. The repository was last updated on October 7, 2026.

Source: warpdotdev/warp on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.