Claude研究工具

Part I: Getting started

New to Claude Code? Start here. By the end of this part you will have a working installation and a fully configured research project — most of it set up by Claude itself. Experienced users can skip ahead to Part II.

Installation and first launch

This section is for readers who have never used VS Code or Claude Code before. If you are already set up, skip to Bootstrapping a new project with Claude.

Step 2 — Install the Claude Code extension

1. In VS Code, click the Extensions icon on the left sidebar (it looks like four squares, one slightly detached). 2. In the search box that appears, type Claude Code. 3. The first result should be "Claude Code" by Anthropic. Click Install. 4. After installation, a Claude icon appears in the left sidebar.

Alternatively, you can install Claude Code as a command-line tool and use it from any terminal without VS Code:

npm install -g @anthropic-ai/claude-code

This requires Node.js to be installed. The VS Code extension is easier if you are not familiar with the terminal.

---

How to read this guide

This guide serves two audiences at once, so it is organised in parts:

- Never used Claude Code? Read Part I from the top. It takes you from nothing to a fully configured project — including a step where Claude does the setup for you. Then read Part II gradually, as the topics become relevant to your work. You do not need anything in Part III to be productive. - Already using Claude Code? Skip Part I (except perhaps Bootstrapping, which is useful for any new project) and start with Part II — the workflow patterns there are the heart of this guide. Add the machinery in Part III when you want it. - Everyone, whatever your experience level: read Honest limitations before trusting anything Claude produces. The failure modes described there are not edge cases.

---

Quick-start flowcharts

Visual overviews of the two key workflows. Scan these before reading the full guide.

Green = start/end · Blue = action · Gold = decision · Red label = no path · Green label = yes path

---

Part II: The core workflow

The heart of the guide: how to organise a long research project so that every Claude session is productive. This part is for everyone — but you do not need to read it all on day one. Start working, and come back to each topic as it becomes relevant.

Step 1 — Install VS Code

VS Code is a free text editor made by Microsoft. Claude Code runs inside it as an extension. You can also run Claude Code in a standalone terminal, but VS Code gives you a much better experience: you see the files Claude is editing, the terminal where it runs, and the chat window all in one place.

1. Go to https://code.visualstudio.com and click the download button for your operating system. 2. Run the installer. On macOS, drag VS Code into your Applications folder. On Windows, the installer does everything for you. 3. Open VS Code. You will see a welcome screen. You can close it.

That is all. You do not need to configure anything in VS Code before continuing.

---

Alternative: scripted setup

If you prefer answering questions over pasting a prompt, scripts/bootstrap.sh does the same setup deterministically. Run it from your new project folder:

curl -fsSL https://raw.githubusercontent.com/Mexregkan/claude-for-researchers/main/scripts/bootstrap.sh | sh

It asks for the project title, author, numerics engine, and whether you cite literature, want the validation skills, or pair with a shared Overleaf project. It then installs the universal core — CLAUDE.md, the workbook / brief / next-session-prompts trio with your title and author already filled in, and BUGS.md — and only the skills your answers make relevant, skipping any skill already in your global ~/.claude/skills/. It never overwrites an existing file, creates the generated/ staging folders when you run numerics, and offers git init.

The script handles structure; it cannot write your introduction or conventions. It finishes by printing the short prompt to paste into your first Claude session, which fills the remaining bracketed stubs from your project description. Both routes end in the same place — with the prompt, Claude makes the relevance decisions from your description; with the script, you make them by answering questions.

If you have existing Mathematica notebooks or scripts, run /nb-to-wolfbook on them after setup is complete. Point it at a file or a whole directory and it will convert everything to Wolfbook's .wb format in one step — re-run the cells afterwards to regenerate output.

Why the install commands may prompt (once). The settings.json Claude just wrote asks before anything dangerous (rm, mv, git reset --hard, …) and blocks edits to files you mark as irreplaceable, so you stay in control without ever being stuck. Claude Code reads settings.json once, at session start, so it does not take effect until your next session — which is why these install commands can ask for permission in this very first session. Approve them. How much you are prompted from here on depends on your permission mode: in auto mode, the default since August 2026, routine commands run without prompting and a classifier vets them instead; in Manual mode you approve each one.

This works because Claude Code can read a GitHub repository, run shell commands, and write files, and because the guide it is reading contains explicit templates and instructions. Filling those templates with your project — turning a description into a working CLAUDE.md, workbook.tex, and brief.tex — is exactly the kind of structured work Claude does reliably. The research that follows is yours.

---

Status vs. changelog: keep the always-loaded file lean

CLAUDE.md is re-read at the start of every session, so every line in it is a recurring cost — and on a long project the "Current status" section is where bloat creeps in. Each finished result is tempting to leave in place as a paragraph with its scripts, its data files, its little proof sketch. Do that for a few months and the status section becomes a dated log of everything you have ever done: dozens of screenfuls that bury the actual instructions and cost tokens every session.

That dated log is worth keeping — but it is a changelog, not a status. Split them:

- CLAUDE.md → "Current status" is a snapshot: for each branch, the headline DONE results and the current OPEN frontier. A handful of lines per branch, no dates. - The dated log — the full "what landed when, with which script and which data file" — lives in the durable history file: the DONE log in next-session-prompts.md for most projects, or a dedicated CHANGELOG.md at the project root once that history gets long.

Rule of thumb: if a status line has a date in it, it belongs in the dated log, not in CLAUDE.md. Condensing a status section that has grown to dozens of paragraphs down to a per-branch snapshot can cut the always-loaded status content by an order of magnitude while losing nothing — the detail just moves to where it is read on demand instead of every session.

A snapshot template for a multi-branch project:

```markdown