Academic Research Skills for Claude Code: How a 165-Skill Pipeline Turns LLMs into Research Assistants Without Full Autonomy

Academic Research Skills (ARS) is a 165-skill pipeline for Claude Code that breaks the academic research workflow into supervised, discrete steps. Instead of handing an LLM full autonomy to write and submit papers, ARS treats the human as the orchestrator and the LLM as a specialized tool that handles literature search, citation formatting, methodology verification, and writing quality checks. The project hit 44,802 stars and trended #1 on GitHub Python in response to Nature’s publication of The AI Scientist (Lu et al., 2026), which demonstrated both the promise and the failure modes of fully autonomous AI research systems.

Why human-in-the-loop beats full autonomy

Lu et al. (2026, Nature 651:914-919) built The AI Scientist, the first fully autonomous AI research system to publish a paper through blind peer review at a top-tier ML venue (ICLR 2025 workshop, score 6.33/10 vs workshop average 4.87). Their Limitations section enumerates the failure modes:

Implementation bugs that produce spurious results
Hallucinated experimental outcomes
Citation hallucinations (citing papers that do not exist)
Methodology fabrication (describing methods never executed)
Frame-lock (inability to pivot when initial hypothesis fails)
Bug-as-insight reframing (treating implementation errors as novel findings)

ARS avoids these by keeping the human in the decision loop at every stage. The LLM proposes, the human approves. The LLM formats, the human verifies. The LLM searches 100+ scientific databases, the human selects which papers to cite.

Architecture: skill registry, state persistence, and handoff boundaries

ARS is not a monolithic agent. It is a skill registry that exposes 165 discrete capabilities through the Agent Skills standard, compatible with Cursor, Claude Code, Codex, Pi, and Antigravity. Each skill is a function with a defined input schema, output schema, and failure mode.

Skill categories

Category	Example Skills	Human Handoff Point
Research	Literature search, database query, citation graph traversal	Human selects which papers to read
Write	Section drafting, style calibration, voice matching	Human approves or rewrites each section
Review	Methodology verification, citation validation, logical consistency check	Human decides whether to fix or ignore flagged issues
Revise	Peer review simulation, response drafting, rebuttal generation	Human approves final revision strategy
Finalize	LaTeX formatting, reference list generation, submission checklist	Human submits the paper

State management

ARS does not maintain a persistent agent state across sessions. Instead, it uses the file system as the state store. Each research project lives in a directory with a .ars/ subdirectory that holds:

plan.json: the paper outline and section assignments
citations.bib: the BibTeX database
style_profile.json: learned voice parameters from past work
review_log.jsonl: append-only log of all review checks and human decisions

This design avoids the need for a database, message queue, or state machine. The human can inspect, edit, or roll back any part of the state by editing files. The LLM reads the state at the start of each skill invocation and writes updates at the end.

Handoff boundaries

Every skill returns one of three outcomes:

Success: the skill completed and wrote its output to the state directory
Needs human decision: the skill found multiple valid options and needs the human to choose
Blocked: the skill cannot proceed without external input (e.g., API key, database credentials)

The orchestration layer (Claude Code’s plugin system) surfaces “Needs human decision” as a prompt in the chat interface. The human responds, and the next skill in the pipeline reads the decision from the state directory.

Tool call flow: literature search example

Here is how the literature search skill works under the hood:

# skills/research/literature_search.py
def literature_search(query: str, databases: list[str], max_results: int = 50):
    """
    Search multiple scientific databases and return ranked results.
    
    Args:
        query: natural language research question
        databases: list of database names (pubmed, arxiv, semantic_scholar, etc.)
        max_results: maximum results per database
    
    Returns:
        SearchResult with papers, relevance scores, and decision prompt
    """
    results = []
    for db in databases:
        connector = get_database_connector(db)
        papers = connector.search(query, limit=max_results)
        results.extend(papers)
    
    # Rank by relevance using embedding similarity
    ranked = rank_by_relevance(query, results)
    
    # Write results to state directory
    write_json(".ars/search_results.json", ranked)
    
    # Return decision prompt
    return {
        "status": "needs_human_decision",
        "message": f"Found {len(ranked)} papers. Review .ars/search_results.json and run /ars-select to choose which to cite.",
        "next_skill": "ars-select"
    }

The human reviews the JSON file, marks papers with "include": true, and runs /ars-select. The next skill reads the selections and adds them to citations.bib.

Database integration: 100+ sources without API key sprawl

ARS integrates 100+ scientific databases across biology, chemistry, medicine, and drug discovery. Instead of requiring the user to sign up for 100 API keys, ARS uses a tiered access model:

