Module 1 Lab: Install, Project Setup, One Verified Task

Download the starter pack (zip) Module 1 slides (PDF) Module 1 notes

In this lab you install Claude Code, authenticate it, and set it up for a real project. Then you run one small, reproducible task through it from start to finish, with a verification step you do yourself. Nothing here touches WRDS or any licensed dataset. Everything uses public SEC data, so there are no credentials to protect and no account approval to wait for. Download the starter pack (lab1_starter.zip) before you begin. It contains a CLAUDE.md.template, a verify_checklist.md, and a prompts_tried.md log.

What you’re building in this module

By the end of the lab you will have three things. First, a Claude Code install that launches from a fresh terminal. Second, a project folder (~/lab1/) with a CLAUDE.md that loads correctly. Third, one small pipeline (a script, its output, and one number you checked by hand) that a labmate could rerun and get the same result.

Part A: Environment (25 min)

Install Claude Code and confirm it authenticates against your Pro, Max, or API-key account, following the steps on the Setup page. Then create a new, empty directory with mkdir ~/lab1 && cd ~/lab1 and launch claude from inside it. Start from an empty folder so that the only files Claude sees are your project’s, not a Downloads folder full of files from another course or another paper. You will start from an empty folder in every module for the rest of the course.

Ask Claude a simple question about the (empty) directory and check that it actually inspects the filesystem instead of guessing. If claude doesn’t launch, or launches but can’t find a local Python or R install to run scripts with, the cause is very likely your PATH or WSL configuration, not Claude Code itself. Flag it early.

Pair debugging is encouraged for this part. If you’re stuck for more than 20 minutes, stop troubleshooting alone and pair up with a neighbor whose install already works. Note the issue on your exit ticket so the instructor can follow up. The instructor and TA will be circulating to help with Windows/WSL installs, which cause the most Module 1 problems.

Part B: CLAUDE.md (15 min)

Open CLAUDE.md.template from the starter pack, save it as CLAUDE.md in ~/lab1/, and fill in the three TODOs. The first is a language preference (Python or R, whichever you’ll actually use in this course). The second is one style convention for output, such as a figure style, a naming pattern, or a units convention. The third is one verification rule, a check you want Claude to run automatically, such as printing a row count before and after any filtering step. Keep it short. CLAUDE.md is read into the context window at the start of every session, so a full-page file uses up the space it is meant to save.

Once it’s saved, close the session and start a new one in the same folder. Ask Claude what it knows about your project’s conventions, and confirm the answer matches what you wrote. If it doesn’t, check three things: the file is named exactly CLAUDE.md, it sits at the project root, and you actually restarted instead of continuing the old session. CLAUDE.md loads at session start, not mid-conversation.

Part C: One verified task (40 min)

Choose one of the three tiers below. All three use the same public dataset, the SEC’s Financial Statement Data Sets (FSDS). FSDS is a free quarterly bulk file of filing metadata and tagged financial values, and it needs no credentials. None of the tiers touch WRDS.

Base. Download one quarter of FSDS, extract sub.txt (the filing metadata file), and count filings by form type (10-K, 10-Q, 8-K, and so on). Save the counts as form_counts.csv, produced by a named script, not pasted from a chat reply. For example, ask for count_forms.py by name so the file exists on disk and can be rerun.

Standard. Do everything in Base, plus a bar figure of the top ten form types by count, with both axes labeled, saved as form_counts.png.

Stretch. Do everything in Standard, plus one deliberate Esc redirect. Let Claude start down a wrong path on purpose (for instance, ask it to also parse every available quarter, then interrupt before it finishes). Press Esc, restate the actual scope, and log the vague-to-specific rewrite in prompts_tried.md.

Whichever tier you choose, the deliverable is a named script, not an answer in the chat. If Claude reports a number in the conversation without writing the script that produced it, ask it to write the script. A number that exists only in a chat transcript is lost when the transcript is. A script can be rerun by you, a labmate, or you again next week. Whatever your tier, log at least one prompt you rewrote from vague to specific in prompts_tried.md, with both versions.

Verify this: your full checklist

Complete every line below before you consider the lab done. The checklist is self-graded and pass/fail. The instructor will spot-check a sample, not grade every box.

claude launches in a fresh terminal, and CLAUDE.md loads in a new session (you asked, and the answer matched what you wrote)
The task ran from a named script (e.g., count_forms.py), not from output pasted into the chat
At least one output number is checked against a source Claude did not touch. Write down what you checked and where. One reasonable check: compare your 10-K count for the quarter with SEC EDGAR’s own filing search, filtered to the same form type and date range.
prompts_tried.md contains at least one real vague-to-specific prompt rewrite from your own session (not copied from the module page)
No credentials of any kind appear anywhere in ~/lab1/. This lab uses only public data, so this box should be easy to tick. Check it anyway, to build the habit.

Debrief and exit ticket (2:45–3:05)

We come back together for a short debrief. Be ready to answer, informally: What broke during your install or your task, and how did you find out? Did you type corrections and argue with Claude when you should have pressed Esc and redirected? If so, what would you do differently next time? By show of hands: whose first prompt turned out vaguer than they thought once they saw the output?

Complete the standard three-question exit ticket (one concept that clicked, one thing that broke, one thing you’d want to verify before trusting a similar result), plus this module’s item:

Homework: confirm your WRDS/Duo runway now

Confirm that you have an active WRDS account and that Duo two-factor authentication is enrolled on it. Set up the ssh wrds shortcut (Setup, step 5) and test that it connects and completes a Duo push. Aim to do this before Module 2. The hard deadline is the checkpoint at the end of Module 2’s lab, and Module 4’s main lab depends on this connection. Allow at least two days to resolve account or Duo problems through WRDS support; the night before Module 4 is too late. If you run into trouble, raise it at Module 2’s checkpoint, not after.