Working with Claude Code

You’ve set up Git and made your first commit by hand. Claude Code is a tool that can do that kind of work for you — and much more. This section covers what it is, how it works, how to get it through Stanford, and what data you can and can’t give it.

Meet Claude Code

In Version Control with Git you worked through fork, clone, branch, commit, and push by hand. That was the point: you now know what each step means. From here on, you don’t have to type it yourself.

Claude Code is an AI assistant that lives in your terminal: you describe what you want in plain English, and it does the work — running commands, editing files, and handling git for you.

You just saw why keeping your work in GitHub is worth the trouble (see Version Control with Git) — and those are exactly the habits Claude Code can handle for you. You will not memorize the commands for any of it. You say “log this as an issue” or “try this on a branch,” and Claude Code does it — the right way — because it follows a skill we wrote for research.

Getting access. You don’t need a personal account. Stanford runs Claude for Education — a secure, university-managed environment — and it’s free for everyone at Stanford.

  • Why go through Stanford? Your work stays under Stanford’s data-governance terms. Claude Code is approved for use with Stanford data when terms and conditions allow it. Stanford’s GenAI tool matrix has the latest on data categories and approved tools. For research, it is always preferred to use your Stanford account.
  • How to get it. The Standard tier is free for all active faculty, students, postdocs, and staff with a SUNet ID. (A Premium tier is available if you have a PTA — a Stanford billing account your lab may hold.) Free still means you request it once, through ServiceNow (Stanford’s IT request website) — it’s a quick approval, not a purchase.

Full details and the request links live at uit.stanford.edu/service/claude. Your instructor can point you to the exact sign-up link in class.

How Claude Code Works

A few basics worth knowing before you start.

CAMPUS PERIMETER 💻 Your machine · the Yens You direct Claude — it reads what you allow, and acts as you. Your data ⚠️ Check before sharing Public data (e.g. SEC filings) Your own code & scripts Personal info (PII) Data under an NDA / license Health data (PHI) 🗨️ Your instructions what you ask it · your CLAUDE.md ⚙️ Claude Code the model harness you direct it reads acts as you results On your machine, as you: edit files · run commands drive git · call tools 🧠 Claude's model Anthropic's server reached via Stanford's governed route ① sends context ② its next step loops until done

The model and the harness — the brain and the hands. Claude is the LLM (large language model — the AI “brain” itself): it reads, reasons, and writes. On its own, it can only talk. Claude Code is the harness around that brain — it hands Claude real tools: read your files, run commands, edit code, use git. The model is the expert; the harness is the desk, the tools, and permission to act.

The models — and how to switch them

Claude comes as a family, trading speed for power:

Model Best for
Opus The most capable — deep reasoning, hard problems
Sonnet Balanced — great for everyday work
Haiku Fastest and lightest — quick, simple tasks

Switch anytime with the /model command. Default to a capable model; drop to a faster one when the task is small.

Permission modes — how much Claude does before asking

Claude Code always works with your permission — you choose how much it checks in before acting. Press Shift+Tab to cycle through the modes (the current one shows at the bottom of the screen, e.g. ⏸ plan mode on, ⏵⏵ accept edits on):

  • Manual (the default): Claude reads freely but asks before every edit and every command — nothing changes on your machine without your yes. Safest, and a good place to start.
  • Accept edits: Claude applies its file edits (and common file commands like creating folders) without asking each time, but still stops before running other commands. Good once you trust the direction and don’t want to approve every edit.
  • Plan: Claude investigates and writes up a plan but changes nothing — no edits, no commands that alter anything — until you approve. Perfect when you want to see the approach first.
  • Auto: Claude does everything on its own — editing files and running commands as it goes — with background safety checks that block the riskiest actions. Fastest, but least oversight: it reduces prompts, it doesn’t guarantee safety, so use it only when you trust the task.

Start in manual to stay in control; use plan mode when you want a proposal first; move to accept-edits or auto once you trust where it’s headed.

Tokens — how Claude reads, and what it costs

Claude doesn’t read letter by letter or word by word — it reads in tokens. A token is a chunk of text: very roughly ¾ of a word, or about 4 characters. “Repository” is a couple of tokens; a full page of prose is around 500.

Everything is counted this way — the text you send and the text Claude sends back. Tokens matter for two reasons: they are how much Claude can hold at once (see Context, next), and they are how paid AI services charge — a fixed price per token.

Type /cost any time to see how many tokens the current session has used.

