Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/mobile-dev-inc/maestro/releasenpx skills add mobile-dev-inc/Maestro --skill releasegit clone --depth 1 https://github.com/mobile-dev-inc/MaestroWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00066 | $0.05526 |
| Opus 5 | $0.00033 | $0.02763 |
| Sonnet 5 | $0.00013 | $0.01105 |
| Haiku 4.5 | $0.00007 | $0.00553 |
Grade C, and why
release scanned grade C with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Downloads and executes remote codehighSupply chain
curl | sh runs whatever the server returns today, which is not necessarily what it returned when this was reviewed.
PATH="$NOBREW" HOME="$TMP" MAESTRO_DIR="$TMP/.maestro" bash -c 'curl -Ls "https://get.maestro.mobile.dev" | bash' Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
PATH="$NOBREW" HOME="$TMP" MAESTRO_DIR="$TMP/.maestro" bash -c 'curl -Ls "https://get.maestro.mobile.dev" | bash' How it starts
The opening of the file, as written. The whole thing — 314 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Maestro
This is the release doc for the Maestro repo. There is no other one: RELEASING.md points here.
Policy
- The commit you release must already have been deployed to Maestro Cloud and run there for about a day. How that happens is not this repo's business; maintainers know. The skill asks you to confirm it and takes your word.
- Two human checkpoints. The version is a judgment call and it gets baked into the changelog, both
gradle.properties, the branch, the commit, the PR title, and the tag — so you confirm it before any of that is written (Checkpoint 1). Then everything is drafted into a PR, and you say go once (Checkpoint 2); after that the skill merges, tags, publishes the CLI, and verifies without asking again. Nothing lands onmainbefore Checkpoint 2. - Checkpoint 2 comes after the PR is approved and required checks are green.
mainrequires one approving review and passing required checks (the e2e suite is one). The checklist asks you to get both before you say go; the skill checks them once and merges — it doesn't wait or poll. - Propose the version, don't ask for it. Read the commits since the last release and recommend a bump with the Semver rubric. The human confirms or overrides at Checkpoint 1; they own the call, the skill just does the arithmetic and makes the case.
- Don't wait for Maven Central. Pushing the tag triggers
publish-release.yaml; it runs on its own and the CLI publish doesn't depend on it. - Don't announce.
publish-cli.yamlmakes jreleaser publish a GitHub release;notify-release-comms.ymlfires on that andmobile-dev-inc/release-commsDMs the releaser to start the announcement flow. - Downstream is not described here. Maestro Cloud and Studio pick up the tag through their own processes.
Inputs
| Input | Default | Notes |
|---|---|---|
version |
propose | The skill proposes X.Y.Z (no v) from the commits since the last tag using the Semver rubric, and you confirm or override at Checkpoint 1. If the invocation names a version, use it — but still map the commits and flag a mismatch at Checkpoint 1 (e.g. the number says minor, the commits are all fixes). |
sha |
origin/main HEAD |
Always print the resolved full sha. It must equal origin/main HEAD. It's here so you can confirm which commit is being released, not so you can pick an older one. |
dry-run |
off | Only when the invocation explicitly says "dry run". Never offer it as an option or ask about it. In dry-run the skill drafts locally and stops at Checkpoint 2, then runs Dry-run cleanup; it never pushes, opens a PR, tags, or dispatches a workflow. |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 314 lines · 66 tokens per session scan C ff9931b8ff70
release is a skill published in the GitHub repository mobile-dev-inc/Maestro (15,456 stars, last pushed 4d ago), licensed Apache-2.0. It adds 66 tokens to every session and 5,526 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it C with 2 findings (downloads and executes remote code, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
flutter-cherry-pick
How to land a formal cherry-pick of a merged PR for the flutter/flutter repo stable or beta channel. Only use for flutter/flutter landed pull requests. Only use when the cherry pick request is into "stable", "beta" or a branch that has the format with flutter- . -candidate.0.
updating-android-sdk
Upgrades Flutter's Android SDK dependency to a new Android API version (or preview/canary release) in packages.txt, verifies CIPD tag uniqueness, and packages/uploads the binaries using createcipdpackages.sh across macOS, Linux, and Windows. Use whenever a user wants to pick up a new version of Android or upload…
flutter-pr-checks-finder
Find failing checks on a Flutter PR and locate the corresponding LUCI log URLs.
analyze-github-flake
Expertise in analyzing flake github issues in the flutter/flutter repository. Use when a user wants to analyze the flakiness of a specific link to a flutter github issue.
upgrade-browser
Upgrade browser versions (Chrome or Firefox) in the Flutter Web Engine and/or Framework tests. Use when asked to roll or upgrade Chrome or Firefox to a newer version.
run-devicelab-with-led
Run DeviceLab tests for Flutter PRs using LUCI's led CLI tool. Use when asked to run, launch, try, or deflake a post-submit or devicelab test against a PR using led.