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/theperu/appium-pilot/skilldatanpx skills add theperu/appium-pilot --skill skilldatagit clone --depth 1 https://github.com/theperu/appium-pilotWrote 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/theperu/appium-pilot/skilldata)<a href="https://agentmods.dev/skills/theperu/appium-pilot/skilldata"><img src="https://agentmods.dev/badge/skills/theperu/appium-pilot/skilldata.svg" alt="Measured on agentmods" 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 | $0.00081 | $0.03102 |
| Opus 5 | $0.00041 | $0.01551 |
| Sonnet 5 | $0.00016 | $0.00620 |
| Haiku 4.5 | $0.00008 | $0.00310 |
Grade A, and why
appium-pilot 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 3d 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 — 267 lines — stays where its author put it; the contents beside it link to each section on GitHub.
appium-pilot
A stateful, session-based CLI for driving a native mobile app. One verb per invocation; session state persists between calls (the Appium server holds the live session). Output is tuned for you to read.
The core loop
appium-pilot open ...once to start a session.appium-pilot snapshotto see the screen as filtered XML withref="eN"ids.- Act on a ref:
appium-pilot tap e7,appium-pilot type e3 "hello", etc. - Re-
snapshotafter anything that changes the screen — refs are only valid until the next snapshot. Acting on a stale ref fails with exit code 2 and the message "run snapshot again".
Starting a session
# Installed Android app (auto-picks a booted emulator, else boots one)
appium-pilot open --platform android --app-package com.example.app
# iOS Simulator app bundle, or an installed app by bundle id
appium-pilot open --platform ios --app /path/to/MyApp.app
appium-pilot open --platform ios --bundle-id com.apple.Preferences
# Target a specific device; add capabilities
appium-pilot open --platform ios --bundle-id com.x --device "iPhone 16"
appium-pilot open --platform android --app-package com.x --cap appium:noReset=true
Platform is inferred from --bundle-id (ios), --app-package (android), or the
app file extension; otherwise pass --platform.
--cap values are coerced (true/false → bool, digits → int). To force a
string, quote the value: --cap 'platformVersion="17"' keeps it as "17".
Inspecting
appium-pilot snapshot # filtered XML + refs (use this, not --raw, by default)
appium-pilot snapshot --raw # full unfiltered page source (when filtered hides something)
appium-pilot snapshot --bounds # add each element's center as at="x,y" (feed tap --at / a screenshot)
appium-pilot source # raw page source, no refs
appium-pilot screenshot # save PNG, prints path — then Read the file to view it
appium-pilot screenshot e7 # screenshot just one element
appium-pilot find "Login" # just the refs of elements whose visible text matches
appium-pilot find "OK" --case-sensitive # exact case (default is case-insensitive)
appium-pilot get e3 # a ref's current state, e.g. text="hi" enabled=true
appium-pilot get e3 bounds # read one raw attribute (bounds, focused, ...)
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.
- 3d ago First seen · 267 lines · 0 tokens per session scan A 1ebdf50ce2b4
appium-pilot is a skill published in the GitHub repository theperu/appium-pilot (4 stars, last pushed 1mo ago), licensed MIT. It adds 81 tokens to every session and 3,102 once invoked, about $0.0004 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
noqa-testing
Use this skill when the user wants to boot and interact with iOS or Android devices/simulators — inspect the screen, execute actions, generate or edit test cases, or run UI tests via the noqa platform.
Appium Mobile Testing
Mobile application testing skill using Appium for iOS and Android, covering device capabilities, selectors, gestures, and cross-platform testing strategies.
agentic-a11y
Use when auditing a user-facing app — web, mobile (iOS/Android/React Native/Flutter), desktop, CLI, or games — for accessibility barriers or WCAG 2.2 conformance, before shipping UI changes, or in response to concerns about screen-reader, keyboard, low-vision, motor, cognitive, or photosensitive users. Not for general…
run-automation-suite
Run local Appium test scripts against Kobiton devices. Guides through app upload, device selection, capability parsing, and local execution. Use when the user asks to run mobile tests, validate an APK or IPA on Kobiton devices, or kick off an Appium suite from a local script directory. Trigger with "run kobiton tests"…
use-mobile-device
Drive iOS and Android devices using the mobile-device-mcp tools (screenshot, tap, uitree, scroll, typetext, runcode, etc.). Use when MCP device-control tools are available and the user wants to interact with a mobile device.
drive-automation-session
Drive an already-reserved Kobiton device from a natural-language intent. Opens an automation Appium session directly against the Kobiton WebDriver hub, runs an observe-decide-act loop with one action per iteration, pauses to ask the user when stuck (same-action repetition, screen unchanged, or model self-declared…