Claude Code + Overleaf: a careful manuscript workflow

For researchers working in English. Documentation checked: 28 October 2026. This handout follows the optional slides CT1–CT8. Replace example paths, filenames, remotes, and branch names with the actual values in your project.

1. Choose how to move the manuscript

Source ZIP: use when Git integration is unavailable or unfamiliar

1. In the Overleaf editor, choose File → Download as source (.zip).
2. Extract the ZIP into a new, clearly named local folder. Do not unpack it over another working copy.
3. Open that folder in VS Code and work on the copy.
4. To return the edited project, create a ZIP containing the project files and choose New Project → Upload Project in Overleaf. This creates a new project, leaving the source Overleaf project separate.
5. Recompile in the new project and inspect its PDF and logs.

The downloaded source ZIP does not contain the compiled PDF. Download the PDF separately if you need an original-versus-edited comparison.

Git: use when the project has Overleaf Git access

Overleaf Git integration is a premium feature on Overleaf Cloud and is also available on Overleaf Server Pro. Get the project’s Git URL from the Overleaf project menu. New clones currently use the single remote branch main; older clones may still use master. Overleaf’s direct Git integration supports one linear history and one remote branch, so it does not behave like a normal GitHub repository with remote feature branches. Confirm the branch shown by your clone before pulling or pushing.

The Overleaf Git integration page shows the clone pattern:

git clone <Overleaf-Git-URL> paper
cd paper

Use the project’s own Git URL from Overleaf, not a sample URL.

Before editing, confirm which project copy and remote you opened, whether there are uncommitted changes, and which branch the lab expects you to update. The next section gives a clean-clone sequence. Do not pull into a checkout with uncommitted changes. Keep edits reviewable and do not use a force push. If Git reports a rejected push or conflict, stop, synchronize with the latest project, resolve the conflict, inspect the resulting diff, compile, and review again before retrying.

2. Install and open Claude Code

VS Code extension

1. Use VS Code 1.94.0 or later.
2. Open Extensions with Cmd+Shift+X on macOS or Ctrl+Shift+X on Windows/Linux.
3. Search for Claude Code and install the extension.
4. Open the manuscript folder as your workspace, open the Claude Code panel, and sign in when prompted.

Terminal CLI

Use the installer for your shell. Anthropic’s current native install commands include:

# macOS, Linux, or WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

:: Windows CMD
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Use the command for the shell you are actually running. Open a new terminal after installation and confirm the CLI is available:

claude --version

Move to the manuscript folder, then start Claude Code:

cd /path/to/paper
claude

On Windows, replace the path with the manuscript’s Windows path, for example C:\Users\you\paper. Sign in on first use. Claude Code supports Claude subscriptions, Claude Console accounts, and documented enterprise provider setups; use the route approved by your institution.

3. Initialize project context with /init

The CLI and slash commands run in different places:

Run /init only after the Claude Code prompt is open. Do not use claude init; the documented workflow is to start with claude, then type /init in the session. Read the generated CLAUDE.md and fix any guessed project details. If a project CLAUDE.md already exists, /init suggests improvements rather than overwriting it.

4. Keep CLAUDE.md concise and specific

Create or refine a project-level CLAUDE.md in the root of the manuscript repository. Replace the example names below with the actual files:

# Manuscript workflow

- Main document: main.tex
- Bibliography database: refs.bib
- Compile using the project's existing compiler and build configuration.
- Preserve scientific claims, equations, numerical values, units, and citation keys.
- Never invent data, results, references, or explanations of methods.
- Edit only the section or paragraph named in the task.
- Do not edit .bib records, figures, raw data, or generated build files unless asked.
- Show a diff and report the compile result after edits.
- Ask before restructuring sections or changing scientific interpretation.

Project CLAUDE.md files are loaded as context at session start. They are useful for stable conventions, build instructions, and boundaries. They are not a hard permission system. Keep them short and review the generated content before committing it to a shared project.

5. Create one local skill for a repeated task

For a reusable paragraph-editing workflow, create this project file:

Path: .claude/skills/revise-paragraph/SKILL.md

---
name: revise-paragraph
description: Revise one selected manuscript paragraph for clarity while preserving its scientific meaning.
---

# Revise one paragraph

1. Work only on the paragraph the user names.
2. Preserve every claim, number, unit, equation, and citation key.
3. Add no sources, data, or scientific interpretation.
4. Show the proposed diff and wait for approval before applying it.
5. Report any ambiguity instead of guessing.

Then, inside Claude Code, run /reload-skills to rescan, followed by /skills to confirm the skill is available. Invoke it with /revise-paragraph and name the target paragraph. Claude Code discovers project skills in .claude/skills/; the example is a local skill and does not require a marketplace.