Public APIs: PubMed, arXiv, Semantic Scholar, CrossRef (no key required)
Institutional access: if the user is on a university network, ARS detects the proxy and routes requests through it
Fallback to web scraping: if no API or proxy is available, ARS uses a headless browser to scrape search results (rate-limited to avoid bans)

The database connector layer abstracts these differences. Each connector implements a common interface:

class DatabaseConnector(Protocol):
    def search(self, query: str, limit: int) -> list[Paper]: ...
    def fetch_full_text(self, paper_id: str) -> str: ...
    def fetch_citations(self, paper_id: str) -> list[str]: ...

This design allows ARS to add new databases without changing the skill layer.

Style calibration: learning voice from past work

The Style Calibration skill reads the user’s past papers (PDFs or LaTeX source) and extracts stylistic features:

Sentence length distribution
Vocabulary frequency (academic vs. colloquial)
Transition word usage
Passive vs. active voice ratio
Citation density (citations per paragraph)

These features are stored in style_profile.json. When the Writing Quality Check skill runs, it compares the draft against the profile and flags sentences that deviate by more than two standard deviations. The human can accept the flag (rewrite the sentence) or reject it (update the profile to allow the new style).

This is not a humanizer. It does not try to hide the fact that an LLM drafted the text. It tries to make the LLM draft in the user’s voice so the final paper sounds like the user wrote it.

Failure modes and observability

ARS exposes three observability layers:

Skill execution log: every skill invocation is logged to .ars/execution_log.jsonl with timestamp, input, output, and duration
Review log: every review check (citation validation, methodology verification, etc.) is logged to .ars/review_log.jsonl with the issue, the human’s decision, and the rationale
State snapshots: before every destructive operation (e.g., deleting a section), ARS writes a snapshot to .ars/snapshots/ so the human can roll back

The most common failure mode is citation hallucination. The Citation Validation skill checks every citation against the BibTeX database and flags any that do not exist. The human can then search for the correct citation or remove the claim.

The second most common failure mode is methodology fabrication. The Methodology Verification skill reads the Methods section and checks that every claim (e.g., “we trained for 100 epochs”) is supported by code in the repository or data in the results directory. If not, it flags the claim and asks the human to provide evidence or remove it.

Deployment shape: plugin vs. standalone CLI

ARS can be deployed in two ways:

Claude Code plugin: install via /plugin marketplace add Imbad0202/academic-research-skills and invoke skills via slash commands (/ars-plan, /ars-search, etc.)
Standalone CLI: clone the repo and run python -m ars.cli plan for users who prefer terminal workflows

The plugin mode is faster for interactive workflows (planning, drafting, reviewing). The CLI mode is better for batch operations (e.g., validating 50 citations in one pass).

Both modes use the same skill registry and state directory, so users can switch between them without losing work.

Security boundaries: no code execution, no file system writes outside project directory

ARS skills do not execute arbitrary code. They read and write JSON, BibTeX, and LaTeX files in the project directory. They call external APIs (PubMed, arXiv, etc.) but do not execute shell commands or install packages.

The only exception is the LaTeX Formatting skill, which calls pdflatex to compile the final PDF. This is sandboxed using Docker (if available) or a restricted subprocess (if not). The user can disable PDF compilation and compile manually if they do not trust the sandbox.

Technical verdict

ARS is a well-architected human-in-the-loop research pipeline that avoids the failure modes of full autonomy by keeping the human in the decision loop at every stage. The skill registry design is clean, the state management is transparent, and the observability is sufficient for debugging. The 100+ database integrations are a significant time-saver for literature review.

Use ARS when:

You are writing a paper for publication and need citation accuracy
You want to learn the research process by supervising each step
You have domain expertise and can catch methodology errors
You are willing to spend 10-20 hours per paper on review and revision

Avoid ARS when:

You are generating synthetic training data and do not care about factual accuracy
You want to generate 100 papers per day for SEO or spam
You are outsourcing research to an LLM because you do not understand the domain
You need a paper written in under an hour

The main limitation is that ARS requires the human to understand the domain well enough to catch errors. If you do not know whether a methodology claim is valid, ARS will not help you. It will flag suspicious claims, but you still need to decide whether to fix or ignore them.

Use ARS if you are an active researcher who wants to automate the grunt work (literature search, citation formatting, LaTeX compilation) while retaining control over the intellectual work (hypothesis generation, method selection, interpretation). Avoid it if you want an LLM to write papers for you without supervision.

Agentic AI, minus the noise.