argent-test-ui-flow

Name: argent-test-ui-flow
Author: software-mansion

1.8kstars51forks

How to install argent-test-ui-flow?

software-mansion/argent/argent-test-ui-flow

$npx -y skills add software-mansion/argent --skill argent-test-ui-flow

Installs into the current project.

Summary

Autonomously test an app UI (iOS or Android) by running interact-screenshot-verify loops using argent MCP tools. Use when testing UI flows, verifying login works, testing navigation, running end-to-end UI test scenarios, manual QA steps, visible UI changes, or visual behavior.

Files · 1

View on GitHub

SKILL.md

1	## Platform-agnostic
2
3	The interaction tool names are identical on iOS and Android — `gesture-tap`, `gesture-swipe`, `describe`, `screenshot`, `launch-app`, etc. — and the tool-server auto-dispatches based on the `udid` you pass (UUID-shape → iOS, adb serial → Android).
4
5	Before testing, resolve which device to test on. Call `list-devices` and follow `<device_selection_rule>`: prefer a running device on any platform;
6
7	Once a platform is chosen, the per-platform setup skill takes over:
8
9	\| Platform \| Setup skill \| Find devices with \|
10	\| -------- \| ------------------------------- \| ----------------------------------------------------------- \|
11	\| iOS \| `argent-ios-simulator-setup` \| `list-devices` → `boot-device` with `udid` if none booted \|
12	\| Android \| `argent-android-emulator-setup` \| `list-devices` → `boot-device` with `avdName` if none ready \|
13
14	## 1. Workflow
15
16	All interactions go through argent MCP tools. Ensure the simulator/emulator is ready before starting.
17
18	For implementation tasks that modify visible UI, this workflow can also serve as a visual acceptance path.
19
20	1. Baseline screenshot: Call `screenshot` to see the current UI state. For visual regression comparison or UI change verification, capture the baseline at `scale: 1.0` with `includeImageInContext: false` and keep the returned `path` before editing whenever feasible.
21	2. Find target: Before tapping, use a discovery tool to get element coordinates:
22	- React Native apps: use `debugger-component-tree` — it returns component names with (tap: x,y) coordinates. This is the preferred tool for RN apps on either platform. To use it, resolve the `argent-react-native-app-workflow` skill for setup; on Android you must also run `adb -s <serial> reverse tcp:8081 tcp:8081` so Metro is reachable from the device.
23	- Standard app screens and in-app modals: use `describe`. On iOS this returns the AX tree (falls back to native-devtools when AX is empty); on Android it returns the uiautomator tree in the same DescribeNode shape.
24	- Permission prompts / system modal overlays: try `describe` first. Fall back to `screenshot` only if the overlay is not exposed reliably. When the app raises its own permission dialog, answer it here — that's the real flow under test. To take a prompt _out_ of the flow (pre-grant/deny before launch, re-enable a permission the user already denied, or reset it so the dialog reappears), use the `argent-settings-permissions` skill during setup instead of interacting with the dialog.
25	- Fallback: use `screenshot` to estimate where the desired component is, then verify immediately after the action.
26	3. Interact: Perform the action (`gesture-tap`, `gesture-swipe`, `keyboard`, `button`, ...) — you receive a screenshot automatically.
27	4. Verify: Check the returned screenshot for expected results. If it shows a loading/transitional state, prefer blocking until it settles with `await-ui-element` (expected element `visible`, or a spinner `hidden`) over a guessed delay — but only with a selector you can trust (`text`/`identifier`/`role`) that the screen is known to have or that you saw in a prior `describe`; a guessed one just times out. Otherwise use a short fixed wait. Pick evidence by what's being asserted:
28	- Visual (layout, spacing, color, typography, image/icon rendering, clipping, overflow, text rendering): prefer `screenshot-diff` against the baseline captured in step 1 — it surfaces pixel-visible changes the auto-screenshot might miss. Fall back to visual inspection of the auto-screenshot only when a stable baseline isn't available.
29	- Structural (navigation state, element existence, accessibility labels/values, selection, hierarchy, route): verify with `describe`, `debugger-component-tree`, or `native-describe-screen`.
30	- Runtime / log / network (console errors, API calls, persistence, timing): verify with `view-network-logs`, `debugger-log-registry`, `debugger-evaluate`, or targeted tests.
31	- Mixed: collect evidence for each relevant class.
32	- Report the combined verdict: expected behavior, observed behavior, evidence used, and any blocker for requested visual diffing.
33	5. Repeat for each step in the flow.
34
35	## 2. Template
36
37	```
38	Goal: Test [feature name]
39
40	Steps:
41	1. Classify expected result: visual / structural / runtime-log-network / mixed → choose evidence
42	2. [Navigate / tap / type to reach stable comparable starting point] → verify auto-screenshot
43	3. screenshot { scale: 1.0, includeImageInContext: false } → save baseline path when visual or mixed evidence needs diffing
44	4. [Perform the

People who liked this also viewed

6 picks

Type

argent-test-ui-flow

1.8kstars51forks

View on GitHub

How to install argent-test-ui-flow?

software-mansion/argent/argent-test-ui-flow

$npx -y skills add software-mansion/argent --skill argent-test-ui-flow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Platform-agnostic
2
3	The interaction tool names are identical on iOS and Android — `gesture-tap`, `gesture-swipe`, `describe`, `screenshot`, `launch-app`, etc. — and the tool-server auto-dispatches based on the `udid` you pass (UUID-shape → iOS, adb serial → Android).
4
5	Before testing, resolve which device to test on. Call `list-devices` and follow `<device_selection_rule>`: prefer a running device on any platform;
6
7	Once a platform is chosen, the per-platform setup skill takes over:
8
9	\| Platform \| Setup skill \| Find devices with \|
10	\| -------- \| ------------------------------- \| ----------------------------------------------------------- \|
11	\| iOS \| `argent-ios-simulator-setup` \| `list-devices` → `boot-device` with `udid` if none booted \|
12	\| Android \| `argent-android-emulator-setup` \| `list-devices` → `boot-device` with `avdName` if none ready \|
13
14	## 1. Workflow
15
16	All interactions go through argent MCP tools. Ensure the simulator/emulator is ready before starting.
17
18	For implementation tasks that modify visible UI, this workflow can also serve as a visual acceptance path.
19
20	1. Baseline screenshot: Call `screenshot` to see the current UI state. For visual regression comparison or UI change verification, capture the baseline at `scale: 1.0` with `includeImageInContext: false` and keep the returned `path` before editing whenever feasible.
21	2. Find target: Before tapping, use a discovery tool to get element coordinates:
22	- React Native apps: use `debugger-component-tree` — it returns component names with (tap: x,y) coordinates. This is the preferred tool for RN apps on either platform. To use it, resolve the `argent-react-native-app-workflow` skill for setup; on Android you must also run `adb -s <serial> reverse tcp:8081 tcp:8081` so Metro is reachable from the device.
23	- Standard app screens and in-app modals: use `describe`. On iOS this returns the AX tree (falls back to native-devtools when AX is empty); on Android it returns the uiautomator tree in the same DescribeNode shape.
24	- Permission prompts / system modal overlays: try `describe` first. Fall back to `screenshot` only if the overlay is not exposed reliably. When the app raises its own permission dialog, answer it here — that's the real flow under test. To take a prompt _out_ of the flow (pre-grant/deny before launch, re-enable a permission the user already denied, or reset it so the dialog reappears), use the `argent-settings-permissions` skill during setup instead of interacting with the dialog.
25	- Fallback: use `screenshot` to estimate where the desired component is, then verify immediately after the action.
26	3. Interact: Perform the action (`gesture-tap`, `gesture-swipe`, `keyboard`, `button`, ...) — you receive a screenshot automatically.
27	4. Verify: Check the returned screenshot for expected results. If it shows a loading/transitional state, prefer blocking until it settles with `await-ui-element` (expected element `visible`, or a spinner `hidden`) over a guessed delay — but only with a selector you can trust (`text`/`identifier`/`role`) that the screen is known to have or that you saw in a prior `describe`; a guessed one just times out. Otherwise use a short fixed wait. Pick evidence by what's being asserted:
28	- Visual (layout, spacing, color, typography, image/icon rendering, clipping, overflow, text rendering): prefer `screenshot-diff` against the baseline captured in step 1 — it surfaces pixel-visible changes the auto-screenshot might miss. Fall back to visual inspection of the auto-screenshot only when a stable baseline isn't available.
29	- Structural (navigation state, element existence, accessibility labels/values, selection, hierarchy, route): verify with `describe`, `debugger-component-tree`, or `native-describe-screen`.
30	- Runtime / log / network (console errors, API calls, persistence, timing): verify with `view-network-logs`, `debugger-log-registry`, `debugger-evaluate`, or targeted tests.
31	- Mixed: collect evidence for each relevant class.
32	- Report the combined verdict: expected behavior, observed behavior, evidence used, and any blocker for requested visual diffing.
33	5. Repeat for each step in the flow.
34
35	## 2. Template
36
37	```
38	Goal: Test [feature name]
39
40	Steps:
41	1. Classify expected result: visual / structural / runtime-log-network / mixed → choose evidence
42	2. [Navigate / tap / type to reach stable comparable starting point] → verify auto-screenshot
43	3. screenshot { scale: 1.0, includeImageInContext: false } → save baseline path when visual or mixed evidence needs diffing
44	4. [Perform the

People who liked this also viewed

6 picks

Type