autoresearch-wrapper-create

Create a feature-comparison run where each candidate implementation and a no-change control are tuned with equal budgets. Use when the user wants to add a new feature and compare approaches by their t

SKILL.md

GitHub

Autoresearch Wrapper Create

Use the run.sh launcher in this skill's folder (the folder containing this SKILL.md). This block finds it in the standard Claude Code and Codex install locations:

AUTORESEARCH_RUNNER=""
if [ -n "${CLAUDE_SKILL_DIR:-}" ]; then
  AUTORESEARCH_RUNNER="${CLAUDE_SKILL_DIR}/run.sh"
elif [ -n "${CLAUDE_PLUGIN_ROOT:-}" ]; then
  AUTORESEARCH_RUNNER="${CLAUDE_PLUGIN_ROOT}/skills/autoresearch-wrapper-create/run.sh"
else
  for dir in skills/autoresearch-wrapper-create .agents/skills/autoresearch-wrapper-create .claude/skills/autoresearch-wrapper-create "$HOME/.agents/skills/autoresearch-wrapper-create" "$HOME/.claude/skills/autoresearch-wrapper-create" "$HOME/.codex/skills/autoresearch-wrapper-create"; do
    if [ -f "$dir/run.sh" ]; then AUTORESEARCH_RUNNER="$(readlink -f "$dir/run.sh")"; break; fi
  done
fi
[ -n "$AUTORESEARCH_RUNNER" ] || { echo "Could not resolve the autoresearch-wrapper-create launcher" >&2; exit 1; }

Use:

bash "$AUTORESEARCH_RUNNER" create --part <part> --feature "<description>" --candidates <n> --metric <metric> --metric-command "<cmd>" --metric-goal <minimize|maximize>

When this skill is invoked:

  1. If the user has not scanned yet, run scan first. Pass --no-interactive when stdin is not a terminal.
  2. Identify the target part, the feature, the number of approaches, the metric, and the per-arm budget (--rounds and/or --stop-rule). Every arm gets the same budget.
  3. Run create. It sets up arms control + approach-A..N, each with its own setup worktree. control (no change) starts tuning immediately: it exists so gains from tuning are not credited to the feature.
  4. Summarize: run id, arms and their setup worktrees, tuning scope, budget, and the generated program.md. The tuning scope defaults to the target and its direct dependency neighbours; pass --tune-scope "a.py,src/models/" if the user names the knobs to tune (e.g. a config file). Files an arm changes during setup are always added to that arm's scope.
  5. Setup phase: implement the feature differently in each approach-* setup worktree, then start its tuning run:
bash "$AUTORESEARCH_RUNNER" arm-ready --run-id <run> --arm approach-A
  1. Tuning phase, per arm (control included): measure the setup score, then run the normal loop, editing only files in the tuning scope. evaluate rejects out-of-scope edits before running the metric; revert them rather than reaching for --allow-out-of-scope, which is for deliberate exceptions the user approves and is flagged in compare:
bash "$AUTORESEARCH_RUNNER" evaluate --run-id <run> --arm <arm> --candidate seed
bash "$AUTORESEARCH_RUNNER" record --run-id <run> --arm <arm> --candidate seed --status auto --description "setup"
bash "$AUTORESEARCH_RUNNER" allocate --run-id <run> --arm <arm>

An arm is done when its rounds target or stop rule is met.

  1. Compare. Present the table: setup score, tuned ceiling, tuning gain, delta vs. tuned control, and the winner (ties go to control, i.e. the status quo):
bash "$AUTORESEARCH_RUNNER" compare --run-id <run>
  1. Offer to merge the winner and clean up. Confirm with the user before --merge or --prune-branches. If control wins, say plainly that no approach beat the status quo once both were tuned:
bash "$AUTORESEARCH_RUNNER" finalize --run-id <run> --merge

Example

  • /autoresearch-wrapper-create --part src/api.py --feature "add response caching" --candidates 3 --rounds 10 --metric latency_ms --metric-command "python bench.py" --metric-goal minimize