Infra Setup Agent Skill

Infra Setup

Use this when the user wants to change where experiments run: local worktrees, pool slots, or a remote provider such as Modal, E2B, Daytona, AWS, Azure, SSH, manual, or a custom dotted-path provider.

Goals

• Be explicit about the target backend/provider.
• Check prerequisites before mutating evo config.
• Never install provider SDKs silently.
• Give one actionable auth command per provider.
• Keep provider credentials separate from benchmark runtime env.

Flow

• Identify the target:
• worktree or pool means local backends.
• modal, e2b, ssh:..., or another remote spec means backend=remote.
• If the target is remote, parse the provider choice the same way evo CLI does:
• modal
• e2b
• daytona
• aws
• azure
• manual
• ssh:user@host[:port]
• another built-in provider name
• dotted import path for a custom provider
• Check whether evo is on PATH and whether it is the expected evo-hq-cli package (evo --version). If the provider SDK is missing, evo's provider loader prints the provider-specific extra or SDK package to install; use that message rather than guessing.
• For SDK-backed providers, verify the SDK import only when you can run the check in the same environment that owns the evo executable. If missing, ask the user before installing it.
• If evo was installed with uv tool or pip/venv, prefer the matching extra on evo-hq-cli:
• uv-tool: uv tool install --reinstall 'evo-hq-cli[<provider-extra>]'
• venv / pip: python -m pip install 'evo-hq-cli[<provider-extra>]'
• If evo was installed with pipx, inject the provider SDK into the same evo-hq-cli environment:
• pipx: pipx inject evo-hq-cli <provider-sdk>
• Check auth and show exactly one provider-specific auth command or setup step. Use references/provider-matrix.md.
• Once prerequisites are satisfied, run the explicit config command:

evo config backend remote --provider <provider> --provider-config ...

Or for local backends:

evo config backend worktree
evo config backend pool --workspaces /abs/slot-a,/abs/slot-b

• Be explicit that incomplete provider setup usually surfaces on

evo new --remote <provider> ..., because that is where remote

allocation and bootstrap actually happen.

• If the benchmark itself needs application keys, configure runtime env

separately with evo env load <path> --all or

evo env load <path> --allow KEY1,KEY2. Provider auth provisions the

sandbox; runtime env is what benchmark/gate processes see.

Pre-assumptions

Before trying to switch a workspace to a remote provider, confirm the basics:

• the target backend is clear from the user's request; only ask if the

intent is genuinely ambiguous between worktree, pool, and remote

• the machine running evo has the right provider SDK or transport installed
• the user has auth for that provider available now, not "somewhere else"
• the provider-specific minimum config exists
• modal: auth + optional config
• e2b: API key + optional config
• daytona: API key and API URL/target if needed
• aws: creds, region, image, SSH key pair/private key, and usually network config
• azure: subscription, resource group, region, SSH key/private key, and VM/image choices
• ssh: reachable host, working SSH user, and key/port if needed
• manual: reachable remote endpoint URL and bearer token
• for SSH-backed VM providers, the guest assumptions are plausible before allocation:
• the image enables SSH
• the SSH user matches the image
• the image architecture matches the selected instance type
• the host can run evo's remote workspace runtime

Provider notes

See references/provider-matrix.md for the compact provider summary, common config, and provider-specific setup/auth command.