agent-easy-use/mobile-easy-use

# Android Observable Code

Keep observability changes small and local to the requested work. Reuse existing logs and identifiers; preserve behavior and avoid adding dependencies or observability layers.

## Key-flow logs

- Add logs only at useful flow boundaries: entry, important branches, completion, and failure. For asynchronous work, log the actual outcome, not just task submission.
- Use a stable, exact TAG; put event names and relevant outcome values in the message. `Log.d(TAG, "...")` is a simple option. Existing logging wrappers are suitable when their output reaches Android `liblog` with that TAG, which Mobile Easy Use captures.
- Keep logs sparse and free of sensitive data. Ensure they remain enabled in the build used for inspection.

## UI identifiers

- Give relevant native Views stable resource IDs, such as `R.id.form_submit`. Reuse existing IDs; distinguish repeated elements within their parent scope.
- Mobile Easy Use also supports string View tags through `tag::` paths. Reuse suitable existing tags without overwriting tags used by application logic.

# iOS Observable Code

Keep changes local and preserve behavior. Reuse existing logs, identifiers, and runtime entry points; avoid new dependencies or observability layers.

## Key-flow logs

- Log key flow boundaries and outcomes, including asynchronous completion. Keep logs sparse, free of sensitive data, and enabled in the inspected build.
- Use `NSLog` with a stable literal `[TAG] ` prefix, event, and relevant values:

  ```swift
  NSLog("[Form] completed count=%ld", results.count)
  ```

  ```objc

# Integrate MobileEasyUse into Android

Complete the integration, report the changes, and ask whether to verify. Verification covers building, installation, launch, connection, and probing.

## Acquire the artifact

Before editing the target project, run `node scripts/ensure-artifacts.mjs`, resolving the script path relative to this `SKILL.md`. The script requires Node.js 20 or newer and works on Windows, macOS, and Linux. It:

- fetches the live compatibility catalog for the current run;
- reuses a complete matching artifact in `~/.meu`;
- otherwise downloads the Android Maven archive, verifies it against `SHA256SUMS`, and extracts it;
- prints one JSON object containing the selected Release, paths, compatible MCP range, and exact version-pinned MCP command.

If the JSON result contains `actionRequired: "confirm-update"`, report the cached and latest Release versions and ask whether to update. Run again with `--update` when accepted or `--use-cached` when declined. Preserve a Release already pinned in the project unless the user accepts an upgrade; select it with `--version <version>`.

# To Android Presets

Build reusable App capabilities for Test and Probe. Presets provide actions, state access,
and scoped condition setup; callers own evidence collection, test registration, and assertions.

## Generation rules

Call `get_sdk_declarations({"platform":"android"})` and read the required SDK, bridge, and Gum
contracts. Reuse only the relevant rules from the probe-script references:

- [Driver](../to-android-probe-script/references/driver-generation.md): navigation, UI interactions, and business flows.
- [Override](../to-android-probe-script/references/override-generation.md): return definitions for callers to scope, or accept an action and return/await `Override.run`. Restore changes when the action settles.
- [Direct Frida](../to-android-probe-script/references/direct-frida-generation.md): native state reads, internal calls, and condition setup.

# To Android Probe

Turn one natural-language Android runtime question into a generated probe, one controlled execution, and an evidence-backed answer. Keep code generation and execution details hidden unless the user asks for them.

## Workflow

1. Read the complete sibling `../to-android-probe-script/SKILL.md` and follow its generation contract.
2. Read the complete sibling `../to-android-run/SKILL.md` and follow its connection and execution contract.
3. Resolve the requested target, starting scene, allowed interactions, and required chain, state, or UI evidence. Inspect the target App source and existing presets when symbols or navigation steps are unknown; never guess them. Ask only when missing information makes execution unsafe or materially ambiguous.
4. Use `to-android-probe-script` to generate the smallest probe that answers the original question. Use a task-specific directory under the workspace `artifacts/` for Module output unless the user supplies another directory.
5. Use `to-android-run` to execute exactly one generated Inline operation or one Module export. Preserve its single-operation and no-unsafe-retry rules.
6. After execution returns, inspect its result and only the evidence files it returned. Read only the references matching the returned evidence types: [chain](references/chain-evidence.md), [state](references/state-evidence.md), or [UI](references/ui-evidence.md).
7. Relate observed runtime events to original App source, distinguish observed facts from source-based inference, and decide whether the question is answered.
8. If it is not answered, revise and execute another probe only when doing so is safe. Do not automatically retry a failed or timed-out operation that may have mutated App state; first restore or confirm a known starting scene.

# To Android Probe Script

Generate the smallest Android runtime code that answers the requested runtime question. Prefer Driver for requested user-visible actions, use Override only when normal App configuration or Driver actions cannot establish a required condition, add Evidence only when needed to answer the question, and use Direct Frida only when the encapsulated capabilities are insufficient. Driver, Override, Evidence, and Direct Frida can compose within their API boundaries; use only what the question requires and avoid unnecessary probing. Generate code only; do not connect to a device or execute it.

## Before generating code

Call `get_sdk_declarations({"platform":"android"})` to obtain declaration paths in `files[].path`. It returns `sdk` (platform SDK), `bridge` (Frida Java bridge), and `gum` (native Frida APIs) declarations. The capability sections below specify which declarations to read.

Resolve `presets.directory` from `<project-root>/.meu/config.json`
relative to the project root, defaulting to `.meu/presets`. If `<base-directory>/android/`
contains `presets.dist.js`, read `presets.entry.js` to identify public exports and the
corresponding feature `index.d.ts` files for their contracts. Prefer reusing capabilities that
satisfy the request; import only names exported by the entry, including any aliases.

# To Android Run

Run exactly one supplied Android operation. Require `appId`; accept optional canonical ADB `deviceId` and device-side `runtimePort`, defaulting to 8484. Accept exactly one execution form:

1. `source`: one complete `(async () => { ... })()` expression.
2. `scriptPath + functionName`: one named Module export.
3. `scriptPath + naturalDescription`: read the matching `probe.d.ts` completely and select exactly one export. Stop on no match, ambiguity, or missing required arguments.

Optional positional `args` apply only to Module. Do not convert between Inline and Module. If code is missing, first use `to-android-probe-script`.

## Target

Run `adb devices -l`. Eligible targets are entries in state `device` that are either running emulators or physical devices with a USB transport. Exclude wireless, offline, and unauthorized entries.

# To Android Test

Accept a natural-language request such as “run the click tests under this directory.” Resolve the scope, recursively find test files, and execute them one by one through [to-android-run](../to-android-run/SKILL.md).

## Workflow

1. Resolve the App, directory, and requested behavior from the request and session. Default to the App's `tests/`; clarify only material ambiguity.
2. Recursively discover files with `rg --files`. Read test modules to identify relevant tests and starting/cleanup conditions. Exclude helpers, deduplicate paths, and sort by path. State the selected files, then proceed; report no matches without claiming success.
3. Read and follow `to-android-run`, using its `scriptPath + functionName` form: pass each module's absolute `scriptPath`, `functionName: "run"`, and `args: []`. Reuse the same target and MCP session; invoke each file once and await completion before the next file. No `.d.ts` is needed.
4. Continue after assertion failures when cleanup succeeded and the next starting conditions are established. Stop on cleanup failure, disconnect, operation timeout, or uncertain App state; mark remaining files unrun. Do not automatically retry or modify tests.

## Result

Show results in the reply first: list the first 10 cases in execution order (all cases if fewer), using ✅ for passed, ❌ for failed, and ⏭ for not run. Include the file and case name; briefly explain failures. Keep execution errors distinct from assertion failures.

# To Android Test Script

Compose Driver, Override, Expect, and Direct Frida into repeatable tests. Reuse `to-android-probe-script` generation rules for actions and observations; compare observations with expectations through the collection's `expect`. Generate files only; do not connect or execute.

## Before generating code

- Call `get_sdk_declarations({"platform":"android"})`. Read `Test` and the required SDK APIs; read returned `bridge` declarations for Java work and `gum` for native Frida work.
- Resolve scenes, targets, and observations from App source. Derive expectations from requirements or confirmed behavior; clarify missing expectations that determine pass or fail.
- Reuse presets: resolve `presets.directory` in `.meu/config.json` (default `.meu/presets`), read the Android entry and relevant feature `index.d.ts` declarations, and import declared exports from `/meu/presets.js`.

## 1. Driver

Drive the App into the target scene and perform the tested interactions, following [Driver generation](../to-android-probe-script/references/driver-generation.md). Default to starting from home; put shared navigation in `beforeEach` and case-specific actions in `test`.

# Integrate MobileEasyUse into iOS

## Acquire the artifacts

Before editing the target project, run `node scripts/ensure-artifacts.mjs`, resolving the script path relative to this `SKILL.md`. The script requires Node.js 20 or newer and downloads on Windows, macOS, and Linux. It fetches the live compatibility catalog, verifies `SHA256SUMS`, and installs both archives under `~/.meu/ios/<version>`:

- `integration` contains the App integration binaries and scripts;
- `runner` contains the XCTest runner and runtime used by MobileEasyUse.

If the JSON result contains `actionRequired: "confirm-update"`, report the cached and latest Release versions and ask whether to update. Run the script again with `--update` when accepted or `--use-cached` when declined. Preserve a Release already pinned by the project unless the user accepts an upgrade; select it with `--version <version>`. A normal result contains `releaseVersion`, `integrationPath`, `runnerPath`, `minimumMcpVersion`, `maximumMcpVersion`, and an exact `mcpCommand`.

Use `MEU_HOME` to override `~/.meu`. Artifacts and checksums are downloaded directly from the public GitHub Release; no GitHub token or login is required. The selected Release's catalog range defines MCP compatibility. Stop and report acquisition, catalog, or checksum errors.

Artifact acquisition is cross-platform. Xcode project changes, building, signing, and runtime verification require macOS; on Windows or Linux, finish the download, report both cache paths, and explain that the integration phase must continue on macOS.

# To iOS Presets

Build reusable App capabilities for Test and Probe. Presets provide actions, state access,
and scoped condition setup; callers own evidence collection, test registration, and assertions.

## Generation rules

Call `get_sdk_declarations({"platform":"ios"})` and read the required SDK, bridge, and Gum
contracts. Reuse only the relevant rules from the probe-script references:

- [Driver](../to-ios-probe-script/references/driver-generation.md): navigation, UI interactions, and business flows.
- [Override](../to-ios-probe-script/references/override-generation.md): return definitions for callers to scope, or accept an action and return/await `Override.run`. Restore changes when the action settles.
- [Direct Frida](../to-ios-probe-script/references/direct-frida-generation.md): native state reads, internal calls, and condition setup.

# To iOS Probe

Turn one natural-language iOS runtime question into a generated probe, one controlled execution, and an evidence-backed answer. Keep code generation and execution details hidden unless the user asks for them.

## Workflow

1. Read the complete sibling `../to-ios-probe-script/SKILL.md` and follow its generation contract.
2. Read the complete sibling `../to-ios-run/SKILL.md` and follow its connection and execution contract.
3. Resolve the target device or simulator, bundle identifier, target scene, starting scene, allowed interactions, and required Objective-C chain, TAG-prefixed NSLog, state, or UIKit UI evidence. Inspect the target App source when selectors, accessibility identifiers, labels, classes, or business symbols are unknown; never guess them. Ask only when missing information makes execution unsafe or materially ambiguous.
4. Use `to-ios-probe-script` to generate the smallest probe that answers the original question. Use a task-specific directory under the workspace `artifacts/` for Module output unless the user supplies another directory.
5. Use `to-ios-run` to resolve or launch the App, idempotently load MobileEasyUse, and execute exactly one generated Inline operation or one Module export. Preserve its single-operation and no-unsafe-retry rules.
6. After execution returns, inspect its result and only the evidence files it returned. Read only the references matching the returned evidence types: [chain](references/chain-evidence.md), [state](references/state-evidence.md), or [UI](references/ui-evidence.md).
7. Relate observed Objective-C events and UIKit state to original App source, distinguish observed facts from source-based inference, and decide whether the question is answered.
8. If it is not answered, revise and execute another probe only when doing so is safe. Do not automatically retry a failed or timed-out operation that may have mutated App state; first restore or confirm a known starting scene.

# To iOS Probe Script

Generate the smallest iOS runtime code that answers the requested runtime question. Prefer Driver for requested user-visible actions, use Override only when normal App configuration or Driver actions cannot establish a required condition, add Evidence only when needed to answer the question, and use Direct Frida only when the encapsulated capabilities are insufficient. Driver, Override, Evidence, and Direct Frida can compose within their API boundaries; use only what the question requires and avoid unnecessary probing. Generate code only; do not connect to a device or execute it.

## Before generating code

Call `get_sdk_declarations({"platform":"ios"})` to obtain declaration paths in `files[].path`. It returns `sdk` (platform SDK), `bridge` (Frida Objective-C bridge), and `gum` (native Frida APIs) declarations. The capability sections below specify which declarations to read.

Resolve `presets.directory` from `<project-root>/.meu/config.json`
relative to the project root, defaulting to `.meu/presets`. If `<base-directory>/ios/`
contains `presets.dist.js`, read `presets.entry.js` to identify public exports and the
corresponding feature `index.d.ts` files for their contracts. Prefer reusing capabilities that
satisfy the request; import only names exported by the entry, including any aliases.

# To iOS Run

Run exactly one supplied iOS operation. Require `appId`; accept optional canonical `deviceId` and device-side `runtimePort`, defaulting to 8484. Accept exactly one execution form:

1. `source`: one complete `(async () => { ... })()` expression.
2. `scriptPath + functionName`: one named Module export.
3. `scriptPath + naturalDescription`: read the matching `probe.d.ts` completely and select exactly one export. Stop on no match, ambiguity, or missing required arguments.

Optional positional `args` apply only to Module. Do not convert between Inline and Module. If code is missing, first use `to-ios-probe-script`.

## Target

Discover currently booted CoreSimulator devices and currently available USB CoreDevice devices. Exclude shutdown simulators and network-only, unavailable, unpaired, or unusable physical devices.

# To iOS Test

Accept a natural-language request such as “run the click tests under this directory.” Resolve the scope, recursively find test files, and execute them one by one through [to-ios-run](../to-ios-run/SKILL.md).

## Workflow

1. Resolve the App, directory, and requested behavior from the request and session. Default to the App's `tests/`; clarify only material ambiguity.
2. Recursively discover files with `rg --files`. Read test modules to identify relevant tests and starting/cleanup conditions. Exclude helpers, deduplicate paths, and sort by path. State the selected files, then proceed; report no matches without claiming success.
3. Read and follow `to-ios-run`, using its `scriptPath + functionName` form: pass each module's absolute `scriptPath`, `functionName: "run"`, and `args: []`. Reuse the same target and MCP session; invoke each file once and await completion before the next file. No `.d.ts` is needed.
4. Continue after assertion failures when cleanup succeeded and the next starting conditions are established. Stop on cleanup failure, disconnect, operation timeout, or uncertain App state; mark remaining files unrun. Do not automatically retry or modify tests.

## Result

Show results in the reply first: list the first 10 cases in execution order (all cases if fewer), using ✅ for passed, ❌ for failed, and ⏭ for not run. Include the file and case name; briefly explain failures. Keep execution errors distinct from assertion failures.

# To iOS Test Script

Compose Driver, Override, Expect, and Direct Frida into repeatable tests. Reuse `to-ios-probe-script` generation rules for actions and observations; compare observations with expectations through the collection's `expect`. Generate files only; do not connect or execute.

## Before generating code

- Call `get_sdk_declarations({"platform":"ios"})`. Read `Test` and the required SDK APIs; read returned `bridge` declarations for Objective-C work and `gum` for native Frida work. SDK declarations govern API details.
- Resolve scenes, targets, and observations from App source. Derive expectations from requirements or confirmed behavior; clarify missing expectations that determine pass or fail.
- Reuse presets: resolve `presets.directory` in `.meu/config.json` (default `.meu/presets`), read the iOS entry and relevant feature `index.d.ts` declarations, and import declared exports from `/meu/presets.js`.

## 1. Driver

Drive the App into the target scene and perform the tested interactions, following [Driver generation](../to-ios-probe-script/references/driver-generation.md). Default to starting from home; put shared navigation in `beforeEach` and case-specific actions in `test`.