Build a Small Tool with Claude and Claude Code

Pick one repeated task, describe the tool in plain words, let Claude Code build it in small steps you can run and judge, and check it before anyone relies on it. The goal is a small tool that works, not a software product.

Practice, not research: the steps, the rules file and the checks on this page are working practice, not tested findings. The risk that AI output can be confidently wrong, called confabulation, is named in the NIST Generative AI Profile (NIST, 2024). Tools change quickly, so use Anthropic's own documentation for installation and current commands.

Use it when:

• You do the same task by hand every week (sorting, summarizing, converting, checking) and a small tool could do the dull part.
• You have an idea for a calculator, a form, a report generator or a file converter and want to try it before paying for development.
• You need a tool for your own work or a small team, not for thousands of customers.

Skip it when:

• The tool would handle personal data about customers, employees or patients, or run unattended with money or safety at stake. Get a developer, and read 10.3 Rules That Apply to My Role first.
• A spreadsheet or an existing product already does it. Sort the task first in 10.7 AI Task Map.

Two tools do two jobs. Claude, in a chat, is where you think: you describe the task and ask it to challenge your plan, name what you forgot and write a short specification. Claude Code is an assistant that works inside a folder on your computer: it reads files, writes code, runs it and shows you what happened, and it asks before changes that matter.

Three habits make this work for a non-programmer. Start with a brief, not with code: the clearer the brief, the better the tool. Work in small steps, run each one yourself and keep the ones that work. And check the result as you would check an analyst's work, because the tool can look right and be wrong, and AI output, code included, can be confidently wrong (NIST, 2024). Limit: you will not catch everything a developer would, so keep the first tool small, local and low-stakes.

Strong answer: (illustrative) one job, one user, concrete input and output, and a limit: "Turns a weekly CSV export into a one-page summary for the site manager. Never deletes or changes the original file." Not: "A tool that helps with reporting."

The one job this tool does:

Who uses it and how often:

What goes in (file, text, numbers; the format):

What comes out (a file, a page, a number; what it should look like):

What it must never do (for example change the original, send anything anywhere, touch real customer data):

The simplest form that could work (a script you run, a single web page that runs in your browser, or no tool at all):

What I do by hand today, and how long it takes:

Illustrative example: the person, firm and all numbers are made up.

A project coordinator at a small Norwegian construction firm gets site reports as a text export every Friday and spends an hour turning them into a summary for the site manager. She writes the brief in Claude: one job, input a text file, output a one-page summary, never alter the original. Claude suggests a small script she runs, not a web app. She puts the rules in CLAUDE.md, including "ask before installing anything", and asks Claude Code for a plan, then builds in four steps, running each on a made-up sample week. She checks the totals by hand for one week and tries an empty file, which gives a clear message. The tool runs on her computer only. She is the owner and sets a review in six months.