# Agent Digivolve Harness Operator > Turn a vague user request like “make this artifact better or more reliable” into a durable optimization run with fixed evaluation, baseline, one bounded mutation per round, keep-or-revert acceptance, holdout protection, and external memory on disk. Use when an agent should operate or continue a `digivolve` run, or when a prompt, skill, document, or repo task should be improved through an eval-driven iterative loop instead of one-shot edits. Use when this capability is needed. - Skill: `tomevault-io/agent-digivolve-harness-operator` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/agent-digivolve-harness-operator` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/agent-digivolve-harness-operator/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/agent-digivolve-harness-operator --- # Agent Digivolve Harness Entrypoint ## Overview Use the harness to turn repeated local trial-and-error into a stable optimization loop. Treat run state on disk as authoritative. Session memory, compaction, and partial chat history are not authoritative. Start from `run-loop` and `work-packet`, then follow the current packet instead of inventing an ad hoc workflow. This skill is agent-system agnostic. It should tell the current agent how to operate the harness whether the host is Codex, Claude Code, OpenCode, or another system with comparable file, shell, and optional subagent capabilities. ## Authority Model - The harness decides the current phase, next action, and legal writes. - The current `work-packet`, `resume` payload, `runner`, and `case` bundles carry the dynamic instructions for this run. - Do not try to memorize all phase details from this skill. Reread the current harness payload when state changes. - When the harness provides `execution_steps`, `agent_prompt`, or `recommended_commands`, treat them as the immediate contract unless they clearly conflict with explicit user instructions. - The skill provides static operating principles. The harness provides the current run truth. ## Bootstrap - Do not assume this skill lives inside the `agent-digivolve-harness` repository. In the intended packaged setup, the skill can be installed separately from the Python package. - Resolve a usable CLI first. Prefer this order: 1. `AGENT_DIGIVOLVE_HARNESS_CLI` if the host already provides an explicit CLI path 2. `digivolve` if it is already on `PATH` 3. `./scripts/ensure_cli.sh` from this skill directory, which can install the package into a skill-local virtual environment - `scripts/ensure_cli.sh` supports two bootstrap sources: 1. `AGENT_DIGIVOLVE_HARNESS_SOURCE_ROOT` for local development or an unpacked source tree 2. `AGENT_DIGIVOLVE_HARNESS_PACKAGE_SPEC` for a wheel, VCS URL, or PyPI package spec - If neither environment variable is set, the bootstrap script assumes the published package name is `agent-digivolve-harness`. - Repo-local `PYTHONPATH=src python3 -m agent_digivolve_harness.cli ...` is only a development fallback when the source tree is explicitly available. It is not the primary packaged-skill path. - Resolve the active run directory before doing semantic work. The CLI materializes runs under the system temporary directory, so a short run ref like `demo` is only a handle; the harness payloads should expose the canonical absolute run path. - Start with: 1. `digivolve run-loop ` 2. `digivolve work-packet ` - If the run is paused or was interrupted earlier, use `digivolve resume ` and read the recovery payload before continuing. - Treat the current work packet as the primary task boundary. Read `runbook.md` and any required files the packet names when the run is still being initialized or when the packet points there. - When the harness exposes a user-facing status or progress summary, use it to anchor those explanations. ## Execution Rules - Prefer harness commands over manual edits to manifest or score JSON files. - Never treat chat continuity as a substitute for rereading run artifacts. - Before each meaningful phase action, explain the current state to the user in plain language: what is happening, what you are about to do next, and why it matters. Translate harness terms instead of assuming the user already knows them. - During baseline, use the current artifact as-is. - During a step, make exactly one bounded mutation before running cases, and respect `mutation_scope` and `frozen_rules`. - Treat evaluator selection as part of the eval package review with the user. Do not assume the evaluator path is fixed unless the run artifacts already say so. - If the evaluator path is not already fixed by the run artifacts, explicitly ask the user to choose it. Do not silently default to `subagent` or `external_panel`. - If the user changes evaluator path or evaluator identities during review, record that choice with `digivolve configure-evaluators ...` before confirming. - Use `experiment-status`, `runner`, `cases`, and `case` when the active execution contract is unclear. - When evaluation mode is `subagent`, use the current host system's built-in subagent capability. The important contract is not which brand of agent is running, but that the evaluator is independent from the executor while still operating inside the same host system. Codex, Claude Code, and OpenCode are examples, not special cases. - When evaluation mode is `external_panel` and the chosen panel is OpenRouter-backed, prefer `digivolve openrouter-panel-eval ...` over hand-recording verdicts. - Hand subagents a single case bundle when parallelizing. Do not invent a separate contract. - Keep state on disk inside the run directory. If a command updates state, reread the current work packet before making the next decision. - Never run `confirm-evals` without explicit user approval. ## Host Agent Capabilities - Minimum host agent requirements: 1. file access in the run directory 2. shell access to run `digivolve` 3. ability to read current work packets and write back through harness commands - Optional host capability: 1. built-in subagents for `evaluation_mode=subagent` - If the current host does not support built-in subagents, prefer `external_panel` and configure explicit external evaluators with the user. ## Interventions - If the user adds context or preference without invalidating the current step, record it with `digivolve note --message '...'`. - If the user asks to stop while you are still active, use `digivolve interrupt --reason '...'`. - If the session was killed out-of-band and you are only seeing the aftermath on resume, rely on the recovery payload instead of assuming you could have recorded the interrupt yourself. - If the user changes goal, success criteria, evaluation standards, or overall direction, use `digivolve change-direction --request '...'` instead of improvising a continuation. - If the harness moves the run into `replan_required`, update the relevant run artifacts first, then record the reconciled direction with `digivolve replan --summary '...'`. - After any interruption, note, direction change, or replan, reread the current `work-packet` or `resume` payload before continuing. ## Command Pattern - Preferred command form: ` ` - Skill-local bootstrap helper: `./scripts/ensure_cli.sh` - Development fallback when source is explicitly available: `PYTHONPATH=src python3 -m agent_digivolve_harness.cli ` - First-choice flow: 1. `run-loop` 2. `work-packet` 3. phase-specific commands from the packet - Recovery flow: 1. `resume` 2. read `active_step.json` and `logs/events.jsonl` 3. follow the resumed phase or replan requirement - Confirmation flow: 1. `work-packet` 2. discuss checks, cases, and evaluator strategy with the user 3. if the evaluator path changes, run `configure-evaluators` 4. only then run `confirm-evals` - Standard write-back flow for execution: 1. `case` 2. `record-eval` once per check, or `openrouter-panel-eval` for isolated external `model x check` verdicts 3. `finalize-case` 4. `validate-case` 5. `record-summary` 6. `complete-experiment` --- > Source: [MatthewZMD/agent-digivolve-harness](https://github.com/MatthewZMD/agent-digivolve-harness) — distributed by [TomeVault](https://tomevault.io).