Claude Code for Academic Research: 3 Skills to Build a Paper Workflow

From Chat-Based AI to a Structured Paper Assistant

Many researchers using AI for paper writing tend to dump all their materials into the AI at once, expecting a perfect output. But reality often disappoints: the AI can't distinguish between literature evidence, author drafts, and advisor feedback, resulting in output that's neither reliable nor controllable.

The root of this problem lies in how current large language models work—when processing all input information within the same context window, they lack an inherent ability to differentiate between information sources and authority levels. A casual suggestion from your advisor and experimental data from a Nature paper are just different text fragments in the model's eyes, unless you explicitly tell it the difference.

Recently, Mashtak Biller, a PhD researcher at the University of Southern Denmark, published "Claude Code 102 for Academic Researchers," sparking widespread discussion in academic circles. The core idea of this article isn't about using AI to ghostwrite papers, but rather about turning Claude Code into a long-term paper assistant with organized directories, clear rules, and defined roles.

Claude Code is a command-line AI tool from Anthropic. Its key difference from regular chat-based AI is that it can directly operate on local file systems, execute scripts, and read project directory structures. This means it can do more than just converse—it can work like a real assistant within your project folders, reading PDFs, modifying Markdown files, and generating reports. This capability makes "structured project management" possible, because the AI can perceive folder hierarchies and README files, thereby understanding the role of different materials.

Based on the methodology from this article, combined with writing patterns from Nature Skills, we distilled three immediately usable Skills and tested them with a simulated paper project in the knowledge graph domain. The "Skills" mentioned here are structured instruction templates within the Claude Code ecosystem—similar to reusable workflow recipes. They define how the AI should act in specific scenarios, including which files to read, what steps to execute, what output format to use, and what's prohibited. Nature Skills are templates designed with reference to the writing standards of Nature journal series articles. Nature series papers are known for rigorous structure, clear evidence chains, and explicit support for every claim—writing standards that translate well into executable rules for AI.

Design and Testing of Three Core Skills

Skill 1: Paper Workbench Setup—Helping AI Identify Material Roles

The first skill addresses the most fundamental yet most easily overlooked problem: material classification.

When you pile PDF literature, Word drafts, advisor comments, and meeting notes all together, the AI easily confuses their roles. This confusion isn't just about "finding the wrong file"—the deeper impact is Context Contamination. When AI simultaneously processes materials of different natures within the same workflow, information from different sources interferes with each other through the model's attention mechanism. For example, a hypothetical suggestion mentioned in advisor feedback might be mistaken by the model as a confirmed experimental conclusion and cited as fact in subsequent output.

This Skill's function is to divide the project into functional zones and generate usage instruction files for each folder:

• Literature folder: Instructions tell the AI that materials here can serve as paper evidence, but it must verify whether the original text truly supports the claims in the manuscript
• Draft folder: Instructions tell the AI this is the author's draft, and it must not fabricate experimental results, formulas, figures, or references
• Feedback folder: Instructions tell the AI that advisor comments and meeting notes can only serve as revision suggestions, not as literature evidence

This step seems simple, but its value lies in establishing rules once that remain effective throughout the entire project, avoiding the need to repeatedly explain material properties in every subsequent interaction. This is also why it's recommended to assign different tasks to independent assistant instances—each instance only loads context relevant to its task, effectively preventing information cross-contamination.

Skill 2: Literature Evidence Matching—From "Topically Related" to "Argument Support"

This is the most technically demanding part of the entire workflow. The traditional approach is to ask AI to "find me some references" or "add citations to this paragraph," but the problem with this approach is that the AI typically finds literature that's topically related rather than literature that truly supports the specific claim in your text.

The distinction between these two is crucial. "Topically related" means the literature discusses the same field, while "argument support" means the literature contains specific experimental data, theoretical derivations, or method descriptions that can directly provide an evidence basis for a particular claim in your paper. In academic writing, what reviewers check when examining citations is precisely the latter—does the paper you cited actually say what you claim it says?

This Skill's workflow is:

1. Extract the Word draft into readable text
2. Extract PDF literature into text
3. Identify claims in the draft that need literature support
4. Search for original text evidence in the PDF literature
5. Generate a literature-evidence matching report

The report output format is highly detailed, containing for each entry: what the claim in the paper is, which candidate literature is relevant, what the original text evidence from the literature is, support strength assessment, and citation recommendations.

A great comparative case emerged during testing: the draft statement "knowledge graphs can be used to organize and represent complex knowledge" had corresponding triple representation technique descriptions in the PDF literature that could serve as background support. The basic unit of a Knowledge Graph is a triple—an "entity-relation-entity" structure, such as "Beijing-is the capital of-China." The triple representation techniques mentioned in the text refer to methods that map entities and relations in knowledge graphs to low-dimensional vector spaces (such as TransE, RotatE, etc.), enabling machines to infer implicit relationships in knowledge graphs through vector operations.

