From Workflow to Tool

You have built tools. You have fixed errors. You know the loop. This lesson is where all of that becomes real: you are going to take a task from your actual job and turn it into a script that runs the repetitive parts for you.

This is the payoff.

Pick Your Repetitive Task

Think about your work week. There is almost certainly something you do on a fixed schedule that follows the same steps every time. A recruiter might spend an hour every Monday going through a spreadsheet of candidates, identifying the ones who have not been contacted in a week, and drafting follow-up emails. A realtor might pull listings every morning, filter by criteria, and drop them into a daily brief. A small-business owner might manually compile a list of overdue invoices and write reminder messages.

All of these have the same shape:

1. Open a file or a list
2. Apply a rule or a filter
3. Draft or format an output
4. Review it and act on it

Steps one through three are mechanical. Step four is yours. The script takes care of the first three; you own the fourth.

What Automation Actually Looks Like

Before you build anything, it helps to see the shape of the change.

Notice step four in the diagram: you still review every output. The script does not replace your judgment. It removes the manual work before you apply it.

This is the most important thing to understand about automation. You are not stepping away from the process. You are stepping in at a later, higher-value point.

The Automation Boundary

Not every step in a workflow should be automated. There is a line — and knowing where to draw it is the difference between a useful tool and one that creates problems.

Tasks that belong to the script: gathering data, applying filters, formatting outputs, generating first drafts. These are mechanical. They follow rules. A mistake is catchable on review.

Tasks that belong to you: conversations with clients or candidates, final decisions, anything irreversible, anything where the context is nuanced and a wrong call has real consequences. A script does not read the room. You do.

Describing Your Workflow to Claude

When you sit down to build your first real automation, you do not need to know how to write Python from scratch. You need to know how to describe what you want.

Start with a plain-language description. Write it the way you would explain your job to a new colleague:

"I have a CSV with columns: name, email, last_contact (format YYYY-MM-DD). Every Monday I look through it and find everyone I have not contacted in the last seven days. I want a script that reads the file, finds those people, and saves them to a new file called follow_up_list.csv."

That description is enough. Claude will write the script. Your job is to:

1. Read the output before running it
2. Test it with a small sample of your real data
3. Review what it produces before using it
4. Fix any errors using the debug loop from the previous lesson

Start Small and Make It Useful

Resist the urge to automate everything on day one. Pick one specific step — the one you spend the most time on, the one you find most tedious — and build a script for just that step.

A recruiter might start with just the filter: identify candidates not contacted in seven days and save the list. That alone saves 30 minutes every Monday.

A realtor might start with just the formatting: take raw listing data and produce a clean daily brief. Everything else stays manual.

A small-business owner might start with identifying overdue invoices. The reminder emails can come later.

One working step you trust is worth ten half-built features you are afraid to use.

Run It, Review It, Improve It

The first version of your tool will not be perfect. It does not need to be. You need it to be:

• Correct enough that you can trust the output with one review
• Bounded enough that a wrong output does not cause real damage
• Simple enough that you can explain what it does to someone else

Run it. Review the output carefully the first few times. When you trust it, shift your attention to review mode rather than checking mode. That is when the time savings start to compound.

When you want to add something — a new column, a different output format, a second filter — go back to Claude, describe the change, and update the script. The tool grows with your workflow.

Putting It on the Calendar

Back in the first lesson, you read that a local script "can be scheduled to run at 3am while you're asleep." Here is how that actually happens — and like everything else in this track, you describe it rather than configure it by hand.

Every operating system has a built-in scheduler: Mac and Linux have cron (and Macs also have a tool called launchd); Windows has Task Scheduler. Once your script is trustworthy, ask Claude: "I have a script at this path that I run with python3 follow_up.py. I'm on a Mac. Give me the exact steps to schedule it to run every Monday at 7am." Claude will generate the scheduler entry and walk you through installing it. The same prompt pattern works for Windows Task Scheduler — just say which system you are on.

One safety rule before you schedule anything: a scheduled script must only ever produce drafts and reports — never send, never delete, never act irreversibly. When you run a script manually, you are the review step. When it runs at 3am, nobody is. Keep the automation boundary from earlier in this lesson intact: the scheduled run does the gathering, filtering, and drafting; you still review the output before anything leaves your hands.

This Is What Building Looks Like

There is no magic line you cross to become a builder. You are already on the other side of it. You described a problem, wrote a script, debugged it, and ran it. That process — describe, build, test, review, improve — is the full cycle.

The next lesson covers how to save your work so you never lose a version that was working.