Run out of usage and you wait — you can’t pay for more. Stanford gives you Claude on a managed plan with a usage limit, not the pay-per-token billing a personal account would have. When you use up your allowance, Claude Code pauses until your limit resets after a set time — there is no “just charge me for more tokens” button. To make your usage last: switch to a lighter model with /model (Haiku and Sonnet cost far less than Opus), keep each session to one focused task, and use /clear or /compact so you’re not re-sending a large context every turn.

Context — Claude’s working memory, and when to clear it

The context (or context window) is everything Claude can see right now: your conversation, any files it has read, and its own replies so far. It’s measured in tokens — large, but not infinite.

A long session slowly fills the window. When it’s full, or when the conversation has drifted far from the task at hand, the fix is to start fresh: /clear wipes the slate so the next question gets Claude’s full attention. /context shows how full the window currently is.

If you’re filling up but don’t want to lose the thread, /compact is the middle ground: it replaces the long back-and-forth with a short summary, freeing room while keeping what matters. Use /compact to keep going on the same task; use /clear when you’re moving on to a new one.

Rule of thumb: one focused task per conversation. A clean context beats a cluttered one every time.

Memory — the notebook Claude keeps

Context is erased the moment you /clear or close the terminal. Memory is what survives — and it comes in two forms:

  • A CLAUDE.md file in your project. A plain-text note you commit alongside your code, telling Claude how this project works — where the data lives, how to run things, conventions to follow. Every future session (yours or a collaborator’s) reads the same file, which makes your project easier to pick back up and to reproduce.
  • Personal memory across sessions — facts about you and how you like to work, remembered from one sitting to the next.

To save something to memory, just ask — tell Claude “remember that…” and it stores the note. Use the /memory command to review or edit what’s saved, or open CLAUDE.md directly. Because CLAUDE.md is just a file in your repo, it’s version-controlled like everything else you commit.

Skills — standing instructions for how your group works

A skill is a reusable set of instructions that Claude Code pulls in whenever it’s relevant — so it follows your group’s way of doing things without being told each time. If memory is a set of facts, a skill is a way of working.

Skills can come from Stanford, from your lab, or ones you write yourself. This course ships one — github-for-research — which you’ll install just below, and you’ll see exactly where it lands on disk.

Data Governance and Security

Before you point Claude Code at real work, keep two things straight: what data leaves your machine, and the fact that it acts with your full access.

What leaves your machine — and what must not

As the diagram above shows, the harness stays on your machine, but the model runs on Anthropic’s server — so everything the harness sends the model leaves your machine and travels to that server.

Claude Code does not sort safe data from sensitive. It sends whatever you let it read — if you point it at a file full of names, those names go to the server. Nothing keeps personal, restricted, or health data local on its own. Holding that data back is your job — by not letting Claude read it in the first place.

Deciding what Claude Code may read is your responsibility. Public data and your own code are fine; personal (PII), NDA/licensed, or health (PHI) data must not be sent — and the tool won’t hold them back for you. What’s approved depends on the data and the tool: see Responsible AI at Stanford for which AI tools are cleared for which data-risk levels, and the GSB Library’s eResources usage policy for whether a licensed dataset may be used this way. We map out these data categories in full on Day 2.

Claude Code acts as you

When Claude Code runs a command, edits a file, or pushes to GitHub, it does so with your credentials and your permissions. To the Yens, to GitHub, to anything it touches, the action looks exactly like you did it — there is no way for those systems to tell you apart from Claude acting on your behalf.

That has a blunt consequence: Claude Code can do anything you can do. It can read, change, or delete any file you can, run any command you could run, and reach any system your account can reach. You can ask it to steer clear of something — “don’t touch the data/ folder,” “never force-push” — and it will try, but that’s a request, not a boundary the system enforces. Nothing outside your own judgment stops it.

Treat it like handing your keyboard to a fast, capable assistant. Use plan mode when you want to see the plan before anything happens, review actions that are hard to undo (deleting files, force-pushing, sending data off your machine), and don’t point it at anything you wouldn’t do yourself.

Take It for a Spin

Do this now. On the Yens, load Claude Code, sign in through Stanford, and give it a first real task. This is the one Claude Code step everyone should complete.

You’ve been working on the Yens all along — Claude Code runs there too. Connect the way you did in Connecting to a Cluster if you’re not already on:

ssh SUNetID@yen.stanford.edu

1 — Load Claude Code. It’s available as a module on the Yens, just like gh and python:

ml claude-code

Already have Claude Code on the Yens? Some people arrive with their own install, or signed in with a personal (non-Stanford) account. Run which claude — if it points somewhere other than the module, grab an instructor rather than untangling it yourself. We’ll get you switched over to the module and your Stanford login, so your usage runs under Stanford’s terms.

