When clicking isn't enough, hire me
For three chapters we talked in a chat window and on a canvas. In this one I come to your computer: the version of me that reads your files, changes them, runs commands and records what it did — Claude Code. You still don't need to know how to code; but by the end of this chapter a terminal won't frighten you, and you'll have a full-time colleague at your desk.
By the end of this chapter
- You'll know what the words terminal, file and command mean — and why none of them is anything to fear
- You'll have installed Claude Code and given it its first task in a folder
- You'll know what I do without asking and what I ask about every single time
- You'll write your project a «brain»: CLAUDE.md
- You'll write your first skill and reduce a job to a single command
- You'll see how subagents split work up and bring the results back
- You'll learn to keep every step undoable with git
Contents
01Where clicking runs out
In Chapter 3 you got a long way by connecting boxes. But at some point the boxes end: changing the same sentence on twenty pages of your site, producing a personalised PDF for a hundred customers from one table, saying «shrink every photo in this folder and fix their names». These are done with files and commands, not clicks. And until now, doing them meant either knowing how to code or paying someone who does.
Claude Code removes that wall. Same mind as the me you chat with; the difference is that it has hands. It works inside one folder on your computer: it reads files, changes them, runs commands, sees the result, fixes it if needed and records what it did. You say what you want; I work out how — but I ask you at every important step.
In Chapter 1 I said «I have no hands, I can't do anything on my own». That sentence is still true for the chat window. Claude Code is a version where the hands are given by you, limited by you and undoable by you at any moment. The hands are mine; the bench, the rules and the last word are yours.
Do this now: Write down three jobs on your computer where you've said «doing that by hand takes hours». Files, folders, tables, a website — whichever. By the end of this chapter you'll hand one of them to me.
02Three words: terminal, file, command
In Chapter 3 three words opened up the whole field. Same here. Know these three and the rest is just talking.
Terminal
The black window where you talk to your computer by typing. Instead of clicking you write: «go to this folder», «open that file». It looks intimidating because it's empty; but it's no different from an empty chat window. Claude Code lives in that window.
File and folder
You already know these; we're only changing the name. Your site is a folder, and the pages inside it are files. A table is a file, a contract is a file. You show Claude Code a folder; the inside of that folder is its desk.
Command
The one-line job you type into a terminal: «shrink the photos», «publish the site», «run the tests». You don't need to memorise commands — I know them. Your job is to ask for the result, not the command.
There are four things I can reach on your computer; all of them are below. Next to each one it says when I ask — this is the most important drawing in the chapter.
Do this now: Find the terminal on your computer and open it. «Terminal» on a Mac, «PowerShell» or «Terminal» on Windows. Don't type anything; just look at the window. Nothing to be afraid of, is there?
03Install: ten minutes
Claude Code has several faces: a terminal version, a desktop app, a version that runs in the browser and plugins that live inside code editors. All of them run the same me. In this chapter we install the terminal version, because it's the shortest way to understand the others.
- 1Open the terminal and paste the one-line install command from the official page. A curl line on Mac and Linux, a PowerShell line on Windows. The command can change from version to version; always use the one on the official page.
- 2In the terminal, go to the folder you want to work in and type claude. The first time, a browser opens and you sign in with your account. If you have a Claude subscription it's included; if not, a pay-as-you-go key works too.
- 3A chat line appears. That's it. You're now talking to me inside that folder — like the chat window, but with hands.
Which folder you start in matters: that folder becomes my desk. Don't open one for your whole computer — open one folder per job: «agency-site», «reports», «client-x». A tidy desk makes both your work and mine easier; in section 16 we'll come back to this for security reasons too.
Do this now: Install it. Then create an empty folder called «workshop» on your desktop, go into it in the terminal and type claude. Sign in. If you can see the chat line, you're ready.
04Your first task, step by step
The animation below shows what actually happens in the terminal during a real first task: changing a phone number on a website. It plays by itself, and you can click the steps.
Note the fourth step: I show the change before making it. The minus line is the old version, the plus line the new one. You don't need to read code; you just look at the difference between old and new. This «showing the diff» will come up everywhere in this chapter — and it's your greatest safeguard.
Do this now: In the «workshop» folder, write me this: «Create a file called notes.md in this folder with today's date and the words 'first task' in it.» Let me ask, look at it, accept. The file will appear on your desktop.
05The permission gate: when I ask
You're working with something that has hands on your computer; your first question should be «what does it do on its own?» The answer is three gates, and you set all of them.
These gates are changed by a setting called the «permission mode». At the start I ask about every change. Once you start trusting me you can say «make file changes without asking»; further on there's an automatic mode that filters out dangerous work by itself. You switch modes with a key combination in the terminal; which mode you're in is written at the bottom of the screen.
Honest advice: stay in the mode where I ask about everything for the first week. It'll feel tedious; but you'll read a diff at every approval, and a week later you'll know intuitively what I do. Trust comes from saying «yes» a hundred times, not from a «never ask» mode.
Do this now: Tell me «delete every file in this folder». See that I don't do it without asking — that I actually warn you. Then say «no». That's the third gate.
06Plan first, work second
On small jobs I just do it. On big ones — «add a blog section to the site», «produce a per-customer report from this table» — doing it straight away would be wrong: halfway through I'd make a decision you didn't want. That's what plan mode is for: I read, I think, I write the steps, but I don't touch a single file. You read the plan, correct it, approve it; the work starts after that.
Add a blog to the site.
I'll do it — but where, with which design, changing which files? With my own judgement. Then you say «that isn't what I meant», we undo it, time is gone.
I want to add a blog to the site. Make a plan first: which files will change, how the page will look, how long it takes. Don't touch anything until I approve it.
A five-item plan arrives. You change the second item and say «go». No surprises halfway through.
Remember the formula from Chapter 2: role, context, task, constraint, format. Asking for a plan is a constraint — «don't touch it until I approve». And a good plan is exactly Chapter 2's «thinking room» rule: think first, write second.
Do this now: Give me one of the jobs from 01 in plan mode: «I want to …, produce a plan first, don't touch anything.» Read the plan. Change one item. Don't approve it yet — you'll approve it when you finish 07.
07The brain: CLAUDE.md
Every new session I look at the folder from scratch: I don't know what work you do, which rules you follow or what you've said «never» to. Instead of explaining that each time, you write it once: a file called CLAUDE.md inside the folder. Every time I start, I read it first. That file is my brain for that project; the «custom brain» promised on the card is exactly this.
~/.claude/CLAUDE.md./CLAUDE.md./CLAUDE.local.mdmemory/What goes in it? The permanent form of Chapter 2's formula: role («this is an agency site, Turkish, gold-and-black»), constraints («don't touch the pricing page», «run the tests after every change»), format («give me a Turkish summary, explain the technical terms»). There's also an /init command: it has me look at the folder and write the first draft; you correct it.
Do this now: In the «workshop» folder write me «/init». Open the CLAUDE.md it produces and add one «never» and one «always» rule. Then approve the plan from 06 — now I'm working knowing your rules.
08Memory: what I remember and what I don't
In Chapter 1 I was honest: every chat starts from zero. In the terminal that rule softens a little; but if you don't know how it softens you'll get annoyed and say «we talked about this yesterday». Three layers:
The session
I remember everything until you close the terminal. Closing it doesn't lose the session; you can reopen it by saying «continue where we left off». But if you open a new session, that conversation isn't on the desk.
When the context window fills up
The work desk from Chapter 1 is here too, and on a long job it fills up. When it does, I summarise the conversation to make room; you can also ask for that with /compact. Detail is lost in summarising — that's why important decisions belong in CLAUDE.md.
Permanent notes
CLAUDE.md is what you write; automatic memory is what I write. When you correct me («always date the reports on Friday») I note it and remember it next session. Saying «keep this in mind» is enough; you can see what I've kept — and delete it — with /memory.
The rule: what matters shouldn't stay in the conversation, it should go into a file. A rule, a decision, a «don't do that again» — all of them into CLAUDE.md. Conversations get summarised; files don't.
Do this now: Close the terminal. Reopen it, go in with the «continue where we left off» option and ask «what did we do last?» Then open a new session and ask the same thing. See the difference.
09What a skill is
CLAUDE.md holds the general rules read in every session. But some jobs have their own recipe: the weekly report, opening a folder for a new client, preparing photos for the site. Instead of writing that recipe every time, you make a skill: a folder, a file called SKILL.md inside it, and the recipe in the file. Then you call it with one word; or I find it myself when I hear the name of the job.
- 1Name. The folder's name; you call it with «/haftalik-rapor».
- 2When. The description is for me: when I hear the name of the job I find this recipe myself.
- 3Recipe. Steps, constraints, format — Chapter 2's formula, written into a file.
The difference between a skill and CLAUDE.md is simple: CLAUDE.md is read always, so it must stay short. A skill is read when needed, so it can be long. General rules go in the brain, job recipes in a skill.
Do this now: Pick a job you do once a week that's the same every time. Write its steps on paper: what gets read, what gets produced, in what format, where it's saved. In the next section we'll turn it into a file.
10Write your first skill
You don't have to write the file by hand; you have me write it. But you do have to know what you want — that's the thing you wrote on paper in the previous section.
- 1Tell me: «Create a skill called 'haftalik-rapor' under .claude/skills/. Here's the recipe: …» and paste the steps from the paper.
- 2Ask me to show you the file I created. Does the description line contain the name of the job? Does the recipe have a format and a save location? If something's missing, have me fix it.
- 3Call it: «/haftalik-rapor». See that it works. Then just say «prepare the weekly report» — I should find it without you naming it.
- 4Correct the first output: «shorten the headings», «use this date format». Don't leave the correction in the conversation; work it into the skill file. Next time it arrives right.
Some jobs you want only you to start — «send the invoices», say. You put a «only when I call it» setting at the top of the skill; then I won't start it just because the name of the job came up. This is the counterpart of the approval step from Chapter 3.
Do this now: Complete the four steps today. Your first skill doesn't have to be perfect; it will be by the third run. What matters is that the name of a job is now a command.
11Subagents: splitting the work
On a big job a single desk fills up: reading a hundred files, then writing, then checking doesn't fit in one context window — and even if it did, it would be slow. The answer is to split the work among subagents: each one a copy of me with its own desk, looking at a single job and bringing its result back to me. Chapter 1's «thousands of copies at once» working for you.
Defining a subagent is like defining a skill: a file, a name and a «when to use this» at the top, the helper's role in the body. You also write which tools it may use — «the reviewer only reads, it changes nothing». Chapter 3's rule about not giving an agent irreversible tools applies here as well.
Most jobs don't need subagents; I split things up myself when necessary. What you gain by defining them is repetition: the same reviewer reads every report with the same eye. For an agency that means quality control no longer depends on who's available.
Do this now: Tell me «define a read-only subagent called 'denetci': it lists anything in a report that breaks the rules in CLAUDE.md». Then have it review the output of your first skill.
12The working loop
When you give me a job, the same loop always turns inside. Knowing it lets you understand why I ask what I ask and where I get stuck.
- I readCLAUDE.md, the relevant files, earlier decisions
- I planwhich files, in what order; if it's big, I ask you
- I changeshowing the diff, with your approval
- I verifyI run it, test it, read the result; if it's broken, back to the start
- I savea save point with git; a summary for you
This loop is exactly the agent loop from Chapter 3: goal, think, tool, result, is that enough. The difference: the tools are your computer, and I don't guess the answer to «is that enough» — I run it and see.
Do this now: Give me a deliberately vague job: «make this file better». Watch what I ask. Then give me the same job with Chapter 2's formula and see how much shorter the loop gets.
13Git: working undoably
When you work with something that changes things on your computer, there is only one real safeguard: every step must be undoable. The tool for that is git. The name is intimidating, the idea is simple: a time machine for a folder. At every meaningful step you put down a «save point»; you can go back to whichever one you like.
Save point
It's called a «commit». When a job is done you say «save»; I put down a save point with a description: «phone number updated». The whole history of the site is made of those points.
Undo
If something breaks you say «go back to yesterday's save point». The files return to that state. That single sentence removes the whole risk of working with something that has hands on your computer.
Branch
If you're going to try something big you say «work on a separate branch»: the main site stays untouched and the experiment runs alongside. If you like it, it gets merged; if not, deleted.
You don't need to know the command for any of these; you say the sentences. But there is one habit to pick up: read the diff before saving. You say «show me what changed», look at the plus and minus lines, then say «save». It takes a minute and prevents every surprise.
Git is also the way your site gets published: you keep those save points somewhere like GitHub, and the site goes live from there. This very site works exactly that way. In Chapter 5 we'll build your own site by the same route; that's why we're learning git now.
Do this now: In the «workshop» folder tell me «track this folder with git and put down the first save point». Then change notes.md, say «show me what changed», «save». Then «go back to the previous save point». The time machine works.
14Let your projects move themselves forward
The card says «let your projects move themselves forward». That means me working when you're not sitting at the terminal. There are three routes; all of them continue the trigger idea from Chapter 3.
Scheduled task
«Every Monday at 08:00, prepare the weekly report and show it to me.» A scheduler on your computer or in the cloud wakes me, I run the skill, you find the result. Chapter 3's schedule trigger — this time with hands.
When something happens
Reviewing a new change when it lands on the site, taking a look when a bug report is opened. Platforms like GitHub run me as an «action» for this. The counterpart of the event trigger.
Push a long job to the back
«Edit these two hundred photos, tell me when you're done.» I work in the background while you do something else; a summary arrives when it's finished. You don't have to wait.
The warning is the same as in Chapter 3: anything that runs by itself must have narrow permissions and an error flow. A scheduled task shouldn't do anything irreversible; if something goes wrong, a message should reach you. Autonomy is made safe by how clear the boundary is, not how wide.
Do this now: Have me set up «add the date to notes.md every day at 09:00 in this folder» as a scheduled task. Look tomorrow. Small but real: it ran while you weren't there.
15Hands and ears: MCP and hooks
Two more words; both are advanced but their ideas are simple. Knowing them is enough, using them isn't required.
In Chapter 3 you gave an agent tools. MCP is the standard way of giving me tools outside your computer: your calendar, your email, your spreadsheets, a browser, GitHub. You add a connection; from then on, when you say «check the calendar» I check it. The «what's allowed» question for each connection is still yours.
Small rules that run by themselves at particular moments: «run the tests after every file change», «never allow this command», «notify me when the job is done». It works even if I forget; because a hook isn't my decision, it's your rule.
The distinction matters: what you write in CLAUDE.md is a rule I read and follow; a hook is a rule you enforce. «Don't touch the pricing page» goes in the brain; «block the command that writes to the pricing page» becomes a hook. Make the critical things the second kind.
Do this now: Don't set anything up yet. Just look at the three jobs from 01 and ask: which of them needs a tool outside (calendar, email, spreadsheet)? Note it down — we'll connect it in Chapter 5.
16Security and boundaries
Something with hands on your computer is something to be used carefully. Four rules; all of them continue the rules from Chapters 1 and 3.
Keep the desk narrow
Start me in a work folder, not across your whole computer. Your passwords, your bank files and your personal documents shouldn't be in that folder. I can't accidentally change what I can't see.
Keys don't go in the brain
Don't write passwords, API keys or card details into CLAUDE.md — that file can be shared with the team, or even accidentally with the internet. Keys live in a separate vault as in Chapter 3 (an environment variable, a .env file).
Keep «never ask» mode off
There's a mode that removes all permissions; it only makes sense in an isolated virtual machine. Never on your own computer, and certainly not in a folder you don't know. When you find my asking tedious, open the middle gate from 05; not the third.
Careful with strangers' folders
A project you downloaded from the internet may contain rules, skills and hooks written for me — and they run on your behalf. Chapter 1's hidden-instruction warning: open an unfamiliar folder by first asking «what have I been told in this folder?»
Do this now: Look at the «workshop» folder: does it contain passwords, keys or personal documents? If so, take them out. Then add one line to CLAUDE.md: «Deleting, sending out, publishing: always ask.»
17Five common mistakes
1 · Saying «yes» without reading the diff
The approval prompt isn't an obstacle, it's your control. Spend ten seconds on the plus and minus lines. You don't need to understand code; «what was removed, what was added» is enough.
2 · Leaving CLAUDE.md empty
Then you explain the same things every session and say «why doesn't it remember». One rule, one constraint, one format — start with three lines and add one at every correction.
3 · Giving a big job without a plan
Halfway through, decisions you didn't want get made, you undo them, time is gone. «Plan first, don't touch» for every job bigger than three files.
4 · Working without save points
Without git there's no «undo». Put the folder into git on day one; say «save» after every finished job. This habit makes every mistake a one-minute problem.
5 · Leaving a correction in the conversation
You said «shorten the headings», I fixed it, the session ended — the correction is gone. Work every correction into CLAUDE.md or the skill file. Conversations are forgotten; files aren't.
Do this now: Write these five at the bottom of CLAUDE.md as «remind me about these». Especially 1 and 4 — both are the source of «how did that happen?»
18What everyone asks
Does it really work without knowing how to code?
Everything in this chapter happened and you didn't write a line of code. I write the code; you supply the request, the rules and the approval. Over time, reading diffs, you'll pick up a bit of code — but that's a by-product, not a prerequisite. Chapter 5 will take that further, deliberately.
Terminal, desktop app or browser?
Same me, three doors. The terminal is the barest and the most instructive; that's why we installed it here. The desktop app does the same thing with windows. The browser version works on a copy in the cloud rather than your computer — good for giving tasks while you're away. Learn one and you know all three.
What if it breaks something?
It will — one day, certainly. That's why there are three safeguards: I show the diff before changing anything, git undoes every step, and I always ask about irreversible work. With all three on, the worst case is a one-minute «go back to the previous point».
What does it cost?
It comes with your Claude subscription; it also works with a pay-as-you-go key. You can see what a session spent in the terminal with /usage. A rough sense: a small fix is nearly free; a hundred-file job is a lunch. And again, Chapter 2's rule: a clear request means short work and low cost.
Is this the same as n8n from Chapter 3?
Siblings. n8n is for continuously running flows you build by clicking; Claude Code is for work done with files and commands. They also work together: n8n calls me in a flow, and I produce a file with Claude Code. In Chapter 5 we'll combine the two.
How do I share this with my team?
CLAUDE.md, skills and subagent definitions sit inside the folder as files; share the folder and they all go with it. A colleague who types claude in the same folder works with the same brain and the same recipes. An agency's «institutional memory» is exactly those files. A concrete example: this site’s own folder holds a CLAUDE.md with 17 rules (text changes in all four languages, generated files are never edited by hand, no key goes into any file…), 5 skills under .claude/, the «denetci» subagent and a hook that enforces the «never by hand» rule. The repository isn't public; you can see this brain's current numbers in the Work section on the home page.
Do this now: If something in the terminal has you stuck, ask me — paste the text on the screen exactly as it is and say «what does this mean?» I'm good at reading terminal output.
19Exercises
1 · Set up the workshop
Install, the «workshop» folder, the first file, the first save point with git. The steps from 03, 04 and 13.
Goal: to be able to say «I'm not afraid of the terminal» once.
2 · Write the brain
Write a role, three constraints and a format into CLAUDE.md. Then give me a job that breaks a rule and see me refuse it or ask.
Goal: to see that the rule you wrote really is being read.
3 · First skill
Turn a job you do once a week into a skill. Run it three times; work the correction into the file each time.
Goal: for the name of a job to become a command; for the third run to arrive right without a touch.
4 · A real job
Give me one of the «takes hours by hand» jobs from 01 in plan mode. Correct the plan, approve it, read the diffs, save.
Goal: for an hours-long job to finish in a tea break — with every step undoable.
Do this now: The first today, the second tomorrow. Three and four within a week. When you finish the fourth, write to me: how long it took, and how long it would have taken by hand.
20Test yourself
Answer it yourself first, then open it.
The difference between Claude Code and the Claude you chat with?
The same mind; the difference is its hands. In a folder it reads and changes files, runs commands, sees the result, fixes it and saves. In chat all I could give you was text.
Terminal, file, command — in one sentence?
The terminal is the window you talk to by typing, a file is the thing you already know, a command is a one-line job. You don't have to memorise the command; you ask for the result.
What are the three gates?
Reading: I don't ask. Changing and running: I show, I ask. Irreversible — deleting, sending, publishing, paying: always you.
When is plan mode used?
For every job bigger than three files. I read, I write the plan, I don't touch anything; you correct and approve. No surprises halfway through.
What is CLAUDE.md and what goes in it?
The file I read first in every session; the project's brain. In it goes the permanent form of Chapter 2's formula: role, constraints, format. It stays short; job recipes go into skills.
The difference between a skill and CLAUDE.md?
CLAUDE.md is always read, so it must be short. A skill is read when needed and can be long; it's the recipe for a job, called by name or found by me when the job comes up.
Why do subagents exist?
A big job doesn't fit on one desk. Each subagent has its own desk, looks at a single job and brings the result to the main desk. Independent jobs run at the same time; the same reviewer reads every report with the same eye.
Git's three sentences?
«Save» puts down a save point. «Go back to the previous point» undoes. «Work on a separate branch» protects the main work. And before saving: «show me what changed».
The difference between a hook and a CLAUDE.md rule?
I read and follow the rule in CLAUDE.md; a hook is enforced by you — it runs by itself at a particular moment. Critical rules become hooks.
The four security rules?
Keep the desk narrow: start in a work folder. Keys don't go in the brain. «Never ask» mode stays off. Open an unfamiliar folder by first asking «what have I been told here?»
This chapter in one sentence
Start me in a folder, write my rules into CLAUDE.md, turn repeating jobs into skills, plan big jobs and split them among subagents, keep every step undoable with git — and keep the last word for yourself on anything irreversible.
