subagent
Protocol that evo optimization subagents follow when dispatched from /optimize. Auto-loaded by spawned subagents via their host's skill loader. The orchestrator may also invoke this skill to understand the brief shape its dispatched subagents expect + what they're required to emit -- useful when writing briefs or debugging a subagent's behavior.
npx skills add evo-hq/evo --skill subagent --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Describes the Evo Subagent Protocol that guides dispatched subagents. It lists which tools a subagent may pull, which subagents it can dispatch, and references to instrumentation and diagnostics. It signals that the orchestrator may use this protocol to understand the expected brief shape and required emissions, and that subagents should follow the four fields in their briefs. It also outlines the host conventions and how the orchestrator interacts with subagents during the iteration loop.
How it works
- The protocol is presented as Evo surface from the subagent perspective, enumerating triggering conditions for pull and dispatch actions (e.g., evo:finetuning, evo:verifier, evo:benchmark-reviewer).
- It specifies references and read tools for wiring, instrumentation, and I/O contracts (e.g., sdk_python.py, instrumentation-contract.md).
- It indicates orchestration entry-points for various duties (benchmark-reviewer, ideator, infra-setup) and where the full references catalogue lives (evo discover).
- It describes the operational flow: read the brief with four fields (Objective, Parent node, Boundaries / anti-patterns, Pointer traces) and an iteration budget; read traces; form a concrete edit hypothesis; create an experiment; edit, verify, and run with the evo CLI workflow.
- It emphasizes that subagents operate via a worktree workspace in evo, and provides commands for creating and editing experiments, running verifiers, and performing read/write operations across local or remote backends.
When to use it
- Use whenever you are implementing or deploying an evo optimization subagent that will be dispatched from /optimize and may be auto-loaded by subagents. Use to understand the required brief shape and emissions, and how to interact with orchestrator tooling and references.
What it can touch
- Tools listed under the Evo surface: evo:finetuning as a skill to pull, evo:verifier and evo:benchmark-reviewer as dispatchable subagents, and various Read/Task tools for wiring and instrumentation references.
- References catalogue for wiring per-task instrumentation and I/O contracts (e.g., sdk_python.py, instrumentation-contract.md, trace-schema.md).
Caveats
- License: Apache-2.0
- Declared evo_version: 0.8.0
- The protocol is descriptive guidance for subagents; it does not guarantee outcomes of experiments or the success of edits, and it requires following the brief precisely (four fields).
# Evo Subagent Protocol **Orchestrators reading for context**: this is the protocol your dispatched subagents follow. You don't act on it yourself -- write briefs that satisfy the four required fields described below, and rely on each spawned subagent to drive the loop on its end. Stop reading at "Host conventions" if you only need the brief shape; the rest is for the subagent. ## Evo surface -- subagent perspective What you can pull/dispatch/read as a subagent. Each line is a triggering condition. ``` skills you may pull (Skill tool) └── evo:finetuning before writing or changing any train.py -- technique choice, training recipe, observability, retry discipline. subagents you dispatch (Task tool, subagent_type=...) ├── evo:verifier MANDATORY pre AND post every `evo run`. │ Pre: static analysis before the experiment runs │ (block on failure -- fix and retry). │ Post: result-validity audit after it commits. └── evo:benchmark-reviewer POST-COMMIT only, mode=review-experiment -- per-task failure classification + annotations. Skip on evaluated/discarded/failed outcomes. references (Read tool, on demand) ├── discover/references/ │ ├── sdk_python.py / sdk_node.js wiring per-task instrumen
- Evo surface -- subagent perspective
- Host conventions
- Mid-run user directives (evo direct)
- Important: Working Directory
- Useful Commands
- First Steps
- Iteration Loop
- 0. Re-read shared state (skip on first iteration)
- 1. Formulate the edit
- 2. Create experiment
- 3. Edit the target
- 4. Verify the experiment design (pre-evo run)
- 5. Run the experiment
- 6. Analyze the result
evo scratchpad # bounded state summary evo status # one-line: metric, best score, experiment counts evo show <id> # full state of one experiment (attempts, diffs, annotations, notes) evo path <id> # root-to-node chain with scores evo diff <id> [<other>] # diff vs parent (or between two experiments) evo traces <id> <task> # per-task trace detail Read state across nodes evo awaiting # evaluated nodes awaiting commit/discard decision evo discards [--like <text>] # discarded nodes (optional substring filter on hypothesis) evo annotations # all annotations (filterable with --task/--exp)
What does the subagent skill do?
Protocol that evo optimization subagents follow when dispatched from /optimize. Auto-loaded by spawned subagents via their host's skill loader. The orchestrator may also invoke this skill to understand the brief shape its dispatched subagents expect + what they're required to emit -- useful when writing briefs or debugging a subagent's behavior.
How do I install it?
Run `npx skills add evo-hq/evo --skill subagent --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From evo-hq/evo, a repository with 1,359 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.