بنقرة واحدة
infra-setup
// Non-user-invocable provider/setup reference for evo backend switching, prerequisite checks, and auth/install guidance.
// Non-user-invocable provider/setup reference for evo backend switching, prerequisite checks, and auth/install guidance.
Initialize evo for the current repository by exploring the codebase, proposing unexplored optimization dimensions, constructing the benchmark inside a baseline worktree, and running the first experiment. Use when the user invokes /evo:discover, mentions setting up evo, wants to instrument a codebase for autonomous optimization, or asks to start a new evo run on a project.
Run the evo optimization loop with parallel subagents until interrupted.
Print the dashboard's dot chart (score over experiment order, status colors, best-path stair) inline in the terminal for every run in the workspace. Use when the user invokes /evo:report, asks for a quick score chart without opening the dashboard, or wants the scatter plot in chat output.
Internal protocol for evo optimization subagents. Loaded by subagents spawned from /optimize via their host's skill loader. Not for orchestrator use.
| name | infra-setup |
| description | Non-user-invocable provider/setup reference for evo backend switching, prerequisite checks, and auth/install guidance. |
| disable-model-invocation | true |
| evo_version | 0.4.4 |
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.
worktree or pool means local backends.modal, e2b, ssh:..., or another remote spec means backend=remote.modale2bdaytonaawsazuremanualssh:user@host[:port]
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.evo executable. If missing, ask the user before installing it.
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>]'evo was installed with pipx, inject the provider SDK into the same evo-hq-cli environment:
pipx: pipx inject evo-hq-cli <provider-sdk>references/provider-matrix.md.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
evo new --remote <provider> ..., because that is where remote
allocation and bootstrap actually happen.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.Before trying to switch a workspace to a remote provider, confirm the basics:
worktree, pool, and remotemodal: auth + optional confige2b: API key + optional configdaytona: API key and API URL/target if neededaws: creds, region, image, SSH key pair/private key, and usually network configazure: subscription, resource group, region, SSH key/private key, and VM/image choicesssh: reachable host, working SSH user, and key/port if neededmanual: reachable remote endpoint URL and bearer tokenSee references/provider-matrix.md for the compact provider summary, common config, and provider-specific setup/auth command.