2 — Make a working folder and launch it from there. Create a cctest directory in your home directory, move into it, and start Claude Code:

mkdir -p ~/cctest
cd ~/cctest
claude

3 — Sign in with your SUNet ID the first time (see Meet Claude Code above).

4 — Learn two controls. Try each once:

  • Type /cost — see how many tokens this session has used (the Tokens box explains why this matters).
  • Press Shift+Tab — cycle through the permission modes: manual, accept edits, plan, and auto (see Permission modes above).

5 — Give it a real task. No need to download anything yourself — just point Claude at the grimoire on GitHub and say what you want:

> Download and unzip the grimoire from https://raw.githubusercontent.com/gsbdarc/gsb-research-computing-ai-skills/main/docs/assets/data/grimoire.zip and tell me, for each element, the longest spell name(s).

Claude fetches the archive, unzips it, reads the filenames, and reports one spell per element. Notice what you didn’t do: no curl, no unzip, no wildcards or pipes — you said what you wanted, and it worked out how. That’s the shift Claude Code represents.

6 — Quit, and move to your project. Leave Claude Code by typing /exit (or pressing Ctrl+D). The next section sets things up inside your course repo, so move there now:

cd ~/gsb-research-computing-ai-skills

🟢 Green sticky = I’m done and ready    🔴 Red sticky = I need help

Put a sticky note on your laptop lid so instructors can see where you are.

The github-for-research Skill

You just met skills in the abstract; here’s the one this course ships. github-for-research teaches Claude Code some opinionated, but informed, best practices about how to use GitHub as part of a research project at the GSB:

  • Do new work on a branch, never straight on main.
  • Log problems as issues — even ones you fix immediately.
  • Never quietly change raw data; always validate processed data.
  • Credit Claude on every commit, and keep the environment reproducible.

Install it like this:

bash scripts/install_github_for_research_skill.sh

This is a one-time setup. Not sure if it’s already installed? Just ask Claude Code — > do you have the github-for-research skill? — or run the command again; it’s safe to re-run. The skill’s home is gsbdarc/claude-skill-github-for-research.

See it for yourself — Claude lives in hidden files. Look at the last thing the installer printed:

Skill installed at: /home/users/SUNetID/.claude/skills/github-for-research

That .claude is a dotfile — the hidden names from Command Line Basics, the ones a plain ls won’t show you. It’s where Claude Code keeps its settings, skills, and memory. Go and look:

ls -a ~
ls ~/.claude
ls ~/.claude/skills

The first reveals the hidden .claude folder among the other dotfiles; the second shows settings, skills, and memory; the third shows the skill you just installed, sitting there as an ordinary folder. Open one up — cat ~/.claude/skills/github-for-research/SKILL.md is the very text Claude will follow. Nothing here is magic: it’s plain text in hidden files, readable and editable like anything else you’ve touched today.

🟢 Green sticky = I’m done and ready    🔴 Red sticky = I need help

Put a sticky note on your laptop lid so instructors can see where you are.

Optional practice — investigate a well-kept repo

A repository that follows these practices is one you can actually understand — by hand or with Claude Code. Try both on a real Stanford project: an analysis of whether San Francisco’s graffiti 311 reports fell during COVID.

Show steps

By hand. Open gsbdarc/sf311 on GitHub and try to answer, just by clicking around:

  • What research question does this project answer? (Start with the README.)
  • How was the raw data cleaned, and where is that checked?
  • What’s left to do? (Check the Issues tab and the commit history.)

Notice how much you can piece together because the repo is organized and documented — and how long it takes.

With Claude Code. Now let Claude do the reading. This is someone else’s project, not your coursework, so clone it into the scratch folder you made earlier rather than dropping it into your course repo:

cd ~/cctest
git clone https://github.com/gsbdarc/sf311.git
cd sf311
claude

Now ask the same things in plain English — and notice the first sentence:

> Use the github-for-research skill. What research question does this project answer? How was the raw 311 data cleaned and where is that checked? Walk me through reproducing the main finding, and list anything left to do.

Name the skill. A skill isn’t guaranteed to kick in on its own — Claude decides whether it looks relevant, and often it just answers the question without it. Saying “Use the github-for-research skill” removes the guesswork. Get in the habit: when you want the research practices applied, ask for them by name. You’ll do it again in the next exercise.

Claude reads the README, the scripts, and the issue history and answers in seconds — but only because someone kept the repo the way this skill describes. Good practice is what makes a project answerable, by a person or by Claude.

Quit Claude Code with /exit when you’re done reading.

