跳到正文
cccskills
免费在 GitHub 公开

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.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md3.8 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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).

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

The Arbor research-coordinator protocol: the OBSERVE -> IDEATE -> SELECT -> DISPATCH -> DECIDE cycle over a durable Idea Tree. Preloaded automatically on /auto-research sessions. The coordinator never edits code or runs commands — executors do that in isolated worktrees; the coordinator steers the tree with idea_tree / dispatch_experiments / merge_experiment.

中文简介正在准备中。当前显示原文说明。

invergent-ai/surogates282026年10月19日 更新

Hard-gated ideation for an Arbor research run. Load at the START of every IDEATE round, before drafting any hypothesis. Enforces the PI mindset (mechanism over knob), the four-question first-principles probe, the kill-filter, and the four-line hypothesis format. Ported from Arbor's idea_drafting + first_principles_probe.

中文简介正在准备中。当前显示原文说明。

invergent-ai/surogates282026年10月19日 更新

DECIDE-phase doctrine for an Arbor research run: when to merge, prune, combine, or finalize; how the held-out merge gate works; and the rule that the final report uses TEST scores. Load before deciding what to do with completed experiments.

中文简介正在准备中。当前显示原文说明。

invergent-ai/surogates282026年10月19日 更新

Intake for an autonomous research run (Arbor). Use when the user wants to optimize a metric in a repo over many isolated experiments — 'optimize this benchmark', 'improve the model F1 overnight', 'beat the leaderboard'. Discovers the repo/eval/splits, measures the baseline, confirms a Research Contract, then emits a ready-to-send /auto-research command. Does NOT start the run itself.

中文简介正在准备中。当前显示原文说明。

invergent-ai/surogates282026年10月19日 更新

You MUST use this before any creative work — creating features, building components, drafting documents, designing workflows, or modifying behavior. Explores your human partner's intent, requirements, and design before any implementation begins.

中文简介正在准备中。当前显示原文说明。

invergent-ai/surogates282026年10月19日 更新

Reflective pass over your memory — merge duplicates, fix stale facts, prune what no longer matters. Use when the user asks to clean up or review what you remember, or when memory has grown cluttered or contradictory.

中文简介正在准备中。当前显示原文说明。

invergent-ai/surogates282026年10月19日 更新

查看 invergent-ai 的全部技能

报告此技能的问题