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.mdskills/autoresearch-wrapper-create/SKILL.md
GitHubAutoresearch 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:
- If the user has not scanned yet, run
scanfirst. Pass--no-interactivewhen stdin is not a terminal. - Identify the target part, the feature, the number of approaches, the metric, and the per-arm budget (
--roundsand/or--stop-rule). Every arm gets the same budget. - Run
create. It sets up armscontrol+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. - 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. - 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
- Tuning phase, per arm (
controlincluded): measure the setup score, then run the normal loop, editing only files in the tuning scope.evaluaterejects 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 incompare:
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.
- 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>
- Offer to merge the winner and clean up. Confirm with the user before
--mergeor--prune-branches. Ifcontrolwins, 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