argent-lens

Name: argent-lens
Author: software-mansion

1.8kstars51forks

How to install argent-lens?

software-mansion/argent/argent-lens

$npx -y skills add software-mansion/argent --skill argent-lens

Installs into the current project.

Summary

Propose multiple visual design variants for on-screen elements and let the human pick in the Argent Lens window. Use when the user asks for design alternatives / options / A-B choices for a screen or component, or any time you have produced more than one candidate look for an ele

Files · 1

View on GitHub

SKILL.md

1	> Prerequisite — feature flag. This workflow is gated behind the `argent-lens` flag (off by default). Run `argent enable argent-lens` once before using it. If `propose_variant` / `await_user_selection` come back not-found, the flag is off — enable it and retry.
2
3	## 1. Overview
4
5	You implement several candidate designs, capture each one running on the device, and stage them with `propose_variant`. Each proposed element shows up as a floating card next to the live simulator stream in the Argent Lens window (a native window that opens automatically), connected by a thin line to the real element. The human picks per element, optionally pins free-form comments to elements, and presses Complete selection. `await_user_selection` is the single blocking call that returns their decision.
6
7	The golden rule: one variant = one real, _distinct_ screenshot. A proposal is only useful if its `previewImage` shows the variant actually rendered on the device, captured AFTER that specific variant was applied. Never propose a variant you have not built and seen on screen, and never point two variants at the same file path — if two captures end up byte-identical you have not actually changed anything and the Argent Lens degenerates to identical thumbnails. Plan → build → navigate → screenshot → propose, repeated for every variant of every element, then await once.
8
9	## 2. Tools
10
11	\| Tool \| Blocking? \| Purpose \|
12	\| ---------------------- \| --------- \| ----------------------------------------------------------------------- \|
13	\| `propose_variant` \| No \| Stage ONE variant for ONE element. Call once per variant. Keep working. \|
14	\| `await_user_selection` \| Yes \| Call ONCE after every variant is staged. Parks until the human is done. \|
15
16	`propose_variant` params: `element` (human name), optional `match` (`{ by: "text"\|"label"\|"identifier"\|"role", value }`), optional `udid` (the device id you captured the variants on), and `variant` (`{ name, summary, code?, filePath?, previewImage?, frame? }`). Repeated calls with the same `element` accumulate variants on that element; different `element` values create separate cards.
17
18	Always pass `udid` (the same simulator/emulator id you screenshotted and described with). The preview window then streams _that_ device directly — the human never has to pick a simulator. Set it on the first `propose_variant` of a round; later calls may omit it (the last value wins).
19
20	## 3. Workflow
21
22	Resolve a simulator/emulator first (`argent-ios-simulator-setup` / `argent-android-emulator-setup`) and, for React Native, `argent-react-native-app-workflow` to run the app and reload the bundle. Argent shows the staged variants in a native preview window that opens automatically on the user's screen; you don't open or display anything yourself. Just stage variants and call `await_user_selection`, and the window appears on its own.
23
24	### Step 0 — Plan the variants
25
26	Decide, before touching code, exactly which elements you are redesigning and the distinct variants for each. Write them down (e.g. "Search field: Filled / Outlined / Pill" — "Primary CTA: Solid / Gradient"). Each variant must be a single, self-contained change you can apply, screenshot, and revert independently. Vague or overlapping variants produce useless proposals.
27
28	### Step 1 — Get a precise matcher
29
30	For each element, run `describe` (or `debugger-component-tree` for RN) on the screen where it lives and read its exact `label` / `identifier` / `role`. Pass that as `match` so the floating card's connector anchors to the right element:
31
32	- Stable testID / accessibilityIdentifier → `{ by: "identifier", value: "search-input" }` (most reliable)
33	- Exact a11y label → `{ by: "label", value: "Search" }`
34	- Otherwise → `{ by: "text", value: "Search" }` (fuzzy contains; the default if `match` is omitted)
35
36	Omitting `match` defaults to `{ by: "text", value: element }`, which is fine only when the element's visible text is unique.
37
38	### Step 2 — For each variant: build → navigate → screenshot → propose
39
40	Loop over every variant of every element:
41
42	1. Build the variant. Implement that one variant in code.
43	2. Apply it on the device. Reload the RN bundle (`debugger-reload-metro`) or rebuild as needed so the running app shows this variant.
44	3. Navigate to it. Drive the app (`argent-device-interact`) to the screen where the element is visible — a screenshot is only meaningful if the element is actually on screen.
45	4. Screenshot. Call `screenshot` and pass the returned file path straight through as `var

software-mansionPublisher · 14 listings

Preview

software-mansion/argent

> **Prerequisite — feature flag.** This workflow is gated behind the `argent-lens` flag (off by default). Run `argent enable argent-lens` once before using it.

## 1. Overview

You implement several candidate designs, capture each one running on the device, and stage them with `propose_variant`. Each proposed element shows up as a floa

**The golden rule: one variant = one real, _distinct_ screenshot.** A proposal is only useful if its `previewImage` shows the variant actually rendered on the d

Reposoftware-mansion/argent

LicenseApache-2.0

TypeSkills

CategoryDebugging

UpdatedJul 2026

Repo stars1.8k

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

argent-lens

1.8kstars51forks

View on GitHub

How to install argent-lens?

software-mansion/argent/argent-lens

$npx -y skills add software-mansion/argent --skill argent-lens

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	> Prerequisite — feature flag. This workflow is gated behind the `argent-lens` flag (off by default). Run `argent enable argent-lens` once before using it. If `propose_variant` / `await_user_selection` come back not-found, the flag is off — enable it and retry.
2
3	## 1. Overview
4
5	You implement several candidate designs, capture each one running on the device, and stage them with `propose_variant`. Each proposed element shows up as a floating card next to the live simulator stream in the Argent Lens window (a native window that opens automatically), connected by a thin line to the real element. The human picks per element, optionally pins free-form comments to elements, and presses Complete selection. `await_user_selection` is the single blocking call that returns their decision.
6
7	The golden rule: one variant = one real, _distinct_ screenshot. A proposal is only useful if its `previewImage` shows the variant actually rendered on the device, captured AFTER that specific variant was applied. Never propose a variant you have not built and seen on screen, and never point two variants at the same file path — if two captures end up byte-identical you have not actually changed anything and the Argent Lens degenerates to identical thumbnails. Plan → build → navigate → screenshot → propose, repeated for every variant of every element, then await once.
8
9	## 2. Tools
10
11	\| Tool \| Blocking? \| Purpose \|
12	\| ---------------------- \| --------- \| ----------------------------------------------------------------------- \|
13	\| `propose_variant` \| No \| Stage ONE variant for ONE element. Call once per variant. Keep working. \|
14	\| `await_user_selection` \| Yes \| Call ONCE after every variant is staged. Parks until the human is done. \|
15
16	`propose_variant` params: `element` (human name), optional `match` (`{ by: "text"\|"label"\|"identifier"\|"role", value }`), optional `udid` (the device id you captured the variants on), and `variant` (`{ name, summary, code?, filePath?, previewImage?, frame? }`). Repeated calls with the same `element` accumulate variants on that element; different `element` values create separate cards.
17
18	Always pass `udid` (the same simulator/emulator id you screenshotted and described with). The preview window then streams _that_ device directly — the human never has to pick a simulator. Set it on the first `propose_variant` of a round; later calls may omit it (the last value wins).
19
20	## 3. Workflow
21
22	Resolve a simulator/emulator first (`argent-ios-simulator-setup` / `argent-android-emulator-setup`) and, for React Native, `argent-react-native-app-workflow` to run the app and reload the bundle. Argent shows the staged variants in a native preview window that opens automatically on the user's screen; you don't open or display anything yourself. Just stage variants and call `await_user_selection`, and the window appears on its own.
23
24	### Step 0 — Plan the variants
25
26	Decide, before touching code, exactly which elements you are redesigning and the distinct variants for each. Write them down (e.g. "Search field: Filled / Outlined / Pill" — "Primary CTA: Solid / Gradient"). Each variant must be a single, self-contained change you can apply, screenshot, and revert independently. Vague or overlapping variants produce useless proposals.
27
28	### Step 1 — Get a precise matcher
29
30	For each element, run `describe` (or `debugger-component-tree` for RN) on the screen where it lives and read its exact `label` / `identifier` / `role`. Pass that as `match` so the floating card's connector anchors to the right element:
31
32	- Stable testID / accessibilityIdentifier → `{ by: "identifier", value: "search-input" }` (most reliable)
33	- Exact a11y label → `{ by: "label", value: "Search" }`
34	- Otherwise → `{ by: "text", value: "Search" }` (fuzzy contains; the default if `match` is omitted)
35
36	Omitting `match` defaults to `{ by: "text", value: element }`, which is fine only when the element's visible text is unique.
37
38	### Step 2 — For each variant: build → navigate → screenshot → propose
39
40	Loop over every variant of every element:
41
42	1. Build the variant. Implement that one variant in code.
43	2. Apply it on the device. Reload the RN bundle (`debugger-reload-metro`) or rebuild as needed so the running app shows this variant.
44	3. Navigate to it. Drive the app (`argent-device-interact`) to the screen where the element is visible — a screenshot is only meaningful if the element is actually on screen.
45	4. Screenshot. Call `screenshot` and pass the returned file path straight through as `var

software-mansionPublisher · 14 listings

Preview

software-mansion/argent

> **Prerequisite — feature flag.** This workflow is gated behind the `argent-lens` flag (off by default). Run `argent enable argent-lens` once before using it.

## 1. Overview

You implement several candidate designs, capture each one running on the device, and stage them with `propose_variant`. Each proposed element shows up as a floa

**The golden rule: one variant = one real, _distinct_ screenshot.** A proposal is only useful if its `previewImage` shows the variant actually rendered on the d

Reposoftware-mansion/argent

LicenseApache-2.0

TypeSkills

CategoryDebugging

UpdatedJul 2026

Repo stars1.8k

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type