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 makifbaysal/tasktrooper --skill mobile-manual-testinggit clone --depth 1 https://github.com/makifbaysal/tasktrooperWrote 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/makifbaysal/tasktrooper/mobile-manual-testing)<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/mobile-manual-testing"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/mobile-manual-testing/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/makifbaysal/tasktrooper/mobile-manual-testing"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/mobile-manual-testing.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.00041 | $0.00935 |
| Opus 5.5 | $0.00016 | $0.00374 |
| Sonnet 5.5 | $0.00008 | $0.00187 |
| Haiku 4.5 | $0.00004 | $0.00093 |
Grade A, and why
mobile-manual-testing scanned grade A with 1 finding 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 8d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
3. **The API side of every flow.** Most mobile criteria are "the app shows X after calling Y": call Y yourself with curl against the task branch's backend or the stage target, and verify the payload the app would render. How it starts
The opening of the file, as written. The whole thing — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Mobile Manual Testing
Overview
A mobile task is verified from the outside like any other: you run something and observe what it does. The mobile_* tools are registered only when a device is actually attached. With them, the device flow below is mandatory. Without them, use the build+API ceiling further down — and be exact in your report about what sits above that ceiling.
Never approve a criterion because the code looks right. An untestable criterion is reported, not passed.
1. Is a device here?
Check your tool list for mobile_launch_app. If it's there, a real device is attached and the device flow is not optional.
2. Confirm the build is the task's
mobile_launch_app installs the deploy target's registered app_url (default env=stage) — not automatically this task's branch. Before launching, check list_deployments / get_pipeline_status shows the stage build was produced from this task's PR head (the stage deploy triggers asynchronously when the task enters ready_for_qa). If it doesn't match yet, wait for it rather than testing the previous build; if it never arrives, report that instead of guessing.
3. Device flow
mobile_launch_app (installs the confirmed build and takes the device) → mobile_wait_for → mobile_tap/mobile_type_text/mobile_swipe → mobile_read_ui for state a picture cannot show → mobile_screenshot per criterion. For every UI criterion, capture the device matrix: mobile_screenshot portrait plus mobile_rotate then mobile_screenshot landscape at minimum, and font-scale/dark variants too where the host exposes them — the same standard as the web four-width check, adapted to what a device can actually set. Evidence is one line per screen (bug-report-writing's format): what it shows, no invented file path.
mobile_release_device is your last mobile step, always — a task left holding the device blocks whoever's next in the queue.
If a mobile_* call reports the device is in use: stop. Your task is parked and resumes by itself when the phone frees up; do not retry and do not fall back to guessing.
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.
- 8d ago First seen · 47 lines · 41 tokens per session scan A a66b8c10b6c1
mobile-manual-testing is a skill published in the GitHub repository makifbaysal/tasktrooper (113 stars, last pushed yesterday), licensed Apache-2.0. It adds 41 tokens to every session and 935 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-05.
Other skills, from other repositories
qa-acceptance
Produce QA acceptance criteria and a manual validation plan for a feature change — golden path, edge cases, error states, performance limits, and explicit pass/fail evidence.
android-emulator
Verify and debug native, React Native, Expo, or Flutter apps on an Android Emulator with agent-device. Use when an agent needs to launch an app, inspect its live UI, tap, type, scroll, validate a code change, collect failure evidence, or reproduce a workflow on an Android virtual device.
dogfood
Systematically explore and test a mobile app on iOS/Android with agent-device to find bugs, UX issues, and other problems. Use when asked to dogfood, QA, exploratory test, find issues, bug hunt, or test this app on mobile.
jetson-video-pipeline
Use when planning, executing, and independently validating Jetson Video Codec SDK or PyNvVideoCodec encode/decode, transcode, segmentation, container decode, AV1, or concise acceptance workflows.
qa-testing-android
Designs Android testing with Espresso, UI Automator, Robolectric, and Compose. Use when planning device matrices, emulator CI, Compose test migration, screenshots, or flakes.
proof-e2e
Build E2E test specs for critical user journeys — Playwright or Cypress, page objects, setup/teardown, CI config. Use when asked to "write E2E tests", "end-to-end testing", "browser tests", "UI tests", or "Playwright tests".