autoloop

Files (1)

• SKILL.md

SKILL.md (first lines)

# Autoloop

Autonomous codebase improvement inspired by [karpathy/autoresearch](https://github.com/karpathy/autoresearch). Audit the codebase, pick the highest-impact change, fix it, measure the result, keep or revert, repeat.

## Before Starting

Use `AskUserQuestion` to gather these inputs. Do NOT proceed without answers.

### 1. Objective

Ask: "What do you want to improve? (e.g., test coverage, lint errors, performance, security)"

### 2. Metric Command

Ask: "What command measures success? (e.g., `go test -cover ./...`, `npx jest --coverage`, `ruff check . | wc -l`)"

If the user doesn't have one, detect the stack and suggest:

| Stack | Default metric | Direction |
|-------|---------------|-----------|
| Go | `go test -cover ./...` | higher-is-better (coverage %) |
| TypeScript | `npx jest --coverage` | higher-is-better (coverage %) |
| Python | `pytest --cov` | higher-is-better (coverage %) |
| Rust | `cargo test` | higher-is-better (pass count) |
| Go (lint) | `go vet ./... 2>&1 \| wc -l` | lower-is-better (error count) |
| Any (lint) | `<linter> . 2>&1 \| wc -l` | lower-is-better (error count) |

Confirm with the user: "I'll use `<command>` with <direction>. Correct?"

### 3. Direction

If not obvious from the metric, ask: "Is higher or lower better for this metric?"

### 4. Iterations

Ask: "How many improvement cycles? (default: 10, max recommended: 50)"

### 5. Scope (optional)

Ask: "Any scope constraints? (e.g., only `src/engine/`, only `.py` files, or everything)"

If the user says "everything" or skips, leave scope open.

## Invoke the Workflow

Start the workflow via the devkit engine:

Assemble the input as a single string: `"<objective> | metric: <command> | direction: <higher/lower>-is-better | iterations: <N> | scope: <constraint or 'all'>"`.

Use the `devkit_start` tool with workflow: "autoloop" and input: "{input}".

Then follow each step the engine returns. Call `devkit_advance` after completing each step. The engine controls step order, gates, and loops. Do NOT skip steps.

## Rules

- Never skip the measurement step — every change must be measured
- Never keep a change that regressed the metric — always revert
- One hypothesis at a time — don't bundle changes
- Use the scratchpad (.devkit/scratchpads/current.md) to avoid repeating failed approaches
- Stop when budget is exhausted, iterations are done, or metric stops improving
- Be honest in the report — include reverted attempts, not just successes

From 5uck1ess/devkit, MIT.

More from 5uck1ess/devkit