Casting from somewhere else. You’re in ~/cctest/sf311 right now, not your fork — so a bare ./cast won’t find your repo. Two ways round it: go back with cd ~/gsb-research-computing-ai-skills and run ./cast <spell> as usual, or cast from wherever you are using the full path:

~/gsb-research-computing-ai-skills/cast <spell>

cast works out your repo from its own location, so the full path works from any folder. That even lets you cast without leaving Claude Code — type ! to drop into shell mode and run it right there:

! ~/gsb-research-computing-ai-skills/cast <spell>

Optional Practice — Put Claude Code to Work

Optional practice: Have Claude Code make a real change to your course site — switch it to dark mode — and open a pull request. A bonus walks the same change the way a pro would: inspect, plan, then act.

Optional — the Day 1 Challenge only needs the exercise from Version Control with Git. This is extra practice.

Make a real change: dark mode

Now let Claude Code do real work on your own site. First go back to your course repo — if you did the sf311 practice above, you’re still sitting in someone else’s project:

cd ~/gsb-research-computing-ai-skills
claude

Press Shift+Tab until you’re in auto mode — so Claude can run the whole task end to end without stopping to ask at every edit and git step. Then give it a concrete, checkable task — switch the site to dark mode and drive the whole git loop for you:

> Use the github-for-research skill. Switch this site's theme to dark mode, commit it on a new branch, and open a pull request. You don't have to be thorough, it's a proof of concept.

Two things in that prompt are doing real work:

  • “Use the github-for-research skill” — the same habit as the last exercise. Without it Claude will happily commit straight to main and skip the branch and PR entirely.
  • “You don’t have to be thorough, it’s a proof of concept” — left to itself, Claude will go hunting for every colour on the site and spend five minutes doing it. The theme really is one line in docs/_config.yml, and this tells Claude that flipping it is enough. Scoping a task like this is one of the most useful things you can say to an AI assistant.

Then confirm it worked: on your fork on GitHub, a new branch and a pull request should have appeared with the theme change.

Look at what it did: the work went on a branch, opened as a pull request, and the commit credits Claude — the good habits happened automatically, because you asked for the github-for-research skill.

See your change. When Claude opens the PR it prints a link — follow it and open the Files changed tab. That alone confirms Claude made the edit correctly, and reviewing the diff is the review.

To watch it render live, the change has to reach your fork’s main — GitHub Pages publishes one site per repo, so there’s no separate preview for a branch. Merge the PR whichever way you like:

  • In the browser — open the PR and click Merge pull request, then Confirm merge.
  • In the terminal — from your repo, gh pr merge --merge (you already signed gh in on the Yens).
  • Ask Claude — > merge that pull request.

Any of the three lands the change on main, which triggers the Deploy Jekyll site to Pages workflow you enabled in Version Control with Git. Watch it run on your fork’s Actions tab; a minute or two later, dark mode appears at your site URL:

https://YOUR-USERNAME.github.io/gsb-research-computing-ai-skills/

On your personal fork, turning the whole site dark is harmless — and if you decide you hate it, the fix is one more sentence to Claude.

Bonus — Do it like a pro (plan mode + issues)

The task above flipped the whole site to dark in one line. Here’s a more ambitious change, handled carefully — add a toggle so readers can switch between light and dark themselves. Because it’s bigger, you look before you leap and review a plan before any file changes. (Do this on a fresh branch.)

  1. Inspect the repo. In claude, ask how the site is themed: 
    > How is this site's theme and colours set up, and which files control them?
  2. Review what’s open. Have Claude survey the project’s issue tracker: 
    > Summarise the open issues in this project.
  3. Plan before acting. Press Shift+Tab to enter plan mode, then ask: 
    > Propose a plan to add a dark-mode toggle to the site — a control readers can click to switch between light and dark that remembers their choice.

    Claude investigates and shows a plan without changing anything. Read it; refine it if you want.

  4. Approve, implement, and open a PR. Approve the plan, let Claude make the changes, and have it open a pull request.

This is the everyday Claude Code loop for anything non-trivial: look → plan → approve → act. Plan mode is your safety net — you see exactly what it intends before a single file changes.

What You Learned

  • How Claude Code works — model vs. harness, models, modes, tokens, context, memory, skills
  • What a token is, and why context and cost are both measured in tokens
  • What leaves your machine on an AI call — and why sensitive data can’t go to an external LLM
  • How to get Claude through Stanford’s managed service
  • Install Claude Code and run your first task on real data — in plain English, no commands to memorize
  • Have Claude Code make a real change (dark mode) and open a pull request — using plan mode to review before it acts
  • Interrogate a real research repo with Claude Code
This site uses Just the Docs, a documentation theme for Jekyll.