For external discovery, the existing AX12 slide links skills.sh. Treat its listings as third-party candidates, not Anthropic product guidance. Before adopting any external skill, inspect its SKILL.md, scripts, dependencies, author, and license; test it on a small example. This handout does not install a third-party skill.

6. Make the first task deliberately small

Copy and adjust this prompt:

Revise only the Results paragraph in sections/results.tex. Read the relevant figure caption and existing citation in the project, but do not modify those files. Improve clarity without changing any scientific claim, number, unit, equation, or citation key. Add no sources or data. Show a diff and wait for my approval before applying the edit. If the paragraph cannot be checked against the cited evidence already in the project, tell me what is missing.

Use a real path and a specific paragraph. A small request makes it easier to compare the source and the suggestion. The researcher remains responsible for interpreting the evidence and approving any scientific wording.

7. Review the edit, citations, and build

1. In the running Claude Code session, run /diff. In VS Code, inspect the changed files and the exact lines edited.
2. Check equations, numerical values, signs, units, methods, figure references, and citation keys against the source material.
3. If a local TeX installation is configured for the project and its main file is main.tex, Overleaf’s LaTeX guidance gives this build command:

sh latexmk -pdf main.tex

Replace main.tex with the actual root document. If you do not have a matching local TeX setup, use Recompile in Overleaf instead. 4. Read the build log and inspect the rendered PDF. Confirm that in-text citations resolve and the references list is present and formatted as expected. Overleaf uses latexmk to run the additional passes required for citations and cross-references, but unresolved-citation warnings still need attention. 5. A successful compile checks typesetting; it does not establish that the claims or interpretation are scientifically correct.

8. Return the reviewed copy safely

ZIP route: create a new Overleaf project

1. Put the reviewed source files in a ZIP, retaining the project’s folder structure.
2. In Overleaf’s project dashboard, choose New Project → Upload Project and select the ZIP.
3. In the newly created project, select the right main document/compiler if needed, click Recompile, and inspect the PDF.
4. Keep the original project as the comparison/recovery point. The uploaded ZIP creates a new project rather than replacing the source project.

Git route: clean clone, review branch, commit, sync, push

The example below uses the direct Overleaf Git integration. Get its Git URL in Overleaf first. New clones use main; older clones may still use master. Confirm the name shown by your project before copying the commands. If you clone directly from Overleaf, use the remote name assigned by Git in place of <remote> below.

If you already have a local checkout, inspect it first:

git status --short --branch

If it shows edits you have not intentionally committed, stop. Do not pull into that checkout. Preserve it and use a separate clean clone or deliberately resolve its changes first. If the folder name paper already exists, choose a different clone destination; do not overwrite it.

Clone to a separate folder and check its state:

git clone <Overleaf-Git-URL> paper
cd paper
git status --short --branch

For a new clone, sync the confirmed main branch and create a local review branch before editing:

git switch main
git pull <remote> main
git switch -c paper-review

For an older clone whose Overleaf branch is master, replace main with master in each command. Confirm that git status --short --branch shows the expected branch and no unexpected edits before proceeding.

Edit only the intended manuscript file. Review the source diff, compile, then stage and inspect only named files—never stage the entire folder for this task:

git diff -- sections/results.tex
latexmk -pdf main.tex
git add -- sections/results.tex
git diff --cached -- sections/results.tex
git commit -m "Revise Results paragraph"
git status --short --branch

Replace sections/results.tex and main.tex with the real paths. If the status after the commit shows any uncommitted or unexpected files, stop and inspect them; do not continue to synchronization while the working tree is dirty.

Before pushing, fetch the latest Overleaf branch, synchronize the local review branch with it, inspect the final change, and compile again:

git fetch <remote>
git rebase <remote>/main
git diff <remote>/main...paper-review
latexmk -pdf main.tex

On a legacy clone, replace main in the rebase and diff commands with master. If synchronization reports a conflict, stop and resolve it with a coauthor or Git support; then re-review the changed files and compile before pushing. If the remote advances after this fetch, the push should be rejected; do not force it—fetch, synchronize, review, and compile again.

Once the final diff and build are reviewed, push the local review branch to Overleaf’s single remote branch:

git push <remote> paper-review:main

For an older clone, use git push <remote> paper-review:master. This updates the Overleaf project, so coordinate with coauthors first. Overleaf warns that Git pushes can displace active Track Changes and comments; avoid mixing direct Git pushes with active annotations. For GitHub or another standard Git host, push to the repository’s approved review branch and follow its normal merge process instead. The direct Overleaf Git bridge does not create a remote feature branch.

Official documentation

All product-specific procedures above were checked against official Anthropic/Claude Code or Overleaf documentation on 28 October 2026. Source titles, exact URLs, and the claims they support are listed in claude-tutorial-sources.json.