# Paper to code: project starter + verification checklist

A companion to the Bhattu-Chari reel. These are prompts and a workflow, not a tested implementation of a particular paper. Start with a small, understandable algorithm and expand only after the first result works.

## 1. Choose a feasible scope

- Read the abstract, method, evaluation and limitations. Identify one concrete result you want to reproduce.
- Check that you can obtain the data and have enough compute. A full training run may cost money even when code and a skill are freely available.
- Check the paper, code and dataset permissions separately. Cite what you use.
- Prefer a modest baseline or one algorithm over a huge model for a first project.

## 2. Optional skill example

[issol14/paper2code-skill](https://github.com/issol14/paper2code-skill) describes a paper-to-code workflow for Claude Code. Read the current repository, prerequisites and install instructions before deciding to install. This reel does not demonstrate installation or establish support for every coding agent. The workflow can also be described directly in prompts.

## 3. Planning prompt

> Read the attached paper and its supplement. Focus on [specific method or algorithm]. Before writing code, explain the objective, inputs, outputs, equations, assumptions and required data. Distinguish what the paper specifies from what is ambiguous. Do not invent missing details silently. Propose a small implementation plan with component tests and one reproducible baseline experiment. Identify data and compute requirements before expensive runs.

Review that plan yourself. Check equations, units, indexing, dimensions and boundary conditions against the paper.

## 4. Implementation prompt

> Implement the agreed scope in small components. Pin dependencies, put experiment settings in a config file, and include a minimal runnable example. For each component, add meaningful tests based on the specification. Keep a list of assumptions and deviations from the paper. Do not describe mock outputs or unrun experiments as successful results.

## 5. Paper-to-code audit prompt

> Build a table with these columns: paper section/equation/algorithm step; expected behavior; implementation file and symbol; test or experiment evidence; status; gap or assumption. Cover every important step in the agreed scope. Mark out-of-scope sections explicitly. Flag placeholders, omitted preprocessing, changed losses, unsupported parameter choices and evaluation mismatches. Separate inspection findings from behavior actually tested. An agent's confidence is not evidence.

## 6. Verify independently

- Check tiny examples where the expected answer is known. Test shapes, numerical ranges, edge cases and failure behavior.
- Check dataset version, preprocessing and train/validation/test split. Avoid leakage between splits.
- Check hyperparameters, objective/loss, optimiser and stopping conditions where relevant.
- Use the same metric definition and evaluation protocol before comparing scores. Keep baseline and candidate conditions comparable.
- Record seeds, dependency versions, hardware, commands and actual logs. Where practical, repeat stochastic runs and report variation.
- Compare observed behavior with a baseline and the paper's target result. Investigate differences; do not silently change the target.
- If only a simplified demo ran, call it a simplified demo. Passing unit tests alone does not establish reproduction of the full paper.

## 7. README and résumé

Include the paper citation, installation/run instructions, scope, your contributions, measured results and limitations. Explain borrowed code and respect its licence. Never claim the paper's original research as your own.

Suggested résumé structure:

> Implemented [method] from [paper] using [stack]; evaluated against [baseline] on [dataset/protocol]; achieved [your actual measured result] and documented [limitation or tradeoff].

Replace the brackets with verified facts from your own work. Be ready to explain decisions and modify the code during an interview. One well-understood project is more useful than a long list you cannot defend.

## Release checklist

- [ ] Agreed scope implemented; omissions documented.
- [ ] Meaningful tests run; commands and results recorded.
- [ ] Baseline/evaluation comparisons are fair and actually executed.
- [ ] README reproduces the environment and demo.
- [ ] Paper/code/data attribution included.
- [ ] Résumé claims match the work and results.