learn-claude-with-phoebe / Session 5 of 6
Learn Claude with Phoebe · Session 5 of 6

Data work with Claude Code

The terminal agent for the DS & AI team: clean messy data with a plan you approve, generate a living data catalog, write offline-safe Python for AWS WorkSpaces, and stand up a working data product prototype.

🟠 Hard DS & AI Analysts welcome 45 min live + self-study
0-3 · Welcome 3-18 · Concepts 18-40 · Terminal time 40-45 · Q&A
Part 0

Why this session exists

Chat Claude answers questions about your data. Claude Code WORKS on it: reads the files, writes and runs the scripts, checks outputs, commits results - in your terminal, inside your repo, under permission rules you control. Prerequisites: comfortable with a terminal and basic git.

Live - presented in session Self-study - read after class ★ Build-along demo 2 official courses covered
★ What you walk out with today Claude Code installed with a CLAUDE.md, a messy CSV cleaned + profiled + catalogued via the explore-plan-code loop, and the offline-Python constraints template for AWS WorkSpaces with no internet.
Part 1 · covers "claude code 101"

What Claude Code is and how it works 6 min live

An agent in your terminal: Claude plus tools (read/write files, run commands, search, git) in a loop, pointed at your working directory, gated by permissions you control.

You, in the terminal The agent loop think → pick a tool → act → read result → repeat until done, reporting as it goes Tools, behind YOUR permission gate 📄 read / edit files in the project ▶ run commands (pytest, python, sql) 🔎 search the codebase 🌿 git: diff, commit, PR 🔌 MCP servers (Session 6) Risky actions ask first - you set the rules CLAUDE.md = the project's standing brief: stack, conventions, commands, guardrails. Read automatically every session.
🔍 Click to zoom - Claude Code: an agent loop with tools, gated by your permissions
LiveSetup in three commands + your first prompt2 min▶
★ Install and launchnpm install -g @anthropic-ai/claude-code cd ~/work/my-data-project claude # first prompt - just talk: > look around this project and tell me what it does, what's messy, and what you'd tackle first

Talk to it like a capable new teammate, let it explore before you ask for changes, and treat permission prompts as a feature: saying "no" teaches it your boundaries.

What CLAUDE.md adds over a bare Claude Code session Stack Commands Conventions Guardrails CLAUDE.md the standing brief, read automatically at session start PLAIN CLAUDE CODE capable teammate who doesn't know your repo yet = YOUR tool not a generic one Run /init and Claude drafts one; you correct it, the usual discernment lap.
🔍 Click to zoom - CLAUDE.md turns a generic agent into your repo's own tool
LiveCLAUDE.md - the file that makes it YOUR tool2 min▶

A markdown file at the project root, read automatically at session start - the repo's standing brief:

★ CLAUDE.md starter for a data repo# Project: [name] ## Stack Python 3.11, pandas + polars, duckdb for local SQL, pytest. Env: `conda activate proj`. ## Commands - tests: `pytest -q` · lint: `ruff check .` - data/raw is NEVER edited; outputs go to data/processed ## Conventions - every analysis reproducible: seeds set, no hardcoded paths - notebooks are scratch; kept work moves to src/ as documented scripts - all cleaning steps logged to data/processed/CHANGELOG.md ## Guardrails - warehouse and data/raw are read-only - PII columns (email, phone, address): flag, never print samples

Run /init in any existing repo and Claude drafts the CLAUDE.md for you - then you correct it (the usual loop).

