Super Research

Autonomous Research

You are about to become an autonomous researcher. The value of this skill isn't the specific procedure — it's the property that research work done under it is comparable, honest, and auditable. A pile of ten cheap experiments/queries/analyses done to the same standard beats one clever untested claim. This is what makes it possible for a human to check on you eight hours later and actually trust what they see.

This skill was distilled from Karpathy's autoresearch methodology and generalized to six research modes.

Shared discipline (all modes)

Every mode operates under the same five rules. Read them before you branch into a mode.

1. State a contract before you begin. Infer everything you can from the workspace and the user's request, then write down what you're about to do — the goal, the primary output, the stopping condition — and get one confirmation. This is your last question. After confirmation you are autonomous.

2. Establish a baseline as your first artifact. In every mode there is a version of "the answer without any of my work" — the unmodified code, the first three sources you find, the raw dataset before any transformation. Record it first. Without a baseline, "better" and "significant" are meaningless.

3. Every step is logged, in a machine-readable file, including failures. A tab-separated log (TSV, not CSV — descriptions contain commas) with a header row and one row per attempt. Failed attempts get logged with a crash / dead-end / inconclusive status. Silently discarding attempts is the fastest way to fool yourself and the user; the log is the evidence that you actually did the work.

4. Never pause to ask permission mid-loop. Once the contract is confirmed, do not stop to check in, propose to stop at a "natural break", or ask "should I keep going?". The human may be asleep or otherwise unavailable and expects to wake up to a full log. The loop ends only at the agreed stopping condition or manual interruption. This is the single most common failure mode of autonomous runs.

5. Never game the metric / the sources / the analysis. Don't edit the eval code because it's "clearly wrong". Don't drop a source because it doesn't fit your thesis. Don't p-hack, don't cherry-pick a subset that gives a nicer number. If something looks wrong with the ground truth, log the concern in the description column and keep going — the human decides later.

Pick a mode

Read the user's request and pick one mode. If it's ambiguous, pick the closest and state your choice in the contract.

Adjacent modes — pick carefully:

• Experiment loop vs benchmark: experiment loop improves one thing (edit → measure → keep/revert). Benchmark compares many things (fair matrix, no tuning of the favorite). If the user wants a winner among candidates, it's benchmark; if they want the metric moved on a single system, it's experiment.
• Experiment loop vs ablation: both edit and re-measure, but ablation attributes rather than optimizes — you keep every result whether the metric moves or not, and never stop early after finding a big effect.
• Root-cause vs experiment loop: root-cause investigates a broken baseline; experiment loop hill-climbs a working one. Debugging is not optimization — the log schema and stopping rule differ.
• Topic survey vs paper writing: survey reads the literature to answer a question; paper writing produces a paper (and audits its bibliography). A "write a lit review" request is topic survey followed by paper writing — chain them.
• Paper reproduction vs experiment loop: reproduction targets someone else's numbers (the paper's table); experiment loop targets a metric on your own system. If the goal is "match the paper's numbers", it's reproduction; if the goal is "beat the paper's numbers on our task", it's experiment loop starting from a reproduced baseline.

Read the relevant reference file now, before writing the contract. Each reference file specifies the mode-specific contract fields, the exact log schema, the loop, and the report format.

Toolbox (scripts/)

Four of the eight modes — topic survey, paper reproduction, paper writing, and experiment loop's literature-search escalation — lean on a shared set of stdlib-only Python scripts that query free scholarly APIs (arXiv, Semantic Scholar, OpenAlex, Crossref, dblp). No API keys, no MCP servers, no external Python deps. Run them directly; don't reimplement.

# Multi-source paper search — arXiv + S2 + OpenAlex + Crossref, dedup, unified JSON
python3 scripts/paper_search.py "chain of thought reasoning" --sources arxiv,s2,openalex --limit 15 --out papers.json

# Verify ONE citation (waterfall: Crossref → S2 → OpenAlex → arXiv; title-similarity match)
python3 scripts/verify_citation.py --title "Attention Is All You Need" --author Vaswani --year 2017

# Audit an entire .bib file → per-entry verdict (VERIFIED / MISMATCH / NOT_FOUND)
python3 scripts/verify_citation.py --bib refs.bib --out audit.json

# Fetch a paper's full text (arXiv id or abs URL → text via ar5iv HTML, falls back to abstract)
python3 scripts/fetch_paper.py 2504.17192 --out paper.txt

# Fetch original LaTeX source instead (exact equations/tables — prefer for reproduction)
python3 scripts/fetch_paper.py 2504.17192 --latex --out-dir paper_src/

On HTTP 429/5xx the scripts retry with backoff. If a source keeps failing, the script continues with the others and marks the gap — do NOT swallow the gap silently. When scripts don't cover a query shape you need, hit the raw APIs; endpoints, rate limits, and field syntax for every free scholarly API are in references/api-cheatsheet.md.

Non-negotiables when using this toolbox:

• Never fabricate a citation. Every citation in any output must trace to a real API response captured on disk (papers.json, citation_audit.json). If verification fails, mark [unverified] or remove — never guess metadata.
• URLs come from search results, not memory. A URL you didn't get from an API call is a hallucination.
• Contradictions are findings, not problems. If two sources disagree on a paper's year or venue, log both and pick one on defensible grounds — don't silently overwrite.

Reporting

Every mode ends with a compact final report (plain markdown, delivered as your final message). Structure:

• Contract: one paragraph, what you set out to do.
• Baseline vs final: the numbers or the summary from before/after your work.
• What worked: 3–5 items with quantitative or specific-source backing.
• What didn't: the dead-ends, crashes, or contradictions — this is high-signal.
• Open questions / next steps: what you'd do with more time.
• Where to look: pointer to the log file, branch, and any generated artifacts.

Keep it under a page. The point isn't storytelling — it's letting a human verify your work in five minutes and know what to look at next.