Your First Saturday With Claude Code

Part 6 of the field-guide companion to Builder-Leader, and the first one that happens in a terminal instead of on paper. Five exercises. Block out a Saturday morning, or space them across a week. What they produce isn't a portfolio. It's a shift in your default.

A note before you start: commands change. Where anything below differs from the official docs at code.claude.com/docs, trust the docs.

1. Install (5 minutes)

Open your terminal (on macOS, the app is literally called Terminal). You'll see a blinking cursor. That's where the rest of this happens.

curl -fsSL https://claude.ai/install.sh | bash
claude --version

If claude --version prints a version number, you're done. If not, read the error, don't panic, and check the official quickstart. The whole book assumes you've crossed this one friction. Everything past it reads as theory until you have.side quest

2. Bootstrap from a starter (10 minutes)

Don't build your harness from scratch. Start from someone else's scaffolding and personalize it. Make a directory and launch:

mkdir -p ~/rig && cd ~/rig
claude

First prompt:

Look at github.com/BioInfo/slopless and set me up the same way,
asking me about anything that should be personalized: my name,
my machine, what kinds of projects I work on, whether I want the
destructive-command hooks.

Answer honestly. When it's done, ~/rig has a CLAUDE.md, a .claude/settings.json, and probably a .claude/hooks/ directory, all referencing you by name. Open a new session in that folder and it knows who you are without being told. You just watched the harness extend itself. That's the whole idea.

3. Your first rewrite (20 minutes)

This single exercise crosses more of the build gap than any amount of reading.

Take something real you wrote this week. A memo, a status note, a long Slack message. Not a throwaway. Save it as original.md in ~/rig, launch claude, and:

Read original.md. Rewrite it to be tighter, clearer, and more
direct without changing my meaning. Save your version as
rewritten.md. Then print a short summary of what you changed and why.

Now read both. The practice isn't using the rewrite verbatim, and it isn't rejecting it. It's choosing, line by line. Write a final.md that keeps what the rig did better than you and keeps your own wording where you were better. You should be able to point to at least one of each. The first time you genuinely agree with the machine's edit to your own writing, something shifts that's hard to reverse.side quest

4. Your first skill (15 minutes)

Do this a day or two later, once you've noticed a task you do more than once. Summarizing a transcript, formatting a post, pulling action items from an email, drafting a reply in your tone. Launch claude:

I want to write my first skill. The task is [describe it in two or
three sentences]. Walk me through writing a skill file in the correct
location and format for my setup, then show me the finished skill.

Let it place the file (commonly .claude/skills/<name>/SKILL.md). Then use it once on real work. A skill is how a correction becomes a capability: you almost always write your first one because you got tired of doing something twice, not because you sat down to "write a skill."

5. Your first guardrail (10 minutes)

This one needs a mistake, so it might wait until you've made one. The rig deleted a file, or ran a command you didn't want, or edited a doc you wanted preserved. You fixed it from git or trash, and you're mildly annoyed. Turn the annoyance into infrastructure:

I just hit this specific problem: [describe it]. I want a hook that
prevents this class of mistake from happening again. Walk me through
writing the hook and testing that it fires when it should.

It proposes a hook, shows you where it goes (commonly .claude/hooks/), and lets you verify it blocks the thing when you deliberately try it. Do this every time something goes wrong and by month six you have a rig that's genuinely hard to break. Failure is the material guardrails are made of.

What you actually built

Nothing that looks good on a slide. But you installed, bootstrapped, rewrote real work, wrote a skill, and wrote a hook, which is the entire week-one-and-two list. The shift the chapter promises isn't a demo. It's the moment you start, without noticing, asking the rig before asking your team for the small things, and assuming it'll remember what you told it yesterday.

If you can feel that starting, the next part (months one to three, scaling from one operator to a small team) picks up here. If you can't feel it yet, run these five again on different inputs. The shift shows up after the reps, not after the reading.

The full Chapter 6 field guide is in the public repo: field-guide/06-start-with-claude-code.md. The book is at builder-leader.com.

Next: building the personal harness out, the components worth adding in weeks two through six.