LiveThe working method: explore → plan → code → commit2 min▶
  • Explore: "read the loading and cleaning code, summarize how X flows" - cheap reconnaissance first.
  • Plan: ask for a plan and APPROVE it before code changes (plan mode). For data work this is non-negotiable: you're approving what happens to the data.
  • Code: it writes, runs, hits errors, fixes - the loop you'd do by hand, at machine speed, visible.
  • Commit: reviewed diff, clean message. Ask it to review its own diff first: "anything risky in this change?"
  • Context management: long sessions drift (Session 1's working-memory lesson). Use /clear between unrelated tasks; keep CLAUDE.md lean so every session starts sharp.
Self-studyPower features: custom commands, hooks, GitHub, SDK3 min read▶
  • Custom slash commands: save a repeated prompt as .claude/commands/profile-data.md → run /profile-data. Your team's SOPs as commands (Session 3's idea, terminal edition).
  • Hooks: shell commands that fire automatically on events - auto-run ruff after every edit, block writes to data/raw/, notify on session end. Deterministic guardrails around the agent. Gotcha: hooks run with YOUR permissions - keep them read-only where possible.
  • GitHub integration: Claude reviews PRs, fixes issues from comments, drafts release notes - gh CLI plus the GitHub app.
  • Skills & subagents in Code: your Session 3 skills work here (.claude/skills/); subagents are Session 6.
  • The SDK: the same agent, scriptable from Python/TS - build your own data tools on top. That's the bridge to Session 6's platform story.
Part 2 · the four data workflows

Cleaning, catalog, offline scripts, prototypes 9 min live

The four jobs this team asked for, each as a repeatable pattern with its prompt.

LiveWorkflow 1 · Data cleaning with an approved plan2 min▶
★ The cleaning brief (Demo 1 runs this)Here's data/raw/sales_export.csv - it's messy. Work in explore-plan-code order: 1. EXPLORE: profile it first - shape, dtypes, nulls, duplicates, outliers, encoding issues, suspicious values. Report before touching anything. 2. PLAN: propose the cleaning steps as a numbered list with the WHY per step and what could go wrong. Wait for my approval. 3. CODE: implement as src/clean_sales.py - reproducible (seeded, no hardcoded paths), logging each step's row counts to data/processed/CHANGELOG.md. Never modify data/raw. 4. VERIFY: rerun the profile on the cleaned output, show before/after, and write 3 assertions to pytest so regressions get caught.

The pattern generalizes: profile → approved plan → logged script → verified output. The CHANGELOG plus assertions are what make it governance-grade instead of notebook archaeology.

LiveWorkflow 2 · A data catalog that writes itself2 min▶
★ The catalog generatorBuild a lightweight data catalog for this project as docs/catalog/: For every dataset in data/processed (and the warehouse tables listed in CLAUDE.md): - one markdown page: purpose, owner (from git blame if unclear, flag it), refresh cadence, schema table (column, type, description, % null, example - MASK anything that looks like PII), lineage (which script produces it, which raw sources feed it), known quality issues. - an index page grouping by domain, with a one-line description each. Infer descriptions from column names + the code that creates them; mark every inference with (inferred) so humans know what to verify. Regenerate idempotently - I'll re-run this weekly.

Not a DataHub replacement - a living, in-repo catalog that costs one command to refresh. For most teams it beats the enterprise tool nobody updates. When you outgrow it, the markdown migrates cleanly.

LiveWorkflow 3 · Offline Python for AWS WorkSpaces3 min · the house specialty▶

Our reality: analysis code gets copy-pasted into AWS WorkSpaces with no internet and no pip. Scripts that import freely die on arrival. The fix is a constraints preamble that makes Claude write for that runtime every time - keep it as a skill or slash command:

★ The offline constraints template (Demo 2 runs this)Write this as a SINGLE self-contained Python script for a locked-down environment: HARD CONSTRAINTS - the runtime has: - No internet. No pip. Nothing beyond: Python 3.10 standard library + pandas + numpy + openpyxl [ADJUST to your WorkSpace's verified list] - No environment variables, no config files - all parameters in an UPPERCASE constants block at the top - Input/output paths as constants, with clear FILL THIS IN comments REQUIREMENTS: - one file, runnable as: python script.py - graceful failure: every file read wrapped with a clear error message naming the missing path - progress prints per major step (the user can't attach a debugger) - a --dry-run flag that validates inputs without writing - header docstring: purpose, inputs, outputs, and the exact verified-library assumptions Before writing, list which parts of my request are IMPOSSIBLE under these constraints and propose stdlib workarounds. Task: [describe the job]
Real world

The killer detail is the last line: asked to reconcile two Excel exports, Claude flagged "no requests, so the FX-rate lookup must become a manual constants table" BEFORE writing code - the exact failure that used to burn an afternoon inside the WorkSpace where debugging is misery.

