by tangxiangru
AI handles execution, humans own the direction, and every run becomes an inspectable research artifact on disk.
# Add to your Claude Code skills
git clone https://github.com/tangxiangru/AutoRLast scanned: 8/6/2026
{
"issues": [
{
"file": "README.md",
"line": 798,
"type": "dangerous-command",
"message": "Dangerous command (disables permission prompts): \"bypassPermissions\"",
"severity": "medium"
}
],
"status": "PASSED",
"scannedAt": "2026-08-06T06:30:10.783Z",
"npmAuditRan": true,
"pipAuditRan": true,
"promptInjectionRan": true
}See how AutoR compares with popular alternatives.
AutoR is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by tangxiangru. AI handles execution, humans own the direction, and every run becomes an inspectable research artifact on disk. It has 805 GitHub stars.
Yes. AutoR passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/tangxiangru/AutoR" and add it to your Claude Code skills directory (see the Installation section above).
AutoR is primarily written in Python. It is open-source under tangxiangru on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh AutoR against similar tools.
No comments yet. Be the first to share your thoughts!
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.
AutoR is not a chat demo, not a generic agent framework, and not a markdown-only research toy.
It is a structured research harness over a coding-agent execution layer: the agent handles execution, the human owns the direction, and every run becomes an inspectable research artifact on disk.
docs/framework.md is the single document that describes what this system is: its implementation, its modules, what is new in it, and what it contributes. This README is the overview and the operating manual.
What AutoR is · Quick start · The stage graph · The rigor dial · Self-improvement rounds · Review · The stage contract · Execution model · Run layout · Architecture · Benchmarks (ResearchClawBench · FIRE-Bench · AIRS-Bench) · Documentation · Limits · License
Most autoresearch systems optimize for autonomy. AutoR takes a different position: research is too important to hand over as a blind end-to-end loop. The goal is not to remove humans from research. The goal is to give them a stronger execution system.
AutoR runs a research project as eight stages wired into a directed graph. Six of the forward
edges are guarded by artifacts on disk; thirteen backward edges let a late finding send the run
back — Stage 07 can reopen the literature survey. Hypotheses are frozen and hashed when Stage 04 is
approved, every one must be adjudicated at Stage 06 against a named result file that exists, and
every paper claim traced at Stage 07; a supported or refuted verdict resting on a single seed is
refused unless the run records why one run settles it. An adversarial reviewer attacks Stage 05's
results and Stage 06's analysis, and the stage after each must answer every finding in writing or the
gate refuses it. Drafts are scored and a refinement that does not improve is reverted. Every stage
still stops at an approval gate, and by default that gate is you.
| Move | What runs | Where |
|---|---|---|
| Propose | Five proposers work from distinct lenses — mechanism, contrarian, adjacent field, null/artifact, regime — blind to each other; two statements whose Jaccard overlap reaches 0.5 collapse into one idea | ideation_panel.py |
| Test | Every baseline declares why_competent and a tuning_budget before it runs; the hypothesis set is frozen and hashed before any result exists, and a later change is legal only as a recorded amendment |
experimental_protocol.pypreregistration.py |
| Refute | An adversarial pass asks why the result is wrong across ten named failure modes — confound, leakage, metric_cherry_picking, effect_within_noise, six more; a round can close as converged, refine_design, new_hypothesis or abandon |
validity_review.pyresearch_rounds.py |
| Critique | Five seats review independently, cross-examine anonymised, then converge; a blocking objection is turned into a refusal in code against the panel's own chair, and a different model family audits the approval as a veto | review_panel.pycross_reviewer.py |
| Iterate | Every valid draft is scored against a rubric read off disk; the champion is kept and a losing polish round is reverted before anyone reads it; a draft that loses on the weighted total but is non-dominated on the criterion vector is kept anyway | rubric.pyevolution.pypareto.py |
| Learn | Each finished run records its route and measured fitness; a fitness comparison is keyed on the set of stages the run actually measured, so a run cannot score well by stopping early | archive.pydecisions.py |
| Deliberate | A stage that hits a genuine crux stops, names the question, and pulls in theorist / empiricist / critic / pragmatist plus an expert brief, then continues with an answer that names its own falsifier; budgeted, and measured against what the agent already believed | deliberation.py |
| Localise | A reviewer quotes the passage it objects to instead of refusing the whole stage; the revision is told to change only those spans and is diffed against them, so "preserve the correct parts" is measured rather than hoped for | stage_comments.py |
What a default run (--rigor standard) actually uses. Test, Refute, Iterate and
Learn are on: the validity chain is unconditional at every rigor level including fast,
--evolve defaults on, and the archive records every run — though it only steers under
--archive-steer. Localise runs whenever a reviewer quotes a passage, which requires an agent
reviewer. Propose and Deliberate need --rigor thorough; Critique's panel needs
--rigor max and its cross-model veto is live on the rcb_agent.py path only. See
the rigor dial for the exact mapping.
AutoR does not run itself. Manual approval is the default: approval_mode is manual unless a
flag opts out. Seven of the eight moves above can only score, refuse, revert or re-order; none of
them can approve a stage. The eighth, the review panel, is an approval gate, and it exists only on
the runs where you hand it the gate. Recursion did not change who decides; it changed what reaches
the desk. The research unit is unchanged: one reproducible run under runs/<run_id>/, isolated,
resumable, with redo and rollback.
Approved stage summaries are the only free-text cross-stage memory. Every other cross-stage edge is
a typed artifact with a declared reader: twenty typed channels in
information_flow.py each name the exact stage slugs that consume them,
and the nine channels produced inside the walk name their producing stage as well. obligations.json and
review_policy.json cross stages without touching a summary at all — both only behind an agent
approval gate.
Many systems aim to generate research outputs that look ready. So the question is not
Does it look ready?
It is
Can you verify every part of it?
The answer is the validity chain — freeze at Stage 04, adjudicate at Stage 06, trace at Stage 07
(preregistration.py) — and the edge into writing stays shut until every
frozen hypothesis carries a verdict (_guard_validity_chain, stage_graph.py).
Every number below comes from a named symbol in the source. Re-derive them; that is the point of naming them.
| Count | Symbol | Value |
|---|---|---|
| Stages (nodes in the walk) | STAGES, src/utils.py |
8 |
| Guarded forward edges | _ADVANCE_GUARDS, src/stage_graph.py |
6 |
| Backward edges | REVISIT_EDGES |
13 |
| Conditional terminal edges | TERMINAL_EDGES |
1 |
Edges in the default (adaptive) graph |
StageGraph.adaptive() |
22 |
Edges in --stage-graph linear |
StageGraph.linear() |
9 |
| Typed information channels | CHANNELS, src/information_flow.py |
20 |
validate_* functions the stage gate calls |
validate_stage_artifacts, src/utils.py |
17 |
| Required stage-summary headings | REQUIRED_STAGE_HEADINGS |
7 |
| Rubric criteria (weighted, backend-free) | CRITERIA, src/rubric.py |
10 |
Flags on main.py / rcb_agent.py |
parse_args |
61 / 37 |
| Python modules / lines / tests | the tree | 254 / 137 k / 4053 |
python -m unittest discover -s tests -p "test_*.py" runs 4053 tests in ~440 s across 143 test
modules, with no third-party dependency.
PATH for real runs