Argent Create Flow
Create, record, edit, replay, or repair reusable Argent flow YAML files. Use when the user asks to record or replay a repeatable device path, set up profiling or an A/B comparison, or invoke the authoring engine behind argent-qa-flows. Also use before repeating three or more interactions. For one-off UI checks, acceptance-driven regression tests, or screen video, use argent-test-ui-flow, argent-qa-flows, or argent-screen-recording respectively.
- Skill ID
- software-mansion/argent/argent-create-flow
- Publisher
- software-mansion
- Repository
- argent
- Installs
- 284
- Files
- 4
- Synced
- Sep 16, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
software-mansion/argent/argent-create-flowInstalls these files- SKILL.md
- references/flow-yaml.md
- references/live-authoring.md
- references/reliability-and-recovery.md
What this skill tells the agent
Create an Argent flow
An Argent flow is a replayable sequence in .argent/flows/<name>.yaml.
For a saved QA test case, ticket, or acceptance criterion, load argent-qa-flows first. It adds deterministic setup, acceptance evidence, and two-pass proof.
Read the relevant reference
- Before creating or changing a flow, read Live authoring completely.
- When polishing, composing, or manually reviewing YAML, read Flow YAML. For Vega, read its platform limits before recording remote or keyboard tools.
- Flows run on physical iPhones (an iOS
list-devicesentry with kind"device"), but replay never auto-binds one, even when no simulator is booted: pass the phone's udid asdevice(CLI--device), and only aconnectedphone can run.pinch/rotatesteps fail there like the live tools. On hardware the flow tree is thedescribetree: same ids and roles, no UIView hierarchy. Seeargent-ios-device-interactfor the hardware contract. - On capture warnings, raw coordinates, unavailable trees, mistimed transitions, overlays, or replay failures, read Reliability and recovery.
Non-negotiable rules
- Record the first walkthrough. Start the recorder before the first launch or in-app action. Do not reconstruct a rehearsed path.
- Record checks when their states appear. Record
await-ui-elementlive, then convert it during polish. An echo records intent or diagnostic context, not app behavior or a verdict. A screenshot is human evidence, not an executable verdict. For absence, record the same selector asvisible, perform the removing action, then record it ashidden. - Use semantic targets. Prefer a strict id, then stable text or an accessibility label. Use
scroll-tofor off-screen elements. Resolve every raw-point warning immediately through the coordinate fallback gate. - Prove every screen change. Record a destination-only identity check. During polish, follow it with
await: { idle: true }. Stillness does not prove identity, andidlecan pass with a warning. - Polish only executed behavior. Convert recorded steps without changing their meaning. Record any missing action or structural check live. The only unrecorded insertions are a planned
snapshot:, a navigationawait: { idle: true }, and the documented Chromium packaginglaunch:. - Use scripts only when the user requests them. Read Flow YAML: Local scripts, then record each script with
flow-add-script. - Replay the final YAML end to end. A normal flow needs one uninterrupted full pass.
argent-qa-flowsrequires two consecutive passes.
Stable selectors
A stable selector is fixed by app code and survives account, data, time, count, order, and every locale and environment the flow supports. Prefer ids such as settings-screen. Do not gate on values such as Today, Item 4, usernames, counters, or timestamps.
Flow-only selector scopes
During polish, use within, after, and next to disambiguate repeated elements. Read Flow YAML: Relational scopes for their frame-based semantics and failure cases.
Workflow
- Choose the flow type:
- e2e: the first step that is not
echo:orscript:islaunch:. The flow controls process start. - fragment: there is no leading launch. Declare a precise
executionPrerequisite.
- Follow Live authoring: start, record one verified step at a time, finish, polish, audit, and replay.
- Report the file, replay command, result, prerequisite or side effects, and every coordinate or raw-gesture exception.
Proactive recording
Before repeating three or more interactions, tell the user and start a recording. Record that run and replay it afterward. A completed path cannot be recorded retroactively.
Repair
When replay fails, follow Reliability and recovery. Inspect the first divergence, correct the smallest justified unit, audit, and replay the full flow. Stop after two unsuccessful correction cycles. Never weaken a requested check to obtain a pass.
