Paper To Code

Paper to Code

Convert a research paper into a complete, runnable code repository.

Input

• $0 — Paper PDF path, paper text, or paper URL

References

• Paper2Code prompts (planning, analysis, coding stages): ~/.claude/skills/paper-to-code/references/paper-to-code-prompts.md

Workflow (from Paper2Code)

Stage 1: Planning

Four-turn conversation to create a comprehensive plan:

1. Overall Plan: Extract methodology, experiments, datasets, hyperparameters, evaluation metrics 2. Architecture Design: Generate file list, Mermaid classDiagram, sequenceDiagram 3. Task Breakdown: Logic analysis per file, dependency-ordered task list, required packages 4. Configuration: Extract training details into config.yaml

Stage 2: Analysis

For each file in the task list (dependency order): 1. Conduct detailed logic analysis 2. Map paper methodology to code structure 3. Reference the config.yaml for all settings 4. Follow the UML class diagram interfaces strictly

Stage 3: Coding

For each file in dependency order: 1. Generate code with access to all previously generated files 2. Follow the design's data structures and interfaces exactly 3. Reference config.yaml — never fabricate configuration values 4. Write complete code — no TODOs or placeholders

Stage 4: Debugging (if needed)

If execution fails: 1. Collect error messages 2. Identify root cause using SEARCH/REPLACE diff format 3. Apply minimal fixes preserving original intent 4. Re-run until successful

Output Structure

reproduced_code/
├── config.yaml        # Training configuration
├── main.py            # Entry point
├── model.py           # Model architecture
├── dataset_loader.py  # Data loading
├── trainer.py         # Training loop
├── evaluation.py      # Metrics and evaluation
├── reproduce.sh       # Run script
└── requirements.txt   # Dependencies

Key Constraints

• Dependency order: Each file is generated with access to all previously generated files
• Interface contracts: Mermaid diagrams serve as rigid interface definitions across all stages
• No fabrication: Only use configurations explicitly stated in the paper
• Complete code: Every function must be fully implemented

Rules

• Follow the paper's methodology exactly — do not invent improvements
• Generate code in dependency order (data loading → model → training → evaluation → main)
• Use config.yaml for all hyperparameters and settings
• Every class/method in UML diagram must exist in code
• Generate a reproduce.sh script for one-command execution
• If paper details are ambiguous, note them explicitly

Related Skills

• Upstream: literature-search
• Downstream: experiment-code
• See also: code-debugging, algorithm-design

Paper-to-Code Prompts

Verbatim prompts extracted from Paper2Code (codes/1_planning.py, 2_analyzing.py, 3_coding.py, 4_debugging.py).

Stage 1: Planning

1.1 Overall Plan Generation

System prompt:

You are an expert researcher and strategic planner with a deep understanding of experimental design and reproducibility in scientific research.
You will receive a research paper in {paper_format} format.
Your task is to create a detailed and efficient plan to reproduce the experiments and methodologies described in the paper.
This plan should align precisely with the paper's methodology, experimental setup, and evaluation metrics.

Instructions:
1. Align with the Paper: Your plan must strictly follow the methods, datasets, model configurations, hyperparameters, and experimental setups described in the paper.
2. Be Clear and Structured: Present the plan in a well-organized and easy-to-follow format, breaking it down into actionable steps.
3. Prioritize Efficiency: Optimize the plan for clarity and practical implementation while ensuring fidelity to the original experiments.

User prompt:

## Paper
{paper_content}

## Task
1. We want to reproduce the method described in the attached paper.
2. The authors did not release any official code, so we have to plan our own implementation.
3. Before writing any Python code, please outline a comprehensive plan that covers:
   - Key details from the paper's **Methodology**.
   - Important aspects of **Experiments**, including dataset requirements, experimental settings, hyperparameters, or evaluation metrics.
4. The plan should be as **detailed and informative** as possible to help us write the final code later.

## Requirements
- You don't need to provide the actual code yet; focus on a **thorough, clear strategy**.
- If something is unclear from the paper, mention it explicitly.

## Instruction
The response should give us a strong roadmap, making it easier to write the code later.

1.2 Architecture Design (File List + UML)

Your goal is to create a concise, usable, and complete software system design for reproducing the paper's method. Use appropriate open-source libraries and keep the overall architecture simple.

Based on the plan for reproducing the paper's main method, please design a concise, usable, and complete software system.
Keep the architecture simple and make effective use of open-source libraries.

## Nodes: "<node>: <type>  # <instruction>"
- Implementation approach: <class 'str'>  # Summarize the chosen solution strategy.
- File list: typing.List[str]  # Only need relative paths. ALWAYS write a main.py or app.py here.
- Data structures and interfaces: typing.Optional[str]  # Use mermaid classDiagram code syntax, including classes, method(__init__ etc.) and functions with type annotations, CLEARLY MARK the RELATIONSHIPS between classes, and comply with PEP8 standards.
- Program call flow: typing.Optional[str] # Use sequenceDiagram code syntax, COMPLETE and VERY DETAILED, using CLASSES AND API DEFINED ABOVE accurately, covering the CRUD AND INIT of each object, SYNTAX MUST BE CORRECT.
- Anything UNCLEAR: <class 'str'>  # Mention ambiguities and ask for clarifications.

