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
}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 808 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!
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: AI handles execution, humans own the direction, and every run becomes an inspectable research artifact on disk.
New users should start with the step-by-step guides: English Guide or 中文教程.
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.
| Dimension | AutoR |
|---|---|
| Execution model | A coding agent as the execution layer, AutoR as the research control loop |
| Control model | Human approval by default, with an optional strict reviewer-agent gate for unattended runs |
| Research unit | A reproducible run under runs/<run_id>/ |
| Workflow shape | Nine stages as a directed graph the run navigates; the linear sequence is one path through it |
| Improvement | Drafts are measured and ratcheted, so a stage can only get better — and the score is blind to what the run concluded |
| Quality bar | Artifact-backed outputs, not markdown-only summaries |
| Recovery | Resume, redo-stage, rollback-stage, stage-local continuation |
| Layer | Highlight | What AutoR actually does |
|---|---|---|
| Big idea | Human-centered research execution | AutoR is not an autonomous scientist. AI handles execution; humans retain approval and direction at every stage boundary. |
| Big idea | The stages are a graph, not a list | Analysis that exposes a design flaw can send the run back to Stage 03 instead of writing up around it. AutoR computes which moves are open by checking artifacts on disk; the agent chooses among those and says why. Details |
| Big idea | Improvement that is measured, not hoped for | A refinement round is scored against a rigour rubric read off disk. The best-scoring draft is what gets promoted; a round that scores worse is reverted. A stage can only improve. |
| Big idea | Self-improvement that cannot p-hack | The fitness function is blind to what the run concluded — a refuted hypothesis with clean evidence outscores a supported one resting on an assertion — and any round that moves a hypothesis verdict is rejected outright. |
| Big idea | The harness learns across runs | An optional archive compares each graph edge against runs that reached the same node and did not take it, and reorders which move is preferred. It can never open a guarded edge. |
| Big idea | Research loop over agent loop | The system manages stage progression, validation, repair, recovery, and human checkpoints above the lower-level agent execution loop. |
| Big idea | Every run is a reproducible research artifact | Each run leaves behind prompts, logs, approved summaries, code, data, figures, writing sources, and packaged outputs under runs/<run_id>/. |
| Big idea | Verifiable outputs, not paper-shaped theater | The workflow is judged by inspectable artifacts and human approval, not by whether a generated document merely looks polished. |
| Useful feature | Structured literature organization | Survey notes, bibliographies, related-work tables, and reading artifacts stay under workspace/literature/ instead of disappearing into chat history. |
| Useful feature | Automated experiment manifests | Machine-readable experiment and result files make runs inspectable, comparable, and reusable downstream. |
| Useful feature | Citation verification and writing checks | Writing expects citation verification, figure-link checks, and self-review artifacts before Stage 07 is considered complete. |
| Useful feature | Artifact indexing across stages | artifact_index.json and related manifests help later stages find data, results, and figures without guessing from filenames. |
| Useful feature | Cross-model review veto | When the reviewer approves, a different model family audits that approval and can send the stage back. A veto, never an override, so it can only tighten the gate. |
| Useful feature | Self-improving review policy | Every correction the reviewer demands becomes a standing rule checked on all later stages, recorded in an auditable review_policy.json with the stage and attempt that produced it. |
| Useful feature | Resume, redo, and rollback controls | Long research runs can continue in place, retry a stage, or roll downstream state back without starting over. |
| Useful feature | Deliberating review panel | Instead of one reviewer agent at the approval gate, --review-panel seats a PI, domain expert, methodologist, reproducibility engineer and adversarial reviewer who review independently, cross-examine, then converge — and a blocking objection cannot be approved over. Each run measures the panel against its own single-pass baseline and reports when it did not earn its cost. |
| Useful feature | Two output formats | Stage 07 writes a benchmark-ready markdown report (report/report.md + PNG figures) by default, or a venue-aware LaTeX paper package with a compiled PDF via --output-format latex. |
In practice, that means AutoR is useful not only because of the high-level framing, but also because it handles real research chores: literature organization, experiment manifests, citation verification, artifact indexing, manuscript packaging, and recoverable long-running workflows.
Many systems aim to generate research outputs that look ready.
AutoR takes a harder path:
So the question is not:
Does it look ready?
It is:
Can you verify every part of it?
Latest mainline updates:
--stage-graph adaptive), with the agent choosing the move out of each node among the ones AutoR's guards leave open (--routing auto). Stage drafts are scored against a rigour rubric read off disk and iterated under a champion ratchet, so a stage can only improve (--evolve); a round that scores worse is reverted, and a round that changes a hypothesis verdict is rejected outright. An optional cross-run archive learns which moves pay (--archive). All of it is off by default: a run that passes none of these flags walks 01 through 08 exactly as before, through the same engine. See Recursive Self-Improvement.workspace-write, but users who intentionally need remote GPU or SSH execution can now opt into --codex-sandbox danger-full-access; the setting is persisted in run_config.json and preserved on resume.