However, for claims like "our method achieves approximately 18% improvement in accuracy and approximately 12% improvement in recall" in the draft, the report clearly marks "cannot support—must supplement with real experimental results"—because these are the author's own experimental data and cannot be padded with external literature.

This is precisely the core value of this Skill: having AI precisely match evidence around your paper's claims, rather than broadly summarizing literature.

Skill 3: Reviewer Simulation Check—Pre-Submission Risk Warning

The third Skill doesn't directly edit the paper but instead generates a risk report like a reviewer would. It comprehensively reads the paper draft, advisor comments, meeting notes, and the previously generated literature-evidence matching report, then systematically checks for issues in the manuscript.

During testing, it identified several typical problems:

• Experimental results are still estimates, lacking real data
• Main experiment table is missing
• Ablation study is missing
• Formulas and figures are missing
• Related work coverage is insufficient (consistent with the advisor's comment that "recent two years' literature needs more supplementation")

Among these, an Ablation Study is an almost mandatory experiment type in machine learning papers. Its core approach is to remove one component or technique from the model at a time, observe performance changes, and thereby prove each component's contribution. For example, if a model includes three innovations—attention mechanism, residual connections, and data augmentation—the ablation study would remove each one separately, showing how much performance drops without it. Reviewers highly value ablation studies because they prove that each technical contribution in the paper is necessary rather than redundant stacking. Missing ablation studies is one of the common reasons for paper rejection at top conferences.

The final output is a reviewer simulation report ranked by priority, telling the author which areas are most likely to be flagged by reviewers if submitted now.

Six Reusable Principles for AI-Assisted Research

From this article and the test results, six core principles can be distilled:

1. Organize by function: Literature, drafts, feedback, and data each go in their own place—only then can AI distinguish material identities
2. Write clear usage rules for each folder: Put global instructions in the main directory, local rules in subdirectories—write once, effective throughout
3. Plan before complex tasks: For tasks with more than three steps, crossing multiple folders, or producing long outputs, have the AI list steps first, confirm, then execute. The logic behind this principle is that large language models, when executing multi-step tasks without an explicit plan, tend to drift from objectives or miss steps midway. Having AI output a plan first is equivalent to giving it an external scaffold for "working memory"—the researcher confirms before execution, ensuring both correct direction and human decision-making authority.
4. Turn repetitive tasks into fixed commands: High-frequency operations like organizing notes, checking citations, and generating reports should be written as commands, callable with a single line
5. Use different assistants for different tasks: Literature assistant, citation-checking assistant, and reviewer assistant should each be independent to avoid context contamination
6. Citations must be verified against original text: AI saying "this literature is related" and "this literature truly supports your specific sentence" are two completely different things. This point is especially important because large language models have a known "hallucination" problem—they may confidently claim that a certain paper supports a certain viewpoint, when in reality that paper never discussed the relevant content, or the paper itself was fabricated by the AI.

How to Write Your Own Paper Skills

If you want to customize your own Skills based on this approach, start with one specific high-frequency task—don't try to build an entire system from the beginning. For example, "check whether every sentence in my introduction has literature support" or "organize my advisor's comments into a revision checklist."

Once you've chosen a task, break it down into four elements:

• Trigger condition: When to use it (e.g., run after every revision of the introduction section)
• Input requirements: What materials are needed (e.g., the introduction Markdown file + all PDFs in the literature folder)
• Execution steps: Specific operations (e.g., extract claims sentence by sentence → search for corresponding evidence in literature → annotate match strength)
• Output specification: What file to generate (e.g., a Markdown-format matching report, saved in the reports folder)

Particularly important are prohibited actions: cannot fabricate data, cannot overwrite original files, cannot treat suggestions as evidence—these must be explicitly written into the Skill. The design of prohibited actions is essentially setting up "Guardrails" for the AI, which is one of the core concepts in current AI safety. In academic scenarios, guardrails don't limit AI's capabilities but ensure its output always stays within the boundaries of academic integrity. After writing, run it once with real materials to validate, then iterate continuously.

Conclusion: Project Management Thinking Is the Key

The most valuable aspect of this workflow isn't making AI write more, but making it commit fewer critical errors—not misusing literature, not fabricating experiments, not treating advisor comments as evidence, not treating topically related literature as direct support.

The core insight is: if you want AI to truly participate in a long-term paper project, it doesn't rely on one-off chats and magical prompts, but on project structure, rule files, evidence tracking, and repeatable workflows. This parallels the "Infrastructure as Code" philosophy in software engineering—rather than manually configuring environments each time, write configurations as version-controlled, reusable files. Similarly, rather than re-explaining rules in every conversation, embed rules in the project structure. What's truly useful isn't having AI write for you, but having it work according to the workflow you've designed.