# The Builder's Cheat-Sheet

*Print this. Keep it by your keyboard. It's the whole approach to building tools on one page.*

## You are the architect. Claude is the team.
You own the goal, write the spec, make the decisions, and hold the standards. Claude does the
hands-on building. You never touch the keys of the code itself.

## Spec twice, build once (how to ask for a tool)
Before you build anything, hand over a one-page spec:
> **Goal:** what the tool should do, stated as an outcome.
> **Inputs:** what you'll feed it (a file, a template, a folder).
> **Outputs:** what it should hand back (a document, a page, an answer).
> **Rules:** the standards only you know ("flag anything down more than 10%").
> **Done looks like:** how you'll know it works.
> **And:** "Walk me through your plan first — don't create anything until I say go."

## The build loop
Rough first version → try it → refine in small steps. Aim for **working**, then better. Don't
chase perfect on the first pass. *A tool earns its keep the second time you run it.*

## The five builder's safety rules
1. **Save a point first.** A save point is a seatbelt — buckle it before any change that matters.
2. **Test before you trust.** Happy path, edge cases, bad input. Never hand real work to an untested tool.
3. **Read before you approve.** Claude proposes; you decide — every time.
4. **Keep private things out of shared tools.** Strip real data and secrets before you hand a tool to anyone.
5. **Stay self-contained.** Book 2 tools run on your own files, by hand. Live connections and automation are Book 3.

## Test like an architect
Run the tool three ways before you rely on it: a **normal** input, a **messy edge case**, and a
**deliberately bad** input. Check the output yourself — especially any numbers. A wrong result
that looks right is the only kind that can quietly hurt you.

## Make it reusable
A tool that runs once was a task in disguise. Turn the changing details into **inputs and
settings** so the same tool does next month's job without a rebuild. One tool, many jobs.

## Keep tools alive (maintain + memory)
Tools drift when their inputs change. Make small, saved upgrades — never big rewrites. Keep a
`CLAUDE.md` as the toolkit's living spec: update it when a tool changes, so every session starts
knowing your standards. *Buttons change; principles don't.*

## Share it safely
Hand over a folder, not a mess: **keep** the tool, **strip** real data and secrets, **explain**
with a five-line how-to. Still no server — sharing a folder is Book 2; publishing a tool is Book 3.

## When a tool fights back
Ask **"what changed?"** before "how do I fix it?" — the input, a setting, something you did, or
the surroundings. Hand the exact symptom to Claude to diagnose. Fix small and durable, or restore
from a save point. You always have the restore. Stay calm; you can always undo.