LiveWorkflow 4 · Quick data product prototypes2 min▶
★ The prototype briefBuild a Streamlit prototype: app.py over data/processed/sales_clean.csv. Views: KPI header (revenue, orders, AOV - this period vs last), trend chart with date-range picker, breakdown table by [dimension] with search, and a "data health" footer (row count, last refresh, null warnings - pull from the catalog). Style: minimal, our indigo accent, no chart junk. Cache the load. README with run instructions. It's a stakeholder demo, not production: favor obvious code over clever code.

Fifteen minutes to a running dashboard changes stakeholder conversations: they react to something real, you learn what they actually need before the proper build. Same honesty as Session 4's prototypes: demo-grade, and labeled as such.

Demo 1 of 2

Messy CSV → clean + profiled + catalogued ★ 14 min · everyone in terminal

Setup (pre-session homework was: npm install + claude login working). Grab the practice repo: git clone [internal-repo]/claude-data-lab - it has a deliberately messy sales_export.csv.

Run /init, read the generated CLAUDE.md, add the two guardrails (raw read-only, PII masking) from Part 1.

Run the cleaning brief (Workflow 1). Read the profile it reports - what did it catch that you'd have missed?

THE key moment: it proposes the plan and stops. Reject one step out loud ("don't impute region - drop and log instead") - feel the control point.

The plan gate: your control point Approve the proposed cleaning step? yes no Script runs, CHANGELOG logs it, tests green Step dropped, logged instead (your call) Rejecting a step out loud is the control point: the loop only runs what you approved.
🔍 Click to zoom - approval decides what actually gets coded, not Claude

Approve, watch the loop run: script written, executed, CHANGELOG updated, assertions green.

Run the catalog generator (Workflow 2) on the result. Open docs/catalog/ - your dataset now has documentation newer than most production tables.

Data tip The practice repo uses synthetic data. On real data, your CLAUDE.md guardrails (PII masking, read-only warehouse) are doing real work - write them before the first real session, not after.
Demo 2 of 2

An offline-safe script, constraints-first ★ 6 min · everyone builds

Pick a real job you'd normally do inside the WorkSpace (reconcile two exports, monthly aggregation, format validation).

Run the offline constraints template with your job in the Task line. Read the "impossible parts" list first - that's the template earning its keep.

Test locally with --dry-run, then for real on sample files. One file, no imports beyond the verified list - confirm with a glance at the header.

Save the template as /offline-script (custom command) so the whole team writes WorkSpace-safe code by default.

After the session

This week ◐ 60 min total

Source material

Official courses covered

From claude.com/resources/courses:

✓Claude Code 1011 hr · what it is, how it works, install, first prompt, explore-plan-code-commit, context mgmt, code review, CLAUDE.md + subagents/skills/MCP/hooks pointers
✓Claude Code in Action1 hr · setup, adding context, making changes, controlling context, custom commands, MCP servers, GitHub integration, hooks (defining/implementing/gotchas/useful), SDK
Check yourself

Three questions before you go 🎯 ◐ 90 seconds

1 · Your control point when Claude Code works on data is...

Explore → plan → APPROVE → code. You're approving what happens to the data - that step is non-negotiable.

2 · A script destined for our AWS WorkSpaces must be...

No internet, no pip: single file, constants block, dry-run flag, graceful failures - and ask for the "impossible parts" list first.

3 · CLAUDE.md is best described as...

It's Session 2's "project instructions" for your repo. /init drafts it; your guardrails (raw read-only, PII masking) do the real work.

Session 5 cheat sheet · pin this

The methodExplore → plan (APPROVE IT) → code → commit. Plans are your control point on data.
CLAUDE.mdStack, commands, conventions, guardrails. /init drafts it; you correct it. Keep it lean.
Cleaning patternProfile → approved plan → logged script → before/after verify + pytest assertions.
Catalog patternMarkdown per dataset: schema, lineage, owner, (inferred) flags. Regenerate weekly, idempotent.
Offline scriptsConstraints FIRST: verified libs only, constants block, dry-run, graceful failures, "impossible parts" check.
Context hygiene/clear between tasks · guardrails in CLAUDE.md · permission prompts are a feature.