AI-assisted development

Codex and Claude Code can use Day’s Model Context Protocol (MCP) server to build an app, interact with its controls, and inspect screenshots. The agent edits files through its usual file tools; Day supplies the build and test operations. Choose your coding agent to see its installation and connection instructions.

0. Install the two CLIs

Install Day and check the toolkit you plan to use:

cargo install day-cli
day doctor --toolkit appkit

This guide uses macos-appkit on macOS. For another target, follow Getting started and substitute its target name in the commands below.

npm install -g @anthropic-ai/claude-code

npm install -g @openai/codex

Launch your chosen client once and complete its sign-in steps before connecting Day.

1. Scaffold the app

day new app skycheck --toolkit macos-appkit --no-input
cd skycheck
day launch -p macos-appkit

The project includes localized strings, a sample UI, dayscript/demo.yaml, and an AGENTS.md with project conventions. Confirm that the app builds and launches before involving an agent; troubleshooting covers SDK and device setup failures.

2. Connect your coding agent

The connection starts a local Day server, bound to this app’s project directory. An absolute path prevents the server from selecting a different app when the agent changes directories.

[mcp_servers.day]
command = "day"
args = ["--project", "/absolute/path/to/skycheck", "mcp-server"]
startup_timeout_sec = 30
tool_timeout_sec = 1200
required = true

codex --sandbox workspace-write

claude mcp add --transport stdio --scope local day -- day --project "$PWD" mcp-server
claude

@AGENTS.md

What the tools do

day mcp-server exposes project metadata, toolchain checks, builds, launches, test steps, screenshots, linting, and session controls. The agent reference lists the tools and arguments.

The usual sequence is day_metadata, an edit, day_relaunch, then day_drive assertions and a screenshot. On a first run, pass the target explicitly; a relaunch without targets applies to existing sessions. Build errors are returned to the agent, and screenshots are returned as MCP image content for inspection.

Day’s MCP server runs local processes with its process permissions. Connecting the server gives approved calls access to Day’s build and launch operations for that project.

3. Add a weather page, by prompt

Ask the agent:

Read AGENTS.md and call day_metadata first. Add a “weather” page to the sidebar: a city picker (Lisbon, Nairobi, Osaka), a large temperature label, a one-line conditions label, and a Refresh button that simulates a reload with day::sleep. Use demo data, no network. Give every control a stable id (weather-city, weather-temp, weather-conditions, weather-refresh), localize every string in all locales, then relaunch and show me a screenshot of the page.

Watch the loop the scaffolded AGENTS.md prescribes: day_metadata first, then the edits, a day_relaunch (fixing anything the compiler says), then a day_drive that navigates to the page and returns a screenshot. The generated page uses the standard Day API. An abbreviated version should look like this:

pub(crate) fn weather_page() -> impl Piece {
    let city = Signal::new(0usize);
    let cities = ["Lisbon", "Nairobi", "Osaka"]; // res::str keys in the real page
    let temps = ["18 °C", "24 °C", "11 °C"];
    column((
        label(crate::res::str::weather_title()).font(Font::Title).id("weather-title"),
        picker(cities.iter().cloned(), city).id("weather-city"),
        label(move || temps[city.get()].to_string())
            .font(Font::LargeTitle)
            .id("weather-temp"),
        // …conditions label, and a Refresh button whose action is
        // day::task(async move { day::sleep(600).await; /* set signals */ })
    ))
    .spacing(12.0)
    .padding(16.0)
}

If the result isn’t right, say so in the same session (“the temperature should update when the city changes”) and the agent re-drives the app to show the fix. Check the assertion results and inspect the screenshot before accepting the change.

4. Script it: dayscript

Now put that verification in a script that CI can rerun. Ask the agent to write it, or drop this in as dayscript/weather.yaml:

flow:
  - wait_for: { id: nav }
  - navigate: { route: weather }
  - assert_route: { route: weather }
  - assert_visible: { id: weather-title }

  # The picker drives a signal; the labels read it; assert the round trip.
  - select: { id: weather-city, index: 1 }
  - assert_text: { id: weather-temp, text: "24 °C" }
  - tap: { id: weather-refresh }
  - assert_visible: { id: weather-conditions }

  - screenshot: weather

day launch -p macos-appkit --script dayscript/weather.yaml
day launch -p macos-appkit --script dayscript/weather.yaml --variant dark --env DAY_THEME=dark
day launch -p macos-appkit --script dayscript/weather.yaml --variant fr --locale fr

Each run drives the real app and writes content-checked captures under build/day/screenshots/<target>/<variant>/, the same mechanism that produces the localized gallery on this site. For strings that vary by locale, assert by Fluent key (assert_text: { id: …, key: … }) instead of literal text and one script passes in every language.

You can also record the script instead of writing it: day launch -p macos-appkit --record dayscript/weather.yaml captures your real taps, typing, and navigation into a replayable dayscript while you use the app, rewriting the file continuously so it survives a kill. Recording a manual walkthrough is the fastest way to get a first script; add the assert_* steps by hand afterward.

5. Put it in CI

The saved dayscript runs without either coding agent. Add the Linux target to the project before committing a workflow that uses it:

day project add-target linux-gtk

This GitHub workflow builds the app on Linux and runs the script on each push:

name: ci
on: [push, pull_request]
jobs:
  walkthrough:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: dtolnay/rust-toolchain@stable
      - uses: Swatinem/rust-cache@v2
      - run: |
          sudo apt-get update
          sudo apt-get install -y --no-install-recommends \
            libgtk-4-dev libadwaita-1-dev pkg-config xvfb
      - run: cargo install day-cli
      - name: Drive the app
        run: |
          xvfb-run -a -s "-screen 0 1000x720x24" \
            day launch -p linux-gtk --script dayscript/weather.yaml
      - uses: actions/upload-artifact@v4
        with:
          name: screenshots
          path: build/day/screenshots

A failed assertion is a red build; the uploaded captures show reviewers what the app looked like. From here, add targets to the matrix as your app grows (install each target’s tools and add its project configuration), or adopt the fuller multi-platform workflow Day itself publishes in daybrite/actions.

codex exec --sandbox workspace-write \
  -c 'mcp_servers.day.default_tools_approval_mode="approve"' \
  "Read AGENTS.md. Use Day MCP to inspect this project, build macos-appkit, launch it, run the demo assertions, inspect a screenshot, and stop the app. Report any failure."

Connection and build problems

• No Day tools: check /mcp, the day executable path, and the absolute project path.
• Replaying an existing walkthrough: use day launch --script for saved YAML files. Converting YAML to raw MCP steps can lose platform filters or change YAML keys.
• Build failure without a useful compiler diagnostic: run day --verbose build -p macos-appkit in a terminal. An older scaffold may use APIs that have changed in its resolved Day dependencies; check the CLI and dependency versions before diagnosing the MCP connection.

Where to go next

• Testing with dayscript — the full step catalog and how the engine works.
• For AI agents — the terse rulebook agents should follow (link it from your own prompts).
• Agent surface reference — day drive, sessions, and the MCP tools in detail.