Your First Real Script
A real local script that reads a file, does useful work on it, and writes the result — your first tool that runs on your own machine.
You've set up your environment, learned what the tools are, and practiced reading code you didn't write. Now you build something real.
This lesson walks through a complete script — one that reads a real file, does something useful with it, and writes the result. The script reads a CSV file, filters the rows based on a condition you set, and writes the matching rows to a new file. It's not a toy. This exact pattern handles a huge amount of real business work.
The Shape of Every Script
Before looking at code, understand the shape. Every script you'll ever encounter — regardless of how complex it looks — is some version of three phases:
In: The script gets data. Usually from a file you point it at, but sometimes from an API, a database, or standard input.
Do: The script transforms the data. Filter rows. Calculate totals. Reformat fields. Extract patterns. This is the actual work.
Out: The script writes results. A new file, a printed summary, an email sent, a record written to a database.
When Claude generates a 60-line script and it looks overwhelming, find these three phases first. Everything else is just details of how each phase is implemented.
The Input/Output Contract
Before writing (or asking Claude to write) any script, be precise about the contract: what goes in, and what comes out.
Vague input/output thinking produces scripts that need multiple correction loops. Precise thinking produces working scripts on the first or second try.
Before you write a prompt to Claude, answer these questions in one or two sentences each:
- Input file: What is the file name and format? What columns does it have? What is the data's structure?
- Condition: What logic determines which rows you want?
- Output: What file name? What columns? What format?
"Process my spreadsheet" is a vague prompt. "Read sales-2026-q1.csv, which has columns Date, Region, Amount, Status. Keep only rows where Status is 'Closed Won'. Write those rows — all columns — to closed-won-q1.csv" is a precise contract that Claude can fulfill accurately.
What the Script Looks Like
Here is what Claude typically produces for the CSV filter task. Read this — don't run it. Practice the reading skill from the previous lesson.
import csv
input_file = "sales-2026-q1.csv"
output_file = "closed-won-q1.csv"
filter_column = "Status"
filter_value = "Closed Won"
with open(input_file, "r", newline="") as infile:
reader = csv.DictReader(infile)
rows_to_keep = [
row for row in reader
if row[filter_column] == filter_value
]
with open(output_file, "w", newline="") as outfile:
if rows_to_keep:
writer = csv.DictWriter(outfile, fieldnames=rows_to_keep[0].keys())
writer.writeheader()
writer.writerows(rows_to_keep)
print(f"Done. {len(rows_to_keep)} rows written to {output_file}.")
Read it using the four questions from "Reading Code You Didn't Write":
- What goes in? The file named in
input_file, read as a CSV where each row becomes a dictionary. - What does the middle do? Loops through every row, keeps only rows where the Status column equals "Closed Won".
- What comes out? A new CSV at
output_filewith the same columns, only the matching rows, plus a printed count. - What can go wrong? If the filter matches nothing,
rows_to_keepis empty and the output file will be empty.
You just analyzed a real Python script without knowing Python. That's the skill.
Running It Safely
Step 1: Make a copy of your input file. Name it test-sample.csv. Use that copy. Never run a new script on the only copy of your data.
Step 2: Change input_file in the script to point at your test copy.
Step 3: Save the script as filter_script.py in the same folder as your CSV. Any plain-text editor works — paste the code in, save with the .py extension, and ask Claude for help if your editor fights you. Then cd into that folder in your terminal.
Step 4: Run it from your terminal: python3 filter_script.py (on Windows, use python filter_script.py)
Step 5: Open the output file. Verify the results are what you expected.
Step 6: If the results are wrong, paste the script and the unexpected output into Claude and ask: "The output should have had X rows but has Y. What's wrong?"
That debugging loop — script → run → observe → explain to Claude → fix → repeat — is the complete workflow. You don't need to understand Python to drive it. You need to understand your data and your intent.
Building From Here
This script is a template. Every variation of "filter my spreadsheet" is a change to the condition. "Calculate totals by region" is a change to the middle section. "Send results by email instead of writing a file" changes the output section.
In each case, you describe the change to Claude in precise terms. Claude updates the script. You read the changed section. You run it on test data. You verify.
The BuildChallenge below asks you to write the script yourself, with Claude as your partner. The starter code and guidance scaffold the structure. Your job is to fill it in with Claude's help — and to read what you produce before running it.