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 skills add SummerRiversound/expo-launchpad --skill expo-launchpad-evaluatorgit clone --depth 1 https://github.com/SummerRiversound/expo-launchpadWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/summerriversound/expo-launchpad/expo-launchpad-evaluator)<a href="https://agentmods.dev/skills/summerriversound/expo-launchpad/expo-launchpad-evaluator"><img src="https://agentmods.dev/badge/skills/summerriversound/expo-launchpad/expo-launchpad-evaluator/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/summerriversound/expo-launchpad/expo-launchpad-evaluator"><img src="https://agentmods.dev/badge/skills/summerriversound/expo-launchpad/expo-launchpad-evaluator.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00045 | $0.06841 |
| Opus 5 | $0.00023 | $0.03420 |
| Sonnet 5 | $0.00009 | $0.01368 |
| Haiku 4.5 | $0.00005 | $0.00684 |
Grade A, and why
expo-launchpad-evaluator scanned grade A with 0 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 11d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 520 lines — stays where its author put it; the contents beside it link to each section on GitHub.
expo-launchpad-evaluator
Phase A, step 6 of the expo-launchpad pipeline. Skeptical QA gate that decides PASS or FAIL against
the negotiated contract. Default mode runs the functional check (6.1) only; --strict adds
quality scoring (6.2) and an agent-team edge-case sweep (6.3).
All file schemas (config.md, state.md, contract.md, handoff/round-N-gen.md,
feedback/round-N-qa.md, build-log.md/pipeline-log.md) and the phase transition table are
defined in docs/harness-protocol.md — that document is the single source of truth (§2 for
state.md; §3 for contract.md; §4 for handoff layout; §5 for feedback layout; §6 for log
schemas; §7 for the evaluator → generator / evaluator → paused transitions). Do not redefine
schemas here. Every platform-robustness pattern (R1–R11) is defined once in docs/app-gotchas.md
— cite it; do not restate the patterns.
Critical Rule
"Run the code, see the app, then judge." Never PASS on code review alone. Execute commands, launch the app on a simulator, drive the core flow, capture and study screenshots. Stub detected = automatic FAIL, no exceptions.
Setup — Read Inputs
Workspace root vs. project directory
docs/harness/ lives at the workspace root (the directory the pipeline was invoked from) for
the entire pipeline — it is never inside the generated project. Before any other step, capture the
workspace root once:
ROOT="$(pwd)"
From this point on, every harness file (state.md, config.md, contract.md, handoff/*,
feedback/*, pipeline-log.md, build-log.md, screenshots/*) is read/written at the
root-absolute path "$ROOT/docs/harness/..." — never a path relative to whatever directory the
shell happens to be in at the time. ROOT is fixed once, the same way <app_slug> and <N> are:
treat it as a value substituted verbatim into every command below, not a live shell variable that
needs to survive between separate tool invocations.
The generated Expo project lives in its own subdirectory, "$ROOT/<app_slug>/". Only
build/test/run commands (tsc --noEmit, expo lint, jest, expo run:ios, Maestro) cd into
<app_slug>/ — that cd is scoped to those commands only and never affects where harness files
are written. Never write into <app_slug>/docs/harness/.
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.
- 11d ago First seen · 520 lines · 45 tokens per session scan A f47b7ae9106d
expo-launchpad-evaluator is a skill published in the GitHub repository SummerRiversound/expo-launchpad (2 stars, last pushed 1mo ago), licensed MIT. It adds 45 tokens to every session and 6,841 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
Appium Mobile Testing
Mobile application testing skill using Appium for iOS and Android, covering device capabilities, selectors, gestures, and cross-platform testing strategies.
zmr-mobile-testing
Use when testing mobile apps with Zeno Mobile Runner, integrating app-local .zmr setup, driving Android or iOS simulator scenarios, using JSON-RPC or MCP agent sessions, exporting traces, or comparing mobile runner benchmarks.
playwright-for-android
End-to-end Android debug loop on an emulator. Builds the APK with a Gradle task, boots a named AVD, installs and launches the target package, then drives a single feature via adb-injected UI actions while capturing a unified logcat-and-actions timeline plus a developer-facing test report. Use when the user wants to…
aco
Drive a live Appium session from the shell with the aco CLI. Use when the user wants to interact with a running mobile app on an iOS simulator, Android emulator, or connected real device — tap, swipe, type, screenshot, read the screen/page source, find UI elements, switch to a WebView context, or call iOS/Android…
mobile-developer
Expert in React Native, Expo, and cross-platform mobile development.
maestro-mobile-testing
Maestro mobile E2E testing patterns for React Native/Expo apps: YAML test flows, testID selectors, adaptive auth state, optimistic update verification, GraalJS scripting, cross-platform stability, CI/CD integration, Maestro Cloud, and MCP server integration.