Workshop

Practical AI for Academics

Everything from the workshop in one place: the slides, the Claude Code skills we use in the hands-on blocks, the setup guides, and the exercises. Bookmark this page. It stays up as the tools change, and the skills repository is updated as I revise them.

Slides

Set up before Session 2

Session 2 assumes the setup from Session 1: VS Code, Claude Code, and a project folder with a CLAUDE.md. Doing this between the sessions saves the first half hour.

  1. Install VS Code and Claude Code. The Claude Code in VS Code guide walks through installation, the extensions worth having for Stata, Python, R, and LaTeX, and the first session. Claude Code needs a Claude account. The free tier is enough to follow along, and the Pro tier (about $20 a month) removes the limits you will otherwise hit during the hands-on blocks.
  2. If your paper lives in Overleaf, link it to a folder on your computer so the agent can read it. Linking VS Code and Overleaf covers the GitHub and Dropbox routes.
  3. Install the skills below and restart VS Code.
  4. Bring one draft you would like another pair of eyes on, preferably close to finished, and four or five PDFs of your own writing for the voice.md block. Intros, abstracts, and paragraphs you are proud of. Leave out co-authored sections where the prose is not yours.
Nothing you put in a project folder is uploaded anywhere until you ask the agent to read it, but the agent does read what you point it at. Keep licensed and restricted data out of the folder. Session 2 has a block on how to work alongside secure servers.

Install the skills

A skill is a markdown file that Claude Code loads when you type its / command. Most skills used in the workshop is in one public repository, github.com/claesbackman/AI-research-feedback (MIT licence). Fork them, edit them, make them yours. Two ways to install.

Without a terminal

Windows Explorer or macOS Finder.

  1. Download the zip below and unzip it.
  2. Open the Skills folder inside. Copy each skill folder (review-paper, review-paper-light, and so on) into ~/.claude/skills/.
  3. That is a hidden folder in your user folder: C:\Users\you\.claude\skills on Windows, /Users/you/.claude/skills on a Mac. To see hidden folders in Explorer: View → Show → Hidden items. In Finder: Cmd-Shift-. in your home folder.
  4. Restart VS Code. Type / in Claude Code and the skills appear.
Download all skills (zip)

With a terminal

macOS, Linux, or WSL. Paste this one line. Run it again later to update.

git clone --depth 1 https://github.com/claesbackman/AI-research-feedback.git /tmp/airf && mkdir -p ~/.claude/skills && cp -R /tmp/airf/Skills/. ~/.claude/skills/ && rm -rf /tmp/airf

A skill in ~/.claude/skills/ works in every project. One in project/.claude/skills/ works only in that project. The README has one-line installers for individual skills.

What each skill does

An overview of some of the skills that we cover in the workshop. Each skill is a few hundred lines of plain markdown you can open and change.

CommandWhat it doesWhen to use it
/review-paper Pre-submission referee report. Eight subagents run in parallel: spelling and style, internal consistency, unsupported claims and identification, mathematics, tables and figures, a referee assessment, a contribution advocate, and a contribution skeptic. Add a journal: /review-paper JF. A draft you are about to circulate or submit. Ten to fifteen minutes.
/review-paper-code Maps the paper's empirical claims to the code. Checks reproducibility, sample restrictions, clustering, fixed effects. Before a replication package leaves your hands.
/explain-diff Explains a code change as an offline HTML page: what the code did before, what changed, what it does to the results, and a five-question quiz. When you need to understand a change well enough to defend it.
/voice-extractor Reads a folder of your own papers and writes a voice.md: phrasing, sentence rhythm, hedging style, and a ban list. Written by Mihail Velikov. You can download it here. The Session 2 voice block. Once per author.
/explorable-explanations Builds an interactive explanation of a topic as a tree of short HTML pages the reader moves through, in the style of Nicky Case's The Evolution of Trust. Written by Nityesh Agarwal. You can download it here. Explaining a mechanism or a model to students or a non-specialist reader.
/explorable-deck Builds an interactive presentation based on the same format as /explorable-explanations. The presentation is done in Quarto-Markdown and is best done by Fable. . Creating an interactive presentation with a clear narrative.

Hands-on blocks

The instructions from the Session 2 slides, so you can follow them without switching windows.

1. A referee report on your own draft

  1. Open the folder with your draft in VS Code and start Claude Code.
  2. The draft needs to be LaTeX or markdown. If you only have a PDF, run /pdf-to-markdown draft.pdf first.
  3. Run /review-paper-light for the one-minute version, or /review-paper for the full eight-agent run. Add a journal if you have one in mind.
  4. Read the report in reviews/. It is not all correct.

Debrief. What did it catch that you would not have seen? What did it get wrong? Which agent gave the most useful feedback?

2. A voice.md from your own writing

  1. Put four or five PDFs of your own writing in a folder, say sample-papers/. Five to ten thousand words is plenty.
  2. Run /voice-extractor sample-papers.
  3. Read voice.md and edit anything that does not sound like you. The file is yours, not the model's.
  4. Reference it from CLAUDE.md so every future session loads your voice.

Check it works. Ask Claude to rewrite a paragraph with and without voice.md in context. If you cannot tell the versions apart, the file needs sharper rules.

3. Does the code do what the paper says?

Run /review-paper-code in a folder that holds both the draft and the analysis scripts. It maps each empirical claim in the text back to the code that produced it and flags the places where they disagree: a sample restriction described in the paper but absent from the script, clustering that does not match, a table number that no longer matches the output. Useful before a replication package leaves your hands.

4. A style file for slides

Put a few old presentations in a folder and ask Claude to describe their structure, palette, and title style. Save the answer as slides-style.md and reference it whenever you ask for a new deck. Build it once, use it for every deck after.

Working with licensed and confidential data

Most of what we work with cannot be pasted into a chat window. WRDS data sits behind a licence, register data sits on a secure server, and supervisory data never leaves the building. The workflow that makes agentic tools usable here separates two things that usually get tangled together.

The logic

How the tables link, how fiscal years align to returns, which rows are usable. This is public knowledge, it is the hard part, and it can be written and tested without touching licensed data. Build it against synthetic data with the same schema.

The data

Proprietary, and only needed at the end. When the logic works, swap the loader and point it at the real thing. Nothing else moves. What does not transfer is the loading layer, where the schema surprises live.

Synthetic data only contains the bugs its author already imagined. It catches structural breakage, not a sample that is quietly wrong. The check that finds those is an external benchmark: rebuild a published number first, and if the pipeline cannot reproduce a known answer, nothing it produces afterwards is worth reading.

A CLAUDE.md starter template

CLAUDE.md sits in the project folder and is loaded at the start of every session. Type /init in Claude Code to have it drafted from the folder, or start from this and edit. 

# About me
I am a researcher in [field].

# How I want you to work with me
- Ask clarifying questions before generating long output.
- Critical, skeptical tone in feedback. Do not flatter.
- When editing, preserve my voice (see voice.md). No generic LLM phrasing.
- Avoid bullet lists and passive voice in formal writing.
- Cite the specific line or section you are commenting on.

# Things to avoid
- Do not fabricate citations.
- Do not over-claim causality.
- Do not insert emoji or markdown decorations in formal docs.

Guides

The written versions of what the slides cover, kept current as the tools change.

Questions

Email claes.backman@gmail.com. I write about AI and research on Substack, and the resources page collects what other economists have written about working with these tools.