eguidev
AI-assisted development tooling for egui.
eguidev handles cross-target instrumentation inside your app,
eguidev_runtime adds the native-only embedded automation runtime, and edev
manages lifecycle plus the external MCP tool surface.
Join the Discord server for discussion and release updates.
How It Works
eguidev instruments your app from inside the process. It captures widget state
at frame boundaries and injects input through egui's raw_input_hook before
events are consumed. Automation stays aligned with the real event loop without
pixel guessing.
The agent-facing surface is Luau, not fine-grained RPC. On native builds,
eguidev_runtime runs scripts inside the app process against the latest
captured frame, so one script can inspect widgets, queue input, wait for state
changes, and return structured results in a single round trip.
Structure
eguidevcrate -- instrument your egui app. Tag widgets withdev_*helpers, wrap frames withFrameGuard, forward raw input. This is the cross-target instrumentation layer and remains valid forwasm32.eguidev_runtimecrate -- native-only embedded runtime. Attach it once in app bootstrap code to enable script evaluation, screenshots, smoketests, and the in-process MCP server.edevbinary -- the MCP launcher. Starts and stops the app, proxiesscript_eval, serves the Luau API definition. Run it withedev mcp -- <cargo args>.
Build modes
- Instrumentation only: depend on
eguidevalone. This works for native andwasm32targets. - Native embedded runtime: add an app-local feature such as
devtools = ["dep:eguidev_runtime"], then calleguidev_runtime::attach(devmcp)in one bootstrap location. Keep widget code unconditional.
For eframe apps, there are two practical integration rules:
- Register a fixture handler with
DevMcp::on_fixture()to apply named fixtures directly from the runtime without requiring a frame cycle. - Prefer
eframe::Renderer::Glowfor automation runs. Thewgpubackend can exhibit idle-frame stalls in someeframeintegrations.
Custom widgets
Use DevUiExt for standard egui widgets whenever possible. For hand-rolled
controls, instrument both directions:
- Record the widget's current state with
track_response_full(...)orid_with_meta(...). - Consume queued
set_value(...)overrides withtake_widget_value_override(...)before rendering the custom control.
That override step is what lets scripts drive custom combo boxes, sliders, and
other widgets that are not built through the stock dev_* helpers.
Configuration
edev reads .edev.toml from the current directory upward, stopping at the
nearest git root. All subcommands share this config; CLI flags override file
values. See examples/edev.toml for a commented
reference with all options.
The only required field is app.command -- the full argv to launch the app
with DevMCP enabled. edev does not synthesize cargo flags. The command can
also be passed after -- on any subcommand.
Fixtures
List registered fixtures or launch the app from a known baseline for manual testing:
edev fixture applies the named fixture and blocks until ctrl-c. Use it to
get the app into a repeatable state for interactive work.
Fixtures are applied synchronously to app state through DevMcp::on_fixture().
That guarantees the baseline state change has happened, but it does not imply
the next frame has already rebuilt the widget registry for the new pane. In
scripts and smoketests, follow fixture("name") with a concrete readiness wait
such as wait_for_widget_visible(...) for the first widget you depend on.
Smoketests
eguidev includes a built-in smoketest runner. A smoketest suite is a directory
of self-contained .luau scripts. The configured suite is discovered
recursively and executed in lexicographic order by relative path. Explicit
script arguments to edev smoke run in the order provided. Every script
establishes its own state via fixture(), exercises the UI, and asserts
outcomes. After fixture(), wait for the widget or viewport state the script
actually depends on before reading pane-specific widgets.
Smoketests run against the live app through the same script_eval path agents
use. They double as regression tests and as executable documentation for your
scripting surface.
In smoke mode, success is assertion-driven: edev smoke treats a script as
passing when it finishes without throwing. Final return values are ignored by
the smoke runner. Use assert(...) for checks and log(...) for diagnostics.
API Reference
The canonical scripting reference is
eguidev.d.luau -- a strict
Luau type definition covering viewports, widgets, actions, waits, fixtures,
and assertions. Fetch it at any time with script_api or edev --script-docs.
For the Rust API, run ruskel eguidev or see the crate-level doc comments.
The repo also ships a ready-to-use agent skill at
skills/SKILL.md. For Codex-style setups, install it by
copying or symlinking it into your local skills directory as
~/.codex/skills/eguidev/SKILL.md, then invoke the eguidev skill in your
agent workflow.
License
MIT