Prompt library

Copy-paste prompts for the jobs agents most often run on PreviewAPK. Replace the bracketed bits ([path], [device name], [ticket]) before pasting.

Ground rules every prompt assumes (they're in the agent skill): select the working device first and never guess one; read the screen with look / the hierarchy and verify visuals by screenshot; use wait / wait_for after anything that loads instead of sleeping; read the logs after anything unexpected; never blindly repeat an action whose outcome came back unknown; when a step needs the human (a credential, a 2FA code, a payment approval), ask with request-human / previewapk_request_human and wait for the handback — never guess credentials and never ask for one in chat; file the wrap-up (finish / previewapk_finish) at the end of every job and relay its message verbatim; file the field report at the end too (unless the account's diagnostics sharing is off — then don't, and don't try to route around it); stop the session when finished.

1. Smoke check on a new build

Smoke-check the build I just made, on PreviewAPK.

1. List the devices and select [device name]. Push
   [path/to/app.apk] and start a session with driver=agent. Poll
   status until the device is live.
2. Read the screen (look / hierarchy). Confirm the app's first screen
   appears and name the element that proves it. Take a screenshot and
   confirm the screen renders correctly (no clipping, overlap, or
   blank areas).
3. Walk the main path: tap through the primary flow a first user
   would take — [describe it in one line, e.g. "sign up later →
   create a note → save"]. Before each tap, read the screen; after
   each tap, read it again to confirm the screen changed the way it
   should. Tap fields with --field N / by label, and type only after
   the field is focused.
4. Read the session logs with errors only. If there is a crash or an
   error, quote the exact lines — don't paraphrase them.
5. Report: PASS or FAIL, the screens you visited, anything that
   looked wrong in a screenshot, and any log errors verbatim. File a
   PreviewAPK field report, then stop the session.

A good result looks like: a one-paragraph verdict with screen names, one screenshot per key screen, and either "no errors in the log" or the exact error lines.

2. Exploratory session

Explore my app on PreviewAPK like a curious first-time user.

Push [path/to/app.apk] to [device name], start agent-driven, and
wait until live. Then explore for up to [10] minutes of session time:

- Start from the first screen. Systematically visit every reachable
  screen: bottom tabs, menus, settings, dialogs. Use the screen
  snapshots as your map — note screens you reach and elements you
  used.
- On each screen, try the obvious interactions: open and dismiss,
  scroll lists to the bottom, submit an empty form once — just what
  a user would poke at.
- After anything surprising, read the logs (errors only) and take a
  screenshot of the surprising state before moving on.
- If you reach a sign-in, payment, or consent step that needs my
  real credentials, do NOT invent credentials and do NOT ask me to
  paste a password or code into this chat: ask me with
  request-human "the app is asking for [the step]" (MCP:
  previewapk_request_human), relay its message_for_human to me
  word for word, then wait for the handback (wait --for driver)
  and continue from the handback note.
- Dead ends count as findings: buttons that do nothing, back
  behavior that exits the app (note it — relaunch recovers), labels
  that are missing or confusing.

Report: a map of the screens you found, the issues ranked
most-severe first (each with the screen, what you did, what
happened, and the log lines if any), and what you could not reach.
File a field report, then stop.

3. Reproduce a bug report

Reproduce this bug report on PreviewAPK and tell me if it's real:

    [paste the ticket: expected vs actual, steps if known]

1. Push the build named in the ticket (or [path/to/app.apk] if it
   names none) to [device name], start agent-driven, wait for live.
2. Follow the ticket's steps literally, in order. Read the screen
   before and after each step, and quote the screen text you
   actually saw at each step — not what the ticket assumed.
3. The moment the reported behavior appears — or clearly diverges
   from the ticket — take a screenshot of that exact state and read
   the logs (errors only, around that moment). Quote crash/error
   lines verbatim.
4. If a step can't be performed as written (missing element,
   different label, extra dialog), say which step and what the
   screen showed instead; then take the closest reasonable path and
   flag that you deviated.

Report one of: REPRODUCED (with the exact steps as performed, the
screenshot, and the log evidence), DOES NOT REPRODUCE (with what
happened instead at the diverging step), or BLOCKED (what's
missing). File a field report, then stop.

4. Accessibility pass

Run an accessibility pass over my app on PreviewAPK.

Push [path/to/app.apk] to [device name], start agent-driven, and
visit the main screens: [list them, or "every tab and the primary
flow"].

Work from the UI hierarchy — it is your evidence:

- Every tappable element (click flag) should carry a label: a text
  or a desc (content-description). List every clickable element that
  has NEITHER, with its class, bounds, and screen. (On
  Flutter/semantics UIs, labels live in desc — check there before
  calling an element unlabeled.)
- Icon-only buttons are the usual suspects: check each one for a
  meaningful desc, and quote the vague ones ("button", "image", a
  bare filename) verbatim.
- Check form fields: each input should be reachable and tappable by
  its position (--field N order), and its purpose should be
  inferable from a nearby label in the tree. List fields whose
  purpose you cannot determine from the hierarchy.
- Take a screenshot of each main screen and flag text that is
  visually clipped, overlapping, or rendered too small to read at a
  glance.

Be honest about the limits: this pass audits the labels and
structure a screen reader consumes; it is not a TalkBack walkthrough
and it doesn't test dynamic font scaling. Say so in the report.

Report: findings per screen, worst first, each with the element's
class/bounds and the exact missing or vague label. File a field
report, then stop.

5. Before-a-release checklist

Run the pre-release check on this build on PreviewAPK.

Build: [path/to/app.apk] · Device: [device name] · The change in
this release: [one line].

1. Install & first launch. Push and start agent-driven. The app
   reaches its first screen with no crash; read the hierarchy to
   confirm, screenshot to confirm it renders.
2. The changed flow. Drive the flow named above end-to-end. Verify
   each step on screen, screenshot the result screen.
3. Core regression sweep. Re-run the basics: [list your 3–5 core
   flows, e.g. "open an existing item, create a new one, search,
   open Settings and back"]. Note any step that behaves differently
   from the obvious expectation.
4. Back behavior. Press Back (key 4) from the deepest screen, one
   step at a time, until you reach the first screen. Note any step
   where Back exits the app unexpectedly (recover with relaunch) or
   lands somewhere surprising.
5. Logs. Read the full session log (not just errors). Quote any
   stack traces verbatim; summarize warnings in one line each.
   Ignore lines flagged as emulator noise.
6. Fresh-start honesty. This phone starts fresh every session —
   nothing here proves upgrade behavior from the previous version's
   data. If the release needs an upgrade-path check, say that this
   run does not cover it.
7. No-Play-services note. If any flow touches Google sign-in, Maps,
   or push, note that it cannot be verified on these phones.

Report: a checklist table — item, PASS/FAIL, evidence (screen name,
screenshot, or log line). End with a ship / don't-ship
recommendation and the top reason. Hand the wheel to me (handoff
user), give me the session link so I can look myself, file a field
report — and leave the session running for my look unless I told you
to stop it.

6. A flow with a human step — and the wrap-up

Test the [flow name] flow on PreviewAPK, on [device name] with
[path/to/app.apk]. The flow includes a step only I can do:
[describe it, e.g. "approving the test payment" / "entering the
2FA code from my authenticator"].

Drive the flow up to that step. When you reach it:

1. Ask me for the step — previewapk request-human "the app is
   asking for [the step]" (MCP: previewapk_request_human) —
   and relay the message_for_human it returns to me word for
   word. Do not ask me for any password or code in this chat; I
   will type it on the phone myself.
2. Wait for the handback (previewapk wait --for driver / MCP
   previewapk_wait_for with condition driver). Read my handback
   note when it comes back, then continue the flow to the end and
   verify the result on screen.

When the job is done, wrap up: previewapk finish --summary "[what
you tested and what you found]" --verdict [passed|failed|mixed]
(MCP: previewapk_finish) and relay its message_for_human to me
word for word — the counts in it come from the server, not from
your memory. Leave the session running (finish does not stop it)
unless I told you to stop it. File a field report too.