autoloop
Skill4 starsChanged 4 months agoMITView on GitHub
Autonomous improvement loop inspired by karpathy/autoresearch — use when asked to run an autoloop, auto loop, autonomous improvement, or run experiments overnight on the codebase.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- bazaarjapan/codex-autoloop-templatetheir own version, first seen Aug 22, 2026
- sameerhimati/claude-code-kittheir own version, first seen Aug 14, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- sameerhimati/claude-code-kit★ 1same name
- bazaarjapan/codex-autoloop-template★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository40 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- adrSkill
- auditSkill
- browserSkill
- bugfixSkill
- changelogSkill
- clean-codeSkill
- creating-workflowsSkill
- deep-researchSkill
- doc-genSkill
- dont-reinventSkill
- drySkill
- executingSkill
- featureSkill
- gcliSkill
- harness-auditSkill
- healthSkill
- mega-prSkill
- onboardSkill
- pr-readySkill
- refactorSkill
- researchSkill
- scrapeSkill
- scratchpadSkill
- screenshotSkill
- self-auditSkill
- self-improveSkill
- self-lintSkill
- self-migrateSkill
- self-perfSkill
- self-testSkill
- setup-rulesSkill
- stuckSkill
- test-genSkill
- tri-debugSkill
- tri-dispatchSkill
- tri-reviewSkill
- tri-securitySkill
- yagniSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 8 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Use AskUserQuestion to gather these inputs.
- Distinctive: line 16
Ask: "What do you want to improve?
- Very specific: line 20
Ask: "What command measures success?
- Distinctive: line 22
If the user doesn't have one, detect the stack and suggest:
- Distinctive: line 37
If not obvious from the metric, ask: "Is higher or lower better for this metric?"
- Distinctive: line 41
Ask: "How many improvement cycles?
- Very specific: line 45
Ask: "Any scope constraints?
- Distinctive: line 47
If the user says "everything" or skips, leave scope open.
- Very specific: line 51
Start the workflow via the devkit engine:
- Very specific: line 55
Use the devkit_start tool with workflow: "autoloop" and input: "{input}".
- Distinctive: line 61
Never skip the measurement step — every change must be measured
- Distinctive: line 62
Never keep a change that regressed the metric — always revert
- Very specific: line 64
Use the scratchpad (.devkit/scratchpads/current.md) to avoid repeating failed approaches
- Distinctive: line 65
Stop when budget is exhausted, iterations are done, or metric stops improving
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Autoloop
Autonomous codebase improvement inspired by 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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.