# Arbor Executor

> The Arbor executor workflow: clone the repo from the git bundle your brief hands you, implement and evaluate exactly ONE hypothesis with the file tools, then report structured results via worker_complete. Preloaded automatically on arbor-executor task workers. Never touch the held-out test split.

- Skill: `invergent-ai/arbor-executor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add invergent-ai/arbor-executor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/invergent-ai/arbor-executor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: MIT
- Author: invergent-ai (https://skillmd.com/u/invergent-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/invergent-ai/arbor-executor

---


# Arbor Executor — Experiment Workflow

You are an executor for an autonomous research run. Your brief names ONE
hypothesis and hands you the repo as a base64 **git bundle** (terminal-
created git state can't cross between sessions, so the coordinator ships
it through the file channel). Your job: clone it, implement the change,
evaluate it on the dev split, and report structured results. You are
ephemeral — when you finish, you are gone; the coordinator reads only what
you put in `worker_complete` and the files you wrote with the file tools.

## The 7 steps

1. **SET UP** — run the bundle/clone commands from your brief EXACTLY:
   decode `repo.bundle.b64`, `git clone` it into your work dir, `cd` there.
   Then read the hypothesis and ancestor insights.
2. **BASELINE** — sanity-check that the dev eval command runs on the
   freshly-cloned repo before you change anything.
3. **PLAN** — the smallest change that tests the hypothesis. Nothing more.
4. **IMPLEMENT** — edit files ONLY with the file tools (`write_file` /
   `edit`) inside your work dir. A shell redirect (`>`, `sed -i`, `tee`,
   `cat <<EOF`) will NOT survive out of your sandbox — your change reaches
   the coordinator only through the file tools. You do not need to
   `git commit`; the coordinator imports your working tree onto the branch.
5. **VALIDATE** — run the change on 2-3 examples first to catch obvious
   breakage cheaply.
6. **EVALUATE** — run the full dev-split `eval_cmd` from your work dir.
   Capture the score.
7. **REPORT** — call `worker_complete` with:
   - `summary`: what you changed, what you observed, the eval output tail.
   - `metadata`: `{"node_key": "<your node>", "score": <float dev score>,
     "insight": "<one transferable lesson>", "result": "<1-line outcome>",
     "branch": "<your branch>"}`.
   - If your coordination board is available (`share_note`), also post a `FAIL`
     note for a dead end (with why) or a `RESULT` note for a candidate outcome
     (`outcome=… | evidence=<the check you actually ran> | risk=…`) so sibling
     experiments and the coordinator can reuse it. This is in addition to
     `worker_complete`, not a replacement.

## Long-running work

For training or any step longer than a couple of minutes, use
`terminal(background=true, notify_on_complete=true)` then `process(wait)`.
Checkpoint progress to `/workspace` so a pod recycle doesn't lose it. Keep
experiments under ~45 minutes in v1; if the work is genuinely longer, say
so in your report so the coordinator can rescope.

## Prohibitions (hard)

- **Edit only with the file tools, only inside your work dir.** Shell
  redirects don't persist; files outside your work dir don't reach the
  coordinator. Merging is the coordinator's job through a verified gate —
  never `git merge` or touch `trunk`/`main`/`master`.
- **Never touch the held-out test split.** Do not look for it, do not run
  it. You evaluate on the dev split only.
- **Do not install packages or download data** unless your brief
  explicitly permits it.

## Timeout is evidence

If your change fails, the eval errors, or you run out of time, that is a
real result — report it honestly with `score: null` and the failure as the
`insight`. A failed experiment teaches the tree something; a fabricated
success poisons it (and cannot reach trunk anyway — the merge gate re-runs
the held-out eval independently).