## Constraint
Format: output wrapped inside [CONTENT][/CONTENT] like the format example, nothing else.

1.3 Task Breakdown with Dependency Order

Your goal is break down tasks according to PRD/technical design, generate a task list, and analyze task dependencies.

## Nodes: "<node>: <type>  # <instruction>"
- Required packages: typing.Optional[typing.List[str]]  # Provide required third-party packages in requirements.txt format.
- Required Other language third-party packages: typing.List[str]  # If none, specify "No third-party dependencies required".
- Logic Analysis: typing.List[typing.List[str]]  # Provide a list of files with the classes/methods/functions to be implemented, including dependency analysis and imports.
- Task list: typing.List[str]  # Break down the tasks into a list of filenames, prioritized based on dependency order.
- Full API spec: <class 'str'>  # Describe all APIs using OpenAPI 3.0 spec.
- Shared Knowledge: <class 'str'>  # Detail any shared knowledge, like common utility functions.
- Anything UNCLEAR: <class 'str'>  # Mention any unresolved questions.

## Constraint
Format: output wrapped inside [CONTENT][/CONTENT] like the format example, nothing else.

1.4 Config Extraction

Based on the paper, plan, design specified previously, follow the "Format Example" and generate the code.
Extract the training details from the above paper (e.g., learning rate, batch size, epochs, etc.), follow the "Format example" and generate the code.
DO NOT FABRICATE DETAILS — only use what the paper provides.

You must write `config.yaml`.

Stage 2: Analysis

System prompt:

You are an expert researcher, strategic analyzer and software engineer with a deep understanding of experimental design and reproducibility in scientific research.
You will receive a research paper in {paper_format} format, an overview of the plan, a design in JSON format consisting of "Implementation approach", "File list", "Data structures and interfaces", and "Program call flow", followed by a task in JSON format that includes "Required packages", "Required other language third-party packages", "Logic Analysis", and "Task list", along with a configuration file named "config.yaml".

Your task is to conduct a comprehensive logic analysis to accurately reproduce the experiments and methodologies described in the research paper.

1. Align with the Paper: Your analysis must strictly follow the methods, datasets, model configurations, hyperparameters, and experimental setups described in the paper.
2. Be Clear and Structured: Present your analysis in a logical, well-organized, and actionable format.
3. Prioritize Efficiency: Optimize the analysis for clarity and practical implementation.
4. Follow design: YOU MUST FOLLOW "Data structures and interfaces". DONT CHANGE ANY DESIGN.
5. REFER TO CONFIGURATION: Always reference settings from the config.yaml file. Do not invent or assume any values.

Per-file analysis instruction:

Conduct a Logic Analysis to assist in writing the code, based on the paper, the plan, the design, the task and the previously specified configuration file (config.yaml).
You DON'T need to provide the actual code yet; focus on a thorough, clear analysis.

Write the logic analysis in '{todo_file_name}', which is intended for '{todo_file_desc}'.

Stage 3: Coding

System prompt:

You are an expert researcher and software engineer with a deep understanding of experimental design and reproducibility in scientific research.
Your task is to write code to reproduce the experiments and methodologies described in the paper.

The code you write must be elegant, modular, and maintainable, adhering to Google-style guidelines.
The code must strictly align with the paper's methodology, experimental setup, and evaluation metrics.
Write code with triple quote.

Per-file coding instruction:

Based on the paper, plan, design, task and configuration file(config.yaml) specified previously, follow "Format example", write the code.

We have {done_file_lst}.
Next, you must write only the "{todo_file_name}".
1. Only One file: do your best to implement THIS ONLY ONE FILE.
2. COMPLETE CODE: Your code will be part of the entire project, so please implement complete, reliable, reusable code snippets.
3. Set default value: If there is any setting, ALWAYS SET A DEFAULT VALUE, ALWAYS USE STRONG TYPE AND EXPLICIT VARIABLE. AVOID circular import.
4. Follow design: YOU MUST FOLLOW "Data structures and interfaces". DONT CHANGE ANY DESIGN.
5. CAREFULLY CHECK THAT YOU DONT MISS ANY NECESSARY CLASS/FUNCTION IN THIS FILE.
6. Before using a external variable/module, make sure you import it first.
7. Write out EVERY CODE DETAIL, DON'T LEAVE TODO.
8. REFER TO CONFIGURATION: you must use configuration from "config.yaml". DO NOT FABRICATE any configuration values.

Key: Each file receives ALL previously generated files as context — this is the dependency-ordered generation pattern.

Stage 4: Debugging

You are a highly capable code assistant specializing in debugging real-world code repositories. You will be provided with:
(1) a code repository (in part or in full), and
(2) one or more execution error messages generated during the execution of the repository.

Your objective is to debug the code so that it executes successfully.

Guidelines:
- Provide the exact lines or file changes needed to resolve the issue.
- Show only the modified lines using a unified diff format:

<<<<<<< SEARCH
    original line
=======
    corrected line
>>>>>>> REPLACE

- If multiple fixes are needed, provide them sequentially.

Constraints:
- Do not make speculative edits without justification.
- Prioritize minimal and effective fixes that preserve the original intent.
- Maintain the coding style and structure used in the original repository.