A lot has been done to make AI useful for software development.
Modern codebases give agents structure: source files, tests, linters, CI, documentation, issues, package metadata, and fast feedback loops. That structure is a large part of why AI can now be genuinely useful when writing, reviewing, debugging, and maintaining software.
Academic research usually does not have an equivalent substrate.
Sources, notes, experiments, citations, claims, drafts, and decisions often live in disconnected places. A PDF folder, a Zotero library, a notebook directory, a chat history, a LaTeX draft, a few temporary scripts. Even when the model is strong, that scattered state limits how much support an agent can realistically provide.
That is the part I wanted to improve.
Not by asking an agent to “do the research”, but by giving academic work the kind of structured workspace and specialized agent workflows that software development already benefits from.
I built two open-source tools around that idea:
create-academic-research, an npm project creator for agent-ready academic research repositories;academic-research-skills, a modular skill package for LLM agents working on literature review, citation hygiene, paper writing, review, rebuttal, reproducibility, and research project maintenance.
The goal is not automation for its own sake. The goal is to make serious research easier to organize, inspect, verify, and continue across many sessions.
The missing substrate
Many research repositories start with a familiar shape:
paper/
notebooks/
data/
src/
README.mdThat is better than nothing, but it does not capture the actual lifecycle of a research project.
A real project has source metadata, converted PDFs, search strategies, inclusion and exclusion decisions, claim tables, literature matrices, experiments, negative results, reviewer concerns, writing decisions, artifact checklists, environment notes, and open questions that should not disappear into chat history.
Once an LLM agent enters the workflow, this becomes even more important. An agent can help with literature review, repo maintenance, experiment logging, writing, and critique, but only if the project gives it durable state. Otherwise every session starts by rediscovering the project from raw files and vague instructions.
The repository should make the research state legible. It should show where evidence lives, which claims are supported, how citations are audited, how experiments are logged, which MCP tools are available, which skills are installed, and which documents are authoritative.
That is the substrate these two repos try to provide.
Two layers
The split between the two repositories is intentional.
create-academic-research is the structural layer. It creates the workspace.
academic-research-skills is the behavioral layer. It teaches compatible agents how to work inside that workspace.
The two tools are useful independently. You can use the wizard just to start with a clean research repository. You can install the skills in an existing project. But they are strongest together: structure plus workflows, durable files plus agent behavior.
What the wizard creates
The wizard is used like other project creators:
npm create academic-research@latest my-projectIt scaffolds a research workspace with a structure for:
- source PDFs, derived Markdown, metadata, BibTeX, and conversion ledgers;
- SOTA files, literature matrices, screening notes, gaps, and PRISMA-style artifacts;
- experiment registries, outputs, logs, reproducibility notes, and artifact checklists;
- durable wiki pages for sources, claims, decisions, experiments, research questions, and reviewer concerns;
- project-local agent skills;
- MCP configuration records for scholarly search tools such as arXiv, DBLP, Semantic Scholar, OpenAlex, PubMed, Zotero, Crossref, and Overleaf.
The default setup is intentionally conservative. It creates the structure, installs the academic research skill package locally, enables only low-friction MCP records by default, and documents the optional integrations that need API keys, local applications, or manual setup.
That matters because a public tool should not assume my machine, my preferred agent, or my credentials. The generated project is agent-neutral by default. It records generic capability state and lets the user opt into specific clients, skills, and MCP servers when they need them.
Why skills are separate from the template
The template gives the project a place to put knowledge. The skills tell an agent what good work looks like in that structure.
The package includes separate skills for workflows that should not be collapsed into one vague research-agent prompt:
- source ingestion;
- document conversion;
- SOTA and systematic literature review;
- bibliography normalization;
- citation and claim auditing;
- research design and positioning;
- computer science methodology evaluation;
- paper writing and review;
- adversarial peer review;
- rebuttal and revision strategy;
- artifact and open-science preparation;
- experiment logging;
- research data analysis;
- repository reproduction;
- MCP tooling;
- project maintenance.
Keeping these as separate skills is deliberate. A literature review, a citation audit, an adversarial review, and a rebuttal are different tasks. They need different standards, different artifacts, and different failure modes.
The package is broadly useful for academic work, but it gives first-class support to computer science research: AI and machine learning, systems, security, HCI, software engineering, databases, theory, robotics, information retrieval, programming languages, graphics, and adjacent interdisciplinary work.
Durable project memory
The most important design choice is the wiki/log layer.
Most LLM-assisted research workflows behave like retrieval-augmented chat. You upload papers, ask questions, and the model retrieves fragments when needed. That can be useful, but the synthesis is not persistent by default.
For research, I want the opposite default.
When a source is ingested, the repository should preserve the raw file, record metadata, convert the document when useful, summarize the relevant contribution, update SOTA notes, connect it to open claims, and append the event to a project log. When a question produces a useful analysis, that analysis should become a file, not vanish into the chat.
The wiki is not meant to replace the paper, the code, the data, or the bibliography. It is the maintained memory of the project: what we believe, why we believe it, where the evidence is, and what still needs to be checked.
That makes agent-assisted work more useful and easier to audit. The agent is no longer asked to improvise from a pile of PDFs and a prompt. It has project state to inspect, update, and challenge.
MCPs as research infrastructure
The wizard also records MCP server options for scholarly search and research tooling.
That includes low-friction local runtimes such as arXiv and DBLP, API-backed tools such as Semantic Scholar and OpenAlex, local-app integrations such as Zotero, and credentialed/manual integrations such as Overleaf or Crossref depending on the chosen server.
The important distinction is that MCP configuration is not the same as live capability. A generated JSON snippet is documentation until a client loads it, the command is available, and any required API keys or local services are configured.
That is why the CLI exposes commands such as:
npx academic-research mcp list
npx academic-research mcp env --all
npx academic-research mcp doctor --env-file .env.local
npx academic-research mcp probe arxivI wanted the setup to be explicit. Research tooling should fail loudly when a citation graph API is rate-limited, when Zotero is not running, or when an Overleaf token is missing. Silent partial capability is worse than no capability, especially when citations and evidence are involved.
What this deliberately does not do
This is not a paper generator.
It does not decide whether a research question is good. It does not make weak evidence strong. It does not make a result publishable. It does not remove the need for domain expertise, taste, skepticism, or careful reading.
If anything, the point is to make those things harder to fake.
A serious research agent should ask where the evidence is. It should flag unsupported claims. It should preserve negative results. It should distinguish a paper summary from a verified contribution. It should make bibliography errors visible before submission week.
The repos are designed around that philosophy.
Why I built it now
I started from a practical frustration: I had research proposals, code repositories, archives, PDFs, and early project artifacts that were organized far below the standard I would expect from serious academic work.
The more I tried to clean them up, the more obvious the general problem became. A good research repository needs more than a nicer README. It needs an operating model.
At the same time, LLM agents are becoming useful enough to participate in literature work, repo maintenance, experiment logging, and writing revision. But academic projects usually do not give them the same scaffolding that software projects do.
These two repos are my attempt to make that scaffolding explicit.
Try it
To create a new project:
npm create academic-research@latest my-project
cd my-project
npx academic-research doctorTo install only the skills package in an existing project:
npx -y skills add VincenzoImp/academic-research-skills --skill '*' --copy -yThe short version: the wizard creates an agent-ready research repository; the skills give compatible agents research-native workflows for maintaining it.
Together, they are an attempt to bring the practical benefits of AI-assisted software development to academic research: structure, memory, review, reproducibility, and better feedback loops.