Add eas-simulator skill#88
Conversation
gwdp
force-pushed
the
gwdp/eas-simulator-skill
branch
from
95f2749 to
b1e998a
Compare
davidmokos
left a comment
davidmokos
left a comment
There was a problem hiding this comment.
Review comments based on Anthropic and OpenAI skill-creator guidance.
Kudo
left a comment
Kudo
left a comment
There was a problem hiding this comment.
would like to know further test plans:
- if we ask agent to use argent, does it work well? (because the skill / references hardcoded agent-device in multiple places)
- if we ask agent to run android workflow, does ti work well? (because the skill / references hardcoded ios in multiple places)
Thanks for the review @Kudo and @davidmokos 🙏 Addressed all the feedback — replies inline. Also added test plans for argent (editor MCP link) and Android, both worked quite well, although argent received a little refinement to improve experience. Let me know how you guys feel about it! |
gwdp
force-pushed
the
gwdp/eas-simulator-skill
branch
from
3ad2e3b to
c568085
Compare
Kudo
left a comment
Kudo
left a comment
There was a problem hiding this comment.
i have a mixed feeling for the current work. but i don't want to block much. if you want to ship it first and iterate later. please just re-request review for me. (i use graphite dashboard. please don't feel hesitant about the "request changes" / "re-request review" workflow)
the major concern is
- some step-by-step in markdowns could potentially use scripts in the skill to make it more deterministic. for example, the argent mcp setup.
- i feel we are mixing "how-to build" concept in this skill. ideally we should keep this skill smaller and link to other skill. currently the differece between mode a/b/c are mostly how the app built. we could try to focus single stuff - "given an app/ipa/apk, use eas simulator" to run it. how to generate app/ipa/apk is not in the skill scope.
- imo, mode b is the happy path for me. even though the skill said it's rarely used. if people can build ios app locally, they should mostly have local simulators available. using eas build or eas workflow to build the app, for people running on linux/windows machine to test ios app, is something we are targeting first. maybe we can simplify the mode matrix a little bit.
| | `screenshot <path>` | Capture to a local PNG (downloaded from the daemon) | | ||
| | `gesture <pan\|fling\|swipe\|pinch\|rotate\|transform>` / `swipe` / `scroll` / `longpress` / `type` / `back` / `home` | Standard interactions — `gesture` needs a kind subcommand | | ||
| | `metro prepare (--public-base-url <url> \| --proxy-base-url <url>)` / `metro reload` | Wire a dev client to Metro / reload (Mode C). `--proxy-base-url` = optional bridge origin for remote Metro access — **not exercised by this skill's flow** (run-your-app.md connects via the public tunnel URL). | | ||
| | `logs` / `record` / `network` / `perf` | Evidence capture | |
There was a problem hiding this comment.
nit: i feel that we should not doc agent-device in our skill. does agent-device have some doc that we can ask agents to fetch?
or even just run agent-device help?
There was a problem hiding this comment.
agent device skills are installed when you install agent-device: https://github.com/callstackincubator/agent-device
(side note: did we test the full process including the agent-device install on windows?)
There was a problem hiding this comment.
also, we should probably commit to a single library: argent or agent-device, instead of recommending both
There was a problem hiding this comment.
nit: i feel that we should not doc agent-device in our skill. does agent-device have some doc that we can ask agents to fetch?
or even just run
agent-device help?
Agreed that --help is better and decouples us from maintaining a verb list in the skill. Updated. I originally added the table after seeing models struggle with agent-device in dogfooding sessions. Will do a bit more testing before re-requesting review for this particular change.
agent device skills are installed when you install agent-device: https://github.com/callstackincubator/agent-device
(side note: did we test the full process including the agent-device install on windows?)
I checked transcripts and couldn't see agent-device skill. Digging further it was pretty clear that because we exec through npx, those are not loaded and we can't rely on it. (which is a nice isolation imo, let me know your thoughts)
Windows is not directly tested; assuming devs on Windows are using WSL (You guys probably have a better idea if this is a bad assumption). Will look to validate that in the coming days
also, we should probably commit to a single library:
argentoragent-device, instead of recommending both
I'm a little hesitant on this one, imo, going fully blind on it means the agent has no reference when a user brings it up, and that tends to produce more loops and token spend before landing on something maybe works. Let me know if you guys feel strong about this.
davidmokos
left a comment
davidmokos
left a comment
There was a problem hiding this comment.
Don't want to block this. I think we need to test it properly in the wild and make changes when we see the agents struggle. I'd encourage everyone in expo to dogfood this skill and the simulator service after we merge it
I hesitate to give scripts and hard instructions because in my experience, models and user environments are different, and giving the minimum, to allow it to adapt is the part that makes the skill succeed in the most diversity. Happy to be wrong and discuss it further
Fair, and I agree we opinionated more than ideal. The modes emerged from real dogfooding scenarios though; each one came from a "what if I want to do it this way" moment. I'd rather keep the minimum needed to not leave the model stranded than link out and risk it not finding what it needs in time.
The framing was mostly to avoid false-triggering on Mac users who just want a local sim. But the trend I'm seeing, even on Mac is the full agent loop: prompt, see, agent sees too. That all-in-IDE experience is where Mode C earns its place as default. For Linux/Windows targeting iOS, yeah Mode B is the right happy path there, agreed 💯 Thanks for the review once again @Kudo, replies above @davidmokos dropped some more improvements, if you dont mind a second check, I do appreciate the time 🙇♂️ |
Kudo
left a comment
Kudo
left a comment
There was a problem hiding this comment.
thanks for answering the questions. you know what you want. the current work is based on your thinking. that's great and i don't want to block it. approving the pr to move forward.
leaving answers that we can follow up later
Windows using WSL
i think that's not correct. a lot windows user still use powershell / cmd without WSL.
The framing was mostly to avoid false-triggering on Mac users who just want a local sim. But the trend I'm seeing, even on Mac is the full agent loop: prompt, see, agent sees too. That all-in-IDE experience is where Mode C earns its place as default.
for mac users, if they want agent loop. what's the benefit to use eas simulator than local agent-device/argent?
also what does the all-in-IDE experience mean here? does eas simulator offer ui panel inside cursor so we can see simulator ui in the same IDE?
|
Thank you for the quick review @Kudo !
appreciate this input! dogfooding some there without WSL and will follow up on this, very interested in making this particular one flawless
I see motivation around hardware, but more interesting, reproducing bugs on lower/unsupported iOS versions without having the simulator image installed locally 🥳 (I struggled with this multiple time in the past)
cursor and others are currently offering a built-in browser which is leveraged by the skill -> opens from serve-sim provided tunnel (check video) |
|
thanks for sharing the insight. that makes sense to me.
maybe we can even add this "when to use" to the skill. that could be one selling point. |
gwdp
force-pushed
the
gwdp/eas-simulator-skill
branch
from
87b12d3 to
5096676
Compare
szdziedzic
left a comment
szdziedzic
left a comment
There was a problem hiding this comment.
Good job 👏 . I think this looks good overall so I'm approving it although I left some comments about argent. Let's release it so we can all test it more easily and see if we like it + iterate on the feedback. Would be great to test it in Cursor Cloud Agents too. I will play with it more once it lands. Awesome.
| ```bash | ||
| # 1. Add a simulator build profile to eas.json (merges — won't overwrite existing profiles) | ||
| node -e " | ||
| const fs = require('fs'); | ||
| const p = 'eas.json'; | ||
| const c = fs.existsSync(p) ? JSON.parse(fs.readFileSync(p, 'utf8')) : {}; | ||
| c.build = c.build || {}; | ||
| c.build.sim = { ios: { simulator: true } }; | ||
| fs.writeFileSync(p, JSON.stringify(c, null, 2) + '\n'); | ||
| " |
There was a problem hiding this comment.
I think it won't work for some setups. It would be good if agent could prioritize getting existing sim profile first before creating new one?
There was a problem hiding this comment.
I think it won't work for some setups
You're right, there are multiple setup variances, and from experience, the script could force the LLM to use it without much consideration. (reason why I'm not a big fan of script as instructions)
Updated to pure instructions without a script, allowing us to support a little more than the previous iteration.
…un-your-app fixes
gwdp
force-pushed
the
gwdp/eas-simulator-skill
branch
from
206a03b to
880a62b
Compare
…ion if already present
…e fixed NSPasteboard entry
4 participants
Why
EAS provides cloud simulators. This skill makes it easy for agents to open in-development apps on them.
What
New skill at
plugins/expo/skills/eas-simulator/— SKILL.md and three reference files. Covers the session lifecycle, three ways to get an app onto the sim, driving it (press, screenshot, etc.), and cleanup.Test plan
Ran all three modes on real sessions from Cursor on a Mac. Opus 4.8, Composer 2.5, and Codex 5.3 all picked up and followed the skill correctly.
Mode A — local release build
Built locally, uploaded to the cloud sim, app rendered.
Transcript
Mode B — EAS build (iOS)
EAS built it, VM downloaded the artifact (no credentials), app rendered.
Transcript
Mode B — EAS build (Android)
EAS built the APK, VM downloaded it, rendered on the remote Android emulator. No browser preview — Android is screenshot-only.
Transcript
Mode C — dev build + tunnel (live edit)
Edited a file locally, it hot-reloaded on the remote sim with no rebuild.
Transcript
Transcript Linux
argent — editor MCP link
Started an argent session (
--type argent), ranargent init --yesto register the Argent MCP in Cursor, wiredARGENT_TOOLS_URL+ARGENT_AUTH_TOKENas env vars in.cursor/mcp.json(higher precedence thanargent link, works in sandboxed shells), and reloaded the editor. The remote sim was controllable from chat via Argent's MCP tools.Transcript
Trigger accuracy — 6/6 (100%)
Still to do: