You've been configuring Claude, building Artifacts, and shaping how every conversation starts. Now you'll take a different step — building a real, working tool on your computer that handles a piece of your professional work end to end. A script you run when you need it, that takes inputs and produces a finished deliverable. That's what Claude Code is for. By the end of this lesson, you'll have a working tool, and you'll know the limits of what's worth building this way. Let's get started!

Until now, Claude could work with files you uploaded or connected. Claude Code is different because it works inside a local project folder on your computer. You build tools with your actual files — scripts and programs that live on your machine, run when you trigger them, and do real work on your data.

A regular Claude chat is for conversation — you ask, it answers, and anything it says lives in the chat. An Artifact is for interactive tools that others can use through a link. Claude Code is a best fit for tools that need to:

When the work involves your local files and produces a real deliverable, Claude Code is the best choice.

Imagine this: you run a small consulting practice with two retainer clients. Once a month, each client gets a status report — your formal summary of the past month's work. You've been producing these reports the same way for 9 months. Each one takes about 90 minutes.

You're going on vacation in three weeks. Your colleague Sarah will cover both clients while you're away. Two reports are due during that time. Sarah is competent, but she doesn't know your format, your sources, or the months of context behind these clients. If she produces the reports from scratch, the clients will notice the difference. You're going to build her a tool.

The data isn't in one place. Producing the report means cross-referencing across three sources:

The 90 minutes are the cross-referencing work. Each source on its own is incomplete. The tracker doesn't capture the why. The meeting notes capture conversations, but you don't know what made it into the tracker. The email thread surfaces what's open, but doesn't connect to either.

You give it three inputs:

It does the cross-referencing work and produces a finished Word document — the kind of report you'd send to the client after a quick proofread.

Claude Code works inside a folder. Before building anything, you create or choose the folder the tool will work with.

The project tracker and meeting notes live in your project folder, where Claude Code can read them directly. The email thread is different — it lives in Gmail, and the tool needs a way to reach it.

That's what Connectors are for. Go to Customize and select Connectors. Click "Add" then "Browse connectors," and then choose Gmail. Sign in, authorize the connection, and Gmail becomes a source the tool can read from. The connection happens once, and the tool uses it every time it runs.

The temptation is to start prompting immediately. The better move is to describe the tool to yourself first — in writing, in your project folder — so when you prompt Claude, you're handing it a real specification.

A clear spec covers four things:

Skipping this is the most common reason vibe-coded tools end up nearly working instead of actually working.

Now you build. The prompt is short because the spec does the heavy lifting.

As Claude starts building, you'll notice it doesn't just silently write the file. It pauses and asks. That's the default behavior: Manual permissions mode. Claude tells you what it's about to do, and you approve each step. For a first build, this is the right default: you see what's happening and learn what the tool touches as it's being made.

There are other modes for when you don't want to approve every step:

You have 9 months of these reports in a folder. Each one was produced by you, by hand. You know what a correct report looks like, because you wrote them. That's your verification standard. The tool's first real test is running it against last month's inputs. The output should match the report you actually sent.

You run the tool. It produces a Word document. You open it next to last month's actual report and read them side by side. You'll find three kinds of things:

The misses are the iteration material. Don't fix the code — describe the miss to Claude, and let it iterate the tool.

When the tool's output doesn't match the reference, the loop is:

You repeat until the output matches. Each pass narrows the gap.

Not everything that could be a tool should be a vibe-coded tool. Three categories of work fit:

Knowing which bucket a tool falls into is the most important calibration in vibe coding. Over-scoping into the wrong bucket is how Claude Code projects get abandoned.

The standard place to write good documentation is a file called README.md, saved in your project folder. When anyone opens a tool they've never seen before, the README is the first thing they look for — that's the whole job of the file.

This is a documentation example for a different tool — read it as if you're about to use it for the first time: "Tool: expense-categorize. Usage: run the script with your expense data. Output: a categorized version. Edge cases handled." You'd immediately hit the questions this documentation doesn't answer:

Documentation that doesn't survive a stranger's reading isn't ready for a team handoff. Picture the failure: Sarah opens the documentation and can't figure out where to put her data or which command to run, and then ends up texting you from the airport.

The tool lives on your computer. To make it Sarah's tool during your vacation, you need to get the project folder onto her computer. The simplest way is to zip the whole project folder and send it to her. She unzips it on her machine, opens the folder in Claude Code, and the tool is ready to run. Because the tool uses relative paths, it works wherever she puts the folder.

From here on, generating a new client report is straightforward — for you or for Sarah. Drop the new month's inputs into the data folder (or, for your colleagues, into a copy of the folder). Then open the tool's interface, set the client name and the month in the Run panel, and click Generate report. That's it!

You have a working tool. You've verified it against 9 months of reference reports. You've documented it for Sarah. The hard work is over. What's left is the small habit of running the tool yourself once before vacation — on this month's data, with this month's inputs — to confirm everything's working in your absence. If anything looks off, you fix it now. By the time Sarah's covering, the tool is solid.

A quick note: If you've never used Claude Code before, there's a separate course that walks through the installation, the desktop app, and the core workflows for vibe coding and automations.

You've built a tool that turns a 90-minute recurring report process into a faster, reviewable workflow. Sarah can run it. In the next lesson, you'll meet Cowork — the layer that wraps automation around tools like this one. The same client report tool can become part of a larger workflow that runs without anyone triggering it. Let's keep going!