Skip to content

optimization: move some instructions out of the argent-device-interact skill to reference files - #968

Open
kasperski95 wants to merge 5 commits into
mainfrom
kas/refine-argent-device-interact
Open

optimization: move some instructions out of the argent-device-interact skill to reference files#968
kasperski95 wants to merge 5 commits into
mainfrom
kas/refine-argent-device-interact

Conversation

@kasperski95

@kasperski95 kasperski95 commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

Why

Skills are getting bloated affecting benchmark results.

What

  • added <SKILL>/references/chromium.md — no point of loading that information to the context when argent is used with iOS or Android
  • added <SKILL>/references/secrets.md — typing secrets is rather unusual.
  • reduced duplicated information for await-ui-element by redirecting to the tool's description

Note

Not tested. Relying on CI.

@kasperski95 kasperski95 changed the title optimization: argent-device-interact optimization: move some instructions out of the argent-device-interact skill to reference files Aug 26, 2026
@kasperski95
kasperski95 marked this pull request as ready for review August 26, 2026 15:39

@latekvo latekvo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sub total of text has grown past the size of the moved text.
Not necessarily bad but kind of misses the point of this PR, if these new things are useful then just change the PR description and we're good.

Left couple inlines. Good job and thx for it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chromium.md duplicates text that was never removed from SKILL.md

  • SKILL.md:24 - "gesture-swipe is touch-only, use gesture-scroll" - still there, repeated in the new text
  • SKILL.md:59-60 - the scroll/drag table - still there; chromium.md repeats it minus the "(Chromium)" column labels
  • SKILL.md:185 - "paste … Chromium and Vega are rejected" - still there, repeated
  • SKILL.md:169 -"delayMs … applies to the iOS simulator and Chromium" - still there, repeated
  • SKILL.md:285 - the run-sequence allowlist already contains both tools; chromium-tabs.md restates it as prose

## Unified tool surface

All interaction tools below accept a `udid` parameter and auto-dispatch iOS vs Android based on its shape (UUID → iOS simulator, `chromium-cdp-<port>` → Chromium (CDP) app, anything else → Android adb serial). You use the same tool names on every platform.
All interaction tools below accept a `udid` parameter and auto-dispatch on its shape, so you use the same tool names on every platform. A known prefix wins first — `chromium-cdp-` → Chromium (CDP) app, `remote:` → remote iOS simulator — otherwise a bare UUID → local iOS simulator and anything else → Android adb serial.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fact is completely new. Nothing bad just pointing it out since it's out of scope of this PR.


## What counts as a Chromium target

A **Chromium (CDP) app** = any Chromium runtime exposing a Chrome DevTools Protocol endpoint: an Electron app (boot it with `boot-device` + `electronAppPath`), or any Chromium-family browser (Chrome/Brave/Edge) launched with `--remote-debugging-port`. The latter is auto-discovered by `list-devices` on port `9222` plus anything in `ARGENT_CHROMIUM_PORTS` — already-running browsers show up directly, no `boot-device` needed. The same describe/tap/swipe/keyboard/screenshot surface drives all of them.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also new, not on main, just pointing out.

### await-ui-element — Block until a UI element reaches a state

Instead of polling `screenshot`/`describe` in a loop, use `await-ui-element` to block server-side until an element reaches an expected state (or `timeoutMs`, default 5000ms, elapses). It polls the same accessibility/DOM tree as `describe`. (For a plain pause, use your own harness sleep — this tool deliberately has no bare-timer mode.)
**Never poll `screenshot`/`describe` in a loop to wait for something.** Use `await-ui-element`: it blocks server-side on the same tree `describe` reads. It has no bare-timer mode by design — for a plain pause, use your own harness sleep.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very solid rewrite, nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants