If you run a business or work inside one, this is the guide I wish I'd had when I started. It takes you from never having opened Claude Code to using it well enough to save yourself hours every day. You don't need to be a programmer or have a technical background. You need a paid Claude plan.
Most of this is about getting real work done: proposals, lead lists, client onboarding, inbox triage, reports, contracts, internal tools. The coding is just the engine underneath, and you tell it what you want in plain English. I run a B2B lead generation and sales automation business, so my examples lean that way, but the same moves work for any firm with repeatable office work.
It's in three parts.
- Part one teaches you Claude Code itself, every idea you need, plainly explained. Read this even if you never build a thing.
- Part two shows you how to wrap it into an operating system for your business, so every session builds on the last instead of starting from zero.
- Part three is for the brave: actually building software. There's a hard warning in there, because this is where most non-technical people get burned, and I'd rather you hear it from me first.
Here's everything, in order.
Part One: Claude Code, explained from scratch
No worked examples here. Just the ideas, laid out clearly, so the rest of the guide makes sense. Get these and you're ahead of most people who've used the tool for months.
1. What Claude Code actually is
You've probably used the Claude app or ChatGPT. You type, it answers, and that's where it ends. It can't open your files, send an email, or fill in a spreadsheet.
Claude Code is the same brain with hands. It runs on your own computer, inside a folder you choose, and it can do things: read and write files, run programs, control a browser, reach into your other tools. You still talk to it in plain language, and it acts on what you say.
A useful way to picture it: the model on its own is just text in, text out. The thing wrapped around it that gives it tools, memory, and the ability to act is called the harness. Claude Code is that harness, and right now I'd say it's the best one there is. Worth knowing, because the harness keeps getting better on its own. Tricks that mattered a few months ago are now built in. The consequence, which we'll return to: you need less and less scaffolding to get great results.
For a business owner, all this turns into money saved. One person running a small agency can have it scrape a lead list, write the cold email, build the proposal, label the inbox, and draft the follow-ups. Jobs that used to need a virtual assistant or a junior hire become a single command. Heavy users talk about time savings in the tens of hours a month. How far you get depends on how well you learn it, which is what this guide is for.
2. Getting set up
You need a paid plan
Claude Code isn't on the free tier, and I'll be blunt about the entry plan. The cheapest paid tier, the $20-a-month plan, does nothing for you here. You'll burn through it in minutes and spend your day staring at usage limits. To do anything serious, start on the $100-a-month plan at a minimum. That's the real floor. The heavier plans above it give you more usage again and more access to the most capable model. The number sounds steep until you weigh it against the hours it gives back once you're any good with it, at which point it's the easiest money you'll spend all month.
Install it
Search "Claude Code install" and you'll land on the official documentation. It gives you one line to paste. On a Mac you open the Terminal app; on Windows you open PowerShell. Paste the line, press enter, wait a moment, and it's installed. Then type claude to start it, and log in with your plan the first time.
That's the whole setup. Everything past this point is free.
Where you run it
You can run Claude Code in a few places, and the choice confuses beginners more than it should.
- The terminal (the black command window). The most powerful option. Everything works here, and some things work only here.
- The Claude desktop app or the web app. Friendlier to look at, slightly fewer features.
- An IDE like VS Code, Antigravity, or Cursor. An IDE is three things in one window: a file browser down the left, a text editor in the middle, and the part that matters, a built-in terminal panel.
My advice, and this is the bit most beginners get wrong: open an IDE like VS Code or Antigravity, then run Claude Code in the terminal inside it. Every IDE has a terminal panel built in, and that's the sweet spot. You get the full power of the raw terminal, where certain advanced features only ever happen, with all the convenience of the IDE wrapped around it: the file browser down the side, your files open in front of you, everything visible while it works. So don't agonise over terminal versus IDE. Open the IDE, open its terminal, and work there. And if the terminal scares you for any reason, don't let that stop you: you can run Claude Code perfectly well through the IDE extension, the Claude desktop app, or online in the browser, and still get most of the way there. The terminal is the ideal, not a requirement. Both editors are free downloads. If you do add a chat panel, only install the official one published by Anthropic, the one with the verified mark. People hide harmful code in fake copies of popular tools.
What you see on screen
When it's running you'll see the model you're using, your current folder, a box to type in, and a little counter. Two numbers matter: the model, and the context (a percentage that climbs as your conversation grows). We'll come back to context, because handling it well is most of the difference between people who get good results and people who don't.
3. The core mental model
It works inside one folder, on your real computer
Claude Code lives in a folder you point it at, and it can change real files there. That's its power and its risk. Keep each project in its own folder so it isn't rummaging through your whole machine.
Permission modes are the safety dial
You decide how much it can do without asking. Cycle through the modes with Shift+Tab:
- Ask before edits (the default). It asks permission for every change. Safe, slow.
- Accept edits. It edits existing files freely but still asks before creating new ones.
- Plan mode. It can read and research but not change anything. More on this in a moment.
- Bypass permissions. It does whatever the task needs without asking. Fast.
- Auto mode. Newer. Claude decides for itself which actions are safe to run without checking and which to pause and ask about, instead of you setting the dial by hand.
Bypass mode is faster, because you're not approving a change every few seconds. It also carries real risk, since it can delete and create files on its own. There's a known story of someone in bypass mode whose machine got wiped by a misread command. Rare, but it's why you never point it at anything you can't afford to lose. Start on accept edits while you're finding your feet. I typically use bypass, as do most people.
Tokens and the context window are your budget
Everything you type and everything it says back is measured in tokens. A token is roughly a word. The model can hold a fixed budget of tokens at once, called the context window. When it fills up, the session has to wrap up or compress itself.
Here's the part nobody tells beginners, and it's the single most important idea in the whole guide: the more you stuff into the context window, the worse the answers get. People assume a full context just costs them money and a little speed. The bigger price is accuracy. A model overwhelmed with information starts pulling the wrong details and stating them with total confidence, the same way a person drowning in paperwork grabs the wrong file. The people who get great results treat their context window as the most precious thing they own and keep it lean on purpose. Almost everything that follows comes down to keeping that window clean.
Context rot is real, so reset often
Pile more into one conversation and the answers get worse while each reply costs more. This is context rot. The fix is simple. When you switch to a different job, type /clear to wipe the conversation and start fresh. Rule of thumb: if you're past about a quarter of the window on something unrelated, clear it.
Starting fresh in Claude Code isn't like starting fresh in a chatbot, where you lose everything. Claude Code lives in your folder, so it can just read your files again to catch up. Clearing has almost no downside and a real upside. It gets sharper and cheaper.
Plan before it acts
When a job is more than trivial, switch to plan mode first. It researches, reads your files, asks you a few clarifying questions, and writes out a plan before touching anything. You read the plan, approve it, then it builds.
This does more for the quality of your results than anything else. A minute of planning saves ten minutes of building. Let it act straight away and it often gets halfway down a wrong path, and undoing that costs far more than the planning would have.
The other side of this: don't plan a one-line job. If you can describe what you want in a single sentence, just ask for it. Planning earns its keep on the bigger, fuzzier work, not on a typo.
The single highest-value habit here: for anything non-trivial, tell it directly to ask you 10 or 20 questions before it starts, and answer every one. Each answer removes a guess. This matters even more when you're building something serious, because the failure you'll hit most often is misaligned work. The thing comes back perfectly built and still not what you had in mind, because it assumed a detail you never spelled out. Make it interrogate you first and that gap closes.
Be specific about what you want
Most disappointing results trace back to a vague ask. The tool is good, but it can't read your mind, so the more precise you are, the less you'll find yourself correcting. Three habits do most of the work.
Name the thing. "Fix the error on the sign-up page in this file" gets you somewhere; "improve the form" doesn't. Point at the exact file and the exact problem.
Point to an example. The quickest way to get what you want is to show it something close. "Write this proposal like the one in this folder." "Build the new page to look like that one." Show it the pattern and it copies that, so you don't end up with something you only half-like. You can drop a file straight into your message by typing an @ and its name, and it reads that file before it answers.
Say what "done" looks like. "People can't log in once their session times out. It's probably in the login area. Write a test that reproduces the fault, then fix it." Now it has the symptom, where to look, and how you'll both know it's solved.
None of this is technical. It's the brief you'd give a sharp new hire so they don't come back two hours later with the wrong thing.
Put a check in the loop
Here's the habit that separates good results from frustration. Most people give a task, get an answer, give the next task, get the next answer. When the answer isn't quite right, they feel let down and assume the tool is weak.
Build a check into the loop instead. Give the task, let it do the task, have it check its own work, then fix. For a web page, the check is a screenshot it takes and compares against what you wanted. For a tool, the check is a test it runs to see whether the thing actually does the job. The whole value of AI is speed. A person might get closer to right first time, but a person takes five hours. The machine gets to 80% in seconds, then 90%, then 95%, looping fast, and lands somewhere very good in minutes, as long as it can see its own mistakes and correct them. So whenever your results disappoint you, ask one question: is there a check in the loop? If it can't see its own output, it can't improve it.
Two things sharpen the check. Ask it to show you the proof: the test result, the command it ran and what came back, the screenshot. A claim that it's done is worth little; the evidence is worth reading, and reading it is quicker than redoing the work yourself. And when something breaks, get it to find what's actually causing the fault and fix that, so the same problem doesn't resurface next week wearing a different coat.
Treat it as a collaborator, and ask it to explain
The people who get the most out of this don't just say "yes, yes, build it." When it suggests something you don't understand, stop and ask it to explain. It's an endlessly patient tutor. If it asks which tool you want and you don't know what the options mean, ask. That's how you actually learn. Clicking accept and hoping teaches you nothing.
4. CLAUDE.md: the file that steers every session
Inside each project folder you can keep a file called CLAUDE.md. It's a plain text file of instructions, and this is the thing most people get wrong, so read this section slowly.
First, what a Markdown file even is
A Markdown file is just a text file with a .md on the end. Plain words, no special software. You add light formatting with everyday symbols: a # at the start of a line makes a heading, a - makes a bullet, **stars** make text bold. That's it. You can open and edit one in any text editor, or ask Claude Code to write it for you. The whole machine runs on Markdown files. Your instructions, your notes, your knowledge, all of it lives in these simple .md files, which is exactly why a non-technical person can drive the whole thing. You're not writing code. You're writing notes.
The one thing you must understand about CLAUDE.md
CLAUDE.md is glued to the front of every message you send. The technical way to say it: it's appended to the system prompt. In plain terms, before Claude reads a word of what you typed, it has already read the whole of your CLAUDE.md, every time, on every message, all day. It's always there, always taking up room in that precious context window.
So the rule writes itself: keep it short. Everything you put in it, you pay for on every message of every session, whether it matters to the job in front of you or not. A bloated CLAUDE.md doesn't make Claude smarter. It makes it slower, pricier, and past a point worse, because the clutter crowds out the actual task.
Cap it at around 100 lines
I'd cap it at roughly 100 lines. Not 200, not 500. A hundred, lean and clear.
Two reasons. First, the always-loaded cost above. Second, and this surprises people: Claude keeps getting better, and the harness around it keeps getting better, fast. You need less hand-holding every month than the month before. Rules that helped a year ago can actively hurt now, because the model already knows most of it and you're just adding noise. People love to over-engineer this file. They paste in whole manuals and end up with a worse assistant than the person who wrote ten clear lines. Less is more here. Keep it light, keep it clear, and cut when in doubt.
Reference other files instead of pasting them in
Here's the move that makes the 100-line cap easy to live with: CLAUDE.md can point to other Markdown files instead of containing everything itself.
You don't paste your full set of rules into CLAUDE.md. You keep them in separate .md files, and in CLAUDE.md you write a single line like "when working on proposals, read rules/proposals.md." Now Claude only opens that rules file at the moment it needs it, for a proposal job, and ignores it the rest of the time. The detail loads on demand, just when it's needed, instead of squatting in your context window all day.
That's the whole point, and it's the same trick the tool uses to read a big project: it looks at the file names first, and only opens a file's contents when the job calls for it. So CLAUDE.md becomes a short table of contents that says "here's how I work, and here's where to look for the detail when you need it." Short and always loaded at the top. The heavy detail in side files, pulled in only on demand. That's how you stay light without losing anything.
Global versus project: you have two of these
This trips everyone up, so let me be plain. There are two CLAUDE.md files, and they stack.
- The global one lives in your home folder and applies to every project you ever open. This is your always-true context: who you are, what your business does, your offer, your goals, how you like to work. If Claude Code is going to run your business, it needs the full picture of your world, the same context you'd hand a sharp new hire on day one. Keep the headlines here and point to the detail (your brand, your offer, your numbers) in separate referenced files. It's loaded everywhere, so keep it to things that are true everywhere.
- The project one lives inside a specific project folder and applies only to that folder. This is where project-specific detail goes: what this project is, its rules, where things live, who the client is.
When you start Claude Code in a folder, it reads both, the global first, then the project one on top. (There's also a third managed layer for big companies, which almost nobody reading this needs.) The skill is putting each thing in the right place: timeless personal stuff in global, project facts in the project file, heavy detail off in side files that load on demand.
How to actually fill it
- Don't even write one at first. The tool is excellent straight out of the box. Work without a CLAUDE.md for a while, feel where it keeps guessing wrong, and only then write rules to fix those specific misses. Rules you write before you've felt the friction are usually rules you didn't need.
- Make the first one automatically. When a project has some work in it, type
/init. It reads through the folder and writes a sensible starting CLAUDE.md describing the project and how to work in it. - Put the most important rules at the top. The model remembers the start and end of a file best and forgets the middle, much like people do. Anything it must never do goes first.
- Make it self-healing (the most valuable line in the file). Add a standing rule: when something goes wrong, fix the cause so it can't happen again, not just patch the one run. When a saved skill trips on a bad assumption, have it repair the skill itself so the next run is clean. A failure should cost you once, and over time the whole system gets steadier instead of repeating the same mistakes. You can also ask it, after a job, "how could you have done that faster and for fewer tokens?" and fold the answer in as a preference.
- Prune it like you'd tidy a desk. Review and cut. A rule that's no longer earning its place is just weight. For each line, ask one question: would taking this out make Claude get something wrong? If the answer's no, it's clutter, so cut it.
5. Skills: turning a repeatable job into one command
To my mind, this is the most valuable thing here for a business.
A skill is a saved set of instructions for a job you do over and over, with the small programs it needs bundled alongside. You write it once, in plain English (it's just a Markdown file again), and from then on one command triggers the whole job. Think of it as a checklist you hand to a very fast junior employee who never gets bored.
The clever part, and the reason skills beat stuffing everything into CLAUDE.md, is how they sit in memory. Claude carries only a one-line description of each skill, just enough to know it exists and what it's for. The full instructions load only when the skill actually runs, and not a moment before. So you can keep dozens of detailed skills on hand and they cost almost nothing until one is needed. CLAUDE.md is always on; a skill is on demand. Keep CLAUDE.md tiny and push your real procedures into skills.
Who gets to fire it
You hold the dial on this, and it matters more than it sounds.
By default, two things can trigger a skill: you, by typing /its-name, and Claude itself, when your request matches the skill's description. (That's why a clear description is worth getting right: it's how Claude knows which skill fits.) Claude reaches for the right one the way you'd grab the right checklist off the shelf, and only if you've allowed it to.
When a skill has real consequences, lock it to manual. A single line in the skill (disable-model-invocation: true) tells Claude never to fire it on its own, so from then on it runs only when you type /its-name. This is what you want for anything that sends an email, deploys, commits, or takes a payment, where you should be the one choosing the moment. A manual-only skill isn't even carried as a description in context, so it costs you nothing at all until you call it.
You can also go the other way and hide a skill from the menu so only Claude uses it, which suits background knowledge that isn't something you'd ever "run" yourself.
How they self-heal
A skill beats a rigid program in one way. When a step goes wrong, the model uses its own judgement to fix it on the spot, then updates the skill so the next run doesn't trip on the same thing. A checklist that repairs itself, and with the self-healing rule in your CLAUDE.md (from the last section) it does this without being asked.
Building one
You don't write it from scratch. Use the skill-creator (type /skill-creator). You describe what you want, give it an example of the input, and it writes the skill in the right format. Then you test it on a fresh session, give feedback when it slips, and tighten it. After a few rounds it's reliable maybe 98% of the time, which beats most people. The skill-creator can even run quick before-and-after tests to check the skill genuinely beats doing nothing.
One more thing worth knowing: a skill and a sub-agent (more on those shortly) are nearly the same thing under the hood, both just Markdown files describing a job. Skills turn the repeatable work of your business (onboarding emails, proposals, prospect research, drafting replies) into commands that run in seconds. Turn each repeatable job into a skill and one person quietly runs the workload of a small team on the rules-based parts of the work.
6. Connecting your other tools: lean on the CLI
Skills are jobs you define. Sometimes you want Claude Code to reach into software someone else built: your email, your calendar, your CRM, a web browser. There are a couple of ways to wire that up, and they all work. The one thing worth knowing early, which took me months to work out: where a CLI exists, it's far more token efficient, so reach for it first.
First, what a CLI even is
CLI stands for command-line interface. It's a tool you drive by typing commands in the terminal instead of clicking around on a screen. Claude Code is itself a CLI. Loads of the services you already pay for now ship one too: there's a CLI for your email, your calendar, browsers, GitHub, deployment, dozens of everyday tools. Because a CLI lives in the same terminal Claude Code lives in, Claude can run it directly, exactly the way you would by hand.
MCP and connectors: fine, just heavier
MCP (and the one-click connectors built on the same idea) is the other way to plug Claude Code into an outside tool. It works, it's often the easiest way to connect something, and in plenty of cases it's exactly the right call. The one thing to understand is the cost: every MCP you connect is loaded into the context window the moment your session starts, and it sits there whether you use it or not. Some are heavy. A single one can quietly eat tens of thousands of tokens, sometimes a fifth of your whole budget, before you've typed a word. Connect three or four you rarely touch and every message of every session runs slower and pricier.
A CLI doesn't carry that standing cost. It's free until the second Claude actually runs a command. So my rule of thumb: where a CLI exists, it's usually the leaner choice; reach for a connector or MCP when there's no CLI, or when it's simply the easiest way to plug something in.
Browser automation is the one place to be firm: always use a CLI, either the Playwright CLI or the Vercel Agent Browser CLI, and never a browser MCP. A browser MCP is hugely token-heavy and inefficient for the same job, so it's not worth it.
The move that makes CLIs effortless: get the skill
A CLI on its own is a wall of commands and flags Claude doesn't automatically know. The fix is the trick from the last section: get the skill that teaches Claude Code how to drive that CLI. Most popular CLIs already have one written. You install it once, and from then on Claude knows the commands and the right way to use that tool, with no explaining from you and no heavy MCP squatting in your context. A small skill that teaches a CLI might cost a few dozen tokens to have available. The equivalent MCP can cost more than every skill you own put together.
So the pattern when you connect a new tool: check whether it has a CLI (most things you pay for now do); if it does, that's usually the leaner route, so install it and get the skill that teaches Claude to use it; if it doesn't, a connector or MCP is perfectly fine.
7. Context management in practice
You now know why context matters. Here's how to run it well day to day, because this is where most complaints about cost and quality start.
Type /context and Claude Code shows you exactly what's filling its memory before you've started: the system instructions, your CLAUDE.md and rules, the built-in tools (these alone can top 15,000 tokens), any MCP tools you connected, your skills, and finally your own messages. The lesson lands fast: a quarter of your budget can be gone before you type, mostly to tools you connected and rules you wrote.
The first thing to set up: ask Claude Code to build you a status bar. Once it's there, the terminal shows your live context use and current model at all times, so you can watch the number climb and never have to run /context to check. My rule of thumb on Opus and its million-token window: keep usage under about a quarter, roughly 250k tokens. Past that, quality drops off fast, so clear well before you get there.
A clean four-part way to think about it, which I picked up from Cole Medin (worth a follow), is write, isolate, select, compress:
- Write. Get things out of the conversation and into files: your plan, your decisions, your notes. A short file you can re-read later beats a long conversation you have to keep alive. Even your saved work history (your git commits, more below) acts as a memory the next session can read to catch up.
- Isolate. Send the heavy, messy reading off to a sub-agent (next section) so its thousands of tokens of research stay in its memory and only the clean summary comes back to yours.
- Select. Load context just in time, not just in case. If you're unsure a file matters to the job in front of you, don't load it.
- Compress, but clearing beats compacting. When a conversation fills up,
/compactsquashes it into a dense summary so you can keep going. Clearing is almost always the better move though: start fresh with/clearand let Claude re-read the one file it needs. The best compression is not needing to compress.
One rule here saves whole afternoons. If you've corrected it twice on the same point and it's still wrong, stop correcting. The window is now full of failed attempts, and every one of them drags the next reply down. Clear it, and start again with a sharper prompt that folds in what you just learned. A clean window with a better ask beats a long one carrying every wrong turn.
Everyday levers that follow:
- Write tight prompts. "Reword the second paragraph of this proposal to sound less pushy" beats "improve this."
- Use cheaper models for the grunt work. Switch with
/model. The smaller models (Sonnet) are less clever but cost less and have huge memory, so use them for reading and donkey-work and save the top model for the hard thinking. You can also dial how hard it thinks with the effort setting, leaving it on auto unless a job clearly needs more. - Lean on CLIs, and prune unused MCPs. Where a CLI exists it's the leaner choice, and any MCP you connected but don't use is costing you on every message, so disconnect it.
- Save checkpoints. Use
git committo save a solid point you can always return to, and/rewindto jump back if a change went wrong. - Name your work. You can name a session and pick it up later, so a job that runs across two days keeps everything it knew instead of starting cold. Treat each named session as its own workstream.
8. Doing more at once: sub-agents and agent teams
Once you're comfortable, you can have Claude Code split work across several helpers at once.
Sub-agents
A sub-agent is a fresh helper Claude Code spins up for one job, with its own clean memory. It does the job and hands back only the answer, so its long, messy working stays out of your main window.
The real reason to reach for them is parallelism: running many jobs at the same time, which is what makes a big task fast. A few use cases earn their keep:
- Parallel research. Say you want the web combed on twenty different questions at once. Spin up twenty sub-agents, one per question, and they all run together. Each reads its pile and hands back a clean summary, so you get the lot in roughly the time a single one would take, and your main session stays lean. (Anthropic's own research put the context saving from this pattern at over 90%.)
- Better decisions, with stochastic consensus. For a judgement call, which positioning, which price, which approach, don't ask once. There's a skill called stochastic consensus that spins up a crowd of independent helpers on the same question and shows you where they land. When a dozen fresh minds, run separately, keep landing on the same answer, you can lean on it with real confidence. A single reply never gives you that. Where they scatter, that's your signal the question is genuinely still open.
- QA and review. The one people underrate. The model that built something is attached to how it built it, so it's a poor judge of its own work. A fresh sub-agent, with none of that history in its window, reads the work cold and catches what the builder glossed over. That missing context is exactly what makes it useful, which is why every serious review should go to a clean agent.
You can also run the same job many times over: ten helpers each sorting a hundred emails in parallel, classifying a thousand in about a minute. The catch: each helper is a little less clever than the main one, and the more you run, the higher the odds one slips. Keep each helper's job simple and let the main session pull the results together. Use sub-agents for research, review, and decisions, never for the building itself, because the builder needs to keep all the context of what it made.
Agent teams
Agent teams are sub-agents that can talk to each other, with a team leader to coordinate them, like a manager and a small crew. They suit big jobs where the pieces need to compare notes. The cost is real: a team can use roughly seven times the tokens of a single session, because every teammate is a whole separate instance. It's an experimental feature you switch on in settings, and it can spend money fast. Set a spend limit before you start one.
One genuinely useful pattern: point a team at an existing codebase to audit it. Ten helpers scan for security holes, two argue back and forth over whether each finding is real, then more fix the confirmed ones. Two helpers arguing usually beats one working alone. The trade is money for time: a job worth weeks of salaried work runs in minutes.
Running more than one at once
You can open several sessions side by side, each in its own terminal, and let them work in parallel. Useful, with two cautions.
The first limit is you. The machine could happily run twenty; you can't think across twenty. Past two or three at once you're flicking between windows, feeling busy while little actually moves. Someone with nine terminals open just looks productive; they aren't getting nine times the work done, and two is plenty for most jobs.
The second snag is collisions. If two sessions edit the same files at the same time, they tread on each other, like two people scribbling on one notepad. The clean fix is a worktree: each session gets its own private copy of the project to work in, and when they're done you have Claude merge them and settle any clashes. You start a session in its own worktree and give it a name. I'd treat it as an advanced move and get comfortable with one session first.
One pairing is worth knowing early though. Have one session build something, then open a fresh one to review it. The reviewer never saw it being built and has no attachment to it, so it reads the work cold and catches what the builder talked itself into. Same fresh-eyes logic as the review helpers from earlier, run in its own window.
9. Working hands-off: loops and routines
So far you've been driving. Now let it work while you're away.
A loop, while your session is open
The /loop command repeats a task on a timer, say every thirty minutes. The catch: your terminal has to stay open. Good for watching something during a work session, like whether a deployment has finished.
Routines, in the cloud, while your laptop is shut
Routines are the big one. They run on Claude's own cloud, so nothing depends on your computer being on. You can trigger them three ways: on a schedule (every morning at 9), on demand through an API call, or on an event in a connected system. There's a daily cap on runs that depends on your plan, so treat routines as a handful of small jobs for one person, not hundreds of automations.
To set one up you connect a place for it to put its work, give it the task in plain English, pick the trigger, and choose the model. A real example: every morning it scrapes the top trending projects in your field, writes them up, adds a short take, and it's sitting in your folder before you wake.
One billing note
Running Claude Code in the background through programmatic calls (the kind a custom dashboard makes) is moving to a separate monthly credit on top of your plan, billed at a higher rate. Routines, run the normal way, still draw on your ordinary plan usage. So routines are the cheap way to automate; a fancy dashboard that fires jobs in the background quietly bills you twice. Get into the habit of asking which way is cheaper before you scale anything up.
10. The bigger gears: workflows and goals
Two newer tools go further than agent teams. A workflow hands the whole plan to a script. A goal keeps Claude working until a condition is true. Both suit bigger jobs. Treat them as advanced and get the basics solid first.
Workflows: the plan lives in code
You describe a job, Claude writes a short script that organises dozens or even hundreds of helpers, and a runtime runs that script in the background while your session stays free. Three things this gives you that agents alone can't: scale (hundreds of helpers, not a handful), something you can rerun (the process is saved as a script you tweak and run again next week), and a built-in quality check (helpers can argue over each other's findings before anything is reported).
One comes built in: type /deep-research with a question. It fans web searches across several angles, fetches and cross-checks the sources, votes on each claim, and hands back a cited report with the shaky claims removed. For a business that lives on research, this is the standout. To write your own, put the word ultracode in your prompt or just say "use a dynamic workflow," and watch progress with /workflows. A workflow spawns a lot of helpers, so test on a small slice first and watch the token count.
Goals: keep working until it's done
A goal sets a finish line and lets Claude keep going until it's crossed. You type /goal and a condition. After every turn, a small fast model checks whether the condition holds; if it doesn't, Claude takes another turn on its own, and the goal clears itself the moment it's met. Use it for bigger jobs with a clear, checkable end state ("reformat every proposal in this folder until all 20 match the new template"). Write the finish line as something Claude's own output can prove, and add a limit like "or stop after 20 turns" so it can't run forever.
Part Two: Build an operating system for your business
Most people use Claude Code like a search bar. A prompt goes in, an answer comes out, and the next morning you sit down and explain who you are and how you work all over again from the top. The work was useful and it still vanished. Nothing built up, and no one else could pick it up.
That's a habit, and habits change. Treat the whole thing as an operating system for your business: a place where your processes live, improve, and stay whether or not you're the one at the keyboard. I posted on this idea before. Here's the fuller build.
1. Map the business first
Open Claude Code and paste something like this:
Interview me about my day-to-day work. Ask questions until it's clear, then map it into domains, with my repeatable tasks listed under each. Output only that map. Build nothing yet.
Then talk. Answer the way you'd explain your job to a new hire who starts Monday and has to be useful by Wednesday. "Build nothing" matters; you want the map in front of you first. Scope it to your seat: an owner maps the whole business, a sales lead maps sales. What comes back is a short tree of a handful of domains, and under each the tasks you genuinely repeat. Every task on that tree is a candidate for a skill.
2. One skill per task, but do it by hand first
Take one task off the map. Before you automate anything, do the whole task with Claude by hand. Have the real conversation. Explain how you do it, what good looks like, where it usually goes wrong, and tell it to keep asking questions until it would hand you something you'd sign off without a single edit.
Almost everyone skips this step, and it's the step that decides whether a skill is any good. I skipped it on my first few skills and every one came out mediocre. You're just doing the work once, properly, and keeping the recipe.
When the output is genuinely good, capture it with /skill-creator. Then tell it to convert every fixed step into a small script, because anything that never varies should run as code (code does the same thing every time and doesn't burn tokens re-deciding a step with one right answer). Test it on real inputs, fix what breaks, run it again. You're done when it's boring. From then on, you type the command, paste your input, and get the same quality every time. When someone joins the team, they type the same command and get the same quality. The standard moved out of your head and into a file.
3. Put the right skills on a schedule
Most skills you run by hand, by name, so you always know exactly what's about to happen. A few belong on a schedule as routines, the unattended jobs that shouldn't wait for you to remember them.
The first routine I'd build: a review of the pipeline for stalled deals. A schedule trigger, 7am every weekday. It reads your CRM through a connector, finds every deal with no activity in two weeks, and drafts a specific nudge for each one. You sit down to a list of drafts to approve, not a blank screen. Keep the send behind your approval: the routine drafts, a person presses send. The same pattern covers a positive reply landing on a campaign. Your inbox tool fires the routine, it checks your calendar and drafts a reply with real times in it, and you approve.
Get one thing right before you schedule anything. A routine that runs in the cloud lives on Claude's servers, so it never touches your own machine. That means it can't reach the files on your computer, the tools you installed, or your skills. Anything that leans on your own setup has to run locally instead, on your machine while it's on. So send the self-contained jobs to the cloud (read this inbox, check this calendar, summarise the web) and keep the ones that need your own library running at home.
4. The memory layer: the part that compounds
This is the layer most people never build, and the one that turns a clever assistant into an operating system.
A chat forgets the moment you close it. A repository remembers. Here's how the memory layer works. Raw input lands in a staging folder: call transcripts, voice notes, the odd PDF. Claude reads it and distils it into short, cross-linked Markdown articles, each with a one-line summary, with anything sensitive left out. An index file lists every page next to its summary. The next session reads that index first and opens only the one or two pages the question actually needs.
That last part is the whole trick, and you've met it twice already: it's the same just-in-time idea behind keeping CLAUDE.md short and referencing side files. Claude keeps a small index in view and pulls in the rest only when a question calls for it, instead of pouring your whole business into one prompt.
This is Andrej Karpathy's "LLM wiki" pattern, which he published in April 2026: a knowledge base the model writes and maintains itself, with no complicated search system behind it, just a plain index file that carries you to a few hundred pages before you need anything cleverer. In my own repository, one 30 KB architecture document became six linked pages, and a later session answered "what is our data policy" from a single index line and a single page. No re-reading the whole thing.
For a sales business the memory layer holds your offer and pricing, the claims you're allowed to make, each client's status and next action, your writing voice, and what worked and what flopped in past campaigns. The next session that drafts a proposal reads the index, opens the offer page and the claims page, and writes from current truth. That's the compounding. Every call you file makes the next proposal sharper.
5. The command centre: Obsidian, and where the dashboard fits
You can run all of this from the bare terminal. But the memory layer is a pile of linked Markdown files, and Markdown has a natural home: Obsidian. It's a free app built for exactly this, a web of linked .md notes you can click through like a private Wikipedia. Drop a terminal panel inside it (there's a plugin) and you've got both at once: Claude Code running in the terminal, and your whole knowledge base, your wiki, your client pages, your notes, sitting right there beside it, browsable and searchable. The folder structure stays clear: raw input in one place, tidy write-ups in another, finished documents in a third, with a short index file at each level so Claude can find things without reading everything. A structure you can explain to a person is one Claude Code can use too.
Now, the dashboard question, because people always ask. You do not need a dashboard to run your operating system; the terminal already fires every skill and routine, and as noted above, a custom dashboard that runs jobs in the background can bill you on a separate, pricier credit while routines run on your normal plan. So don't build one just to have buttons. A dashboard earns its place when you need to see something, a live view of your numbers, or when you need to hand staff a simple interface so they're not typing commands. Visualising data and giving non-technical colleagues a front door are real reasons. "I'd like some buttons" is not. Build the interface when the value is obvious.
6. Keep the whole thing in one repository
Keep all of it in one place, with two layers. Behaviour is how Claude acts: your CLAUDE.md (short, remember) and your skills. Memory is the layer that compounds: the wiki above. Behaviour and memory in one repository, backed up, and you have a business that runs on files instead of on whatever you can hold in your head this week.
Where to start
Don't try to map and automate the whole business this weekend. Pick one task you did this week and will do again next week. Run it with Claude the slow, conversational way. Build the one skill. Run it twice. That's the whole loop, and it's small on purpose. Once you've done it you own a skill that holds its standard, a repository that remembers, and a method you can point at the next task, and the one after that.
Part Three: Agentic engineering (actually building software)
This part is short on purpose, and it opens with a warning, because this is where I watch non-technical people get hurt.
Read this before you build anything to sell
Everyone online tells you anyone can now "vibe code" an app. You'll hear it from people selling courses. It's nowhere near that simple, and least simple for the person being sold the dream: the non-technical owner.
You don't know what you don't know. That's not an insult, it's the whole problem. You can prompt your way to something that looks like it works, demo it once, and have no idea it's riddled with holes, because you don't have the eyes to see them yet. To build software that's safe to put in front of real people, you have to learn the fundamentals. You need to understand git and GitHub (how code is saved and versioned). You need to understand the tech stack, the actual technologies a piece of software is built from, well enough to make decisions about it. And here's a specific trap: whatever tech stack the AI suggests by default is usually a poor choice. It reaches for what's common in its training, not what's right for you. If you can't tell the difference, you'll inherit problems you can't even name.
So here's my line in the sand. For internal tools, go for it. Build the dashboard, the little utility your team uses, the thing that visualises your numbers. If it breaks, you fix it or you bin it, and nobody outside is harmed. But if you want to run something at any real scale, or sell it to anyone, and you don't have two or three months to put aside to genuinely learn software development, don't. A vibe-coded app you sell to strangers is a liability with your name on it. Learn your craft first, or stay out of that game.
Why I call it agentic engineering, not "vibe coding"
I don't like the term "vibe coding," because it describes the wrong thing. Vibe coding means you have no idea what you're doing. You're saying words and hoping. The thing worth learning is agentic engineering: you understand the fundamentals, how software is built, and the workflows, so you can judge and improve what the machine produces instead of just accepting it.
And here's the part nobody selling the dream will tell you: the more you know, the less you find you can vibe code. Every genuinely technical person discovers this. Knowledge doesn't make you reckless with these tools, it makes you careful, because you can finally see what can go wrong. So no, I'm not in the "anyone can just build it" camp. Anyone can produce something. Producing something that works, holds up, and is safe to sell is a different sport.
How to actually do it: the PIV loop
If you're going to build, do it properly. The cleanest method I've seen is Cole Medin's, and I'd watch his two videos before you start: his framework for working on real codebases without your context rotting (here) and his dead-simple build framework (here).
The core of it is the PIV loop: plan, implement, validate. You run every chunk of work through these three stages.
Plan. Don't start in code. Have a loose conversation with Claude about what you're building, let sub-agents go off and research the approach, then have it ask you a flurry of clarifying questions. Every question you answer removes an assumption it would otherwise have guessed wrong. When you're aligned, have it write the plan down as a structured document, including, and this is the bit people skip, exactly how the result will be checked before a line is written. One bad line in the plan becomes a thousand bad lines of code, so this is where your attention belongs.
Implement. Now reset the context. Open a fresh session and feed it only that plan, because the plan holds everything it needs and nothing it doesn't. Then let it build. This is the part you delegate fully. It's not reckless, because you've sandwiched the building between a planning stage and a validation stage you control.
Validate. This is where the double-checking earns its keep, and where I do something specific. The model that wrote the code is biased toward its own work; it likes what it made. So I don't let it be the only judge. I get a fresh sub-agent, with no memory of the build, to run QA on it cold. Then I bring in Codex, OpenAI's coding tool, as a second, independent reviewer. The point isn't that Codex is better. It's that it's different. A different model thinks differently and trips over different bugs, so between the sub-agent and Codex you catch things either one alone would miss. Everything gets seen by more than one set of eyes, and at least one of those sets had no hand in building it. Only when it's passed both do I commit.
One reason to take validation this seriously: errors compound. If each step is 90% reliable, three steps chained without a check is only about 73% reliable. The more you let it run unchecked, the worse the odds at the end. The human, and the independent reviewer, are how you keep the odds high.
One caution on all this reviewing. A reviewer told to find problems will always find some, even when the work is sound, because that's the job you handed it. Fix the ones that affect whether the thing actually works, and let the rest go. Chase every note and you end up with over-built, over-defended code you never needed.
A note on building front ends, fast
When you do build, the quickest way to a good-looking result is to hand it a design. Find a page whose look you like, take a full-page screenshot, give it over, and let it rebuild from that, comparing screenshots until it matches. You skip every decision about fonts and spacing and just swap in your own words. Talking the spec out with a voice-to-text tool is faster than typing, and ready-made building blocks (sites like 21st.dev) drop polished pieces straight in. To put it live, services like Netlify or Vercel handle it and Claude Code will walk you through the few clicks. Use a web address that isn't short or obvious, because scanners crawl the internet constantly looking for easy targets.
The safety line, said plainly
Build internal tools and client pages freely. Be careful before you put a fully AI-built app on the public internet and run real customer data or payments through it. A few things will genuinely bite you, and they're cheap to get right: never let secrets (passwords, API keys) sit in your code or get saved to GitHub, keep them in one separate .env file Claude is told never to read or commit; never store credit-card numbers yourself, let a service like Stripe handle that; and if your app has a database, make sure its access rules are switched on, because several have defaulted to open and leaked everything. If you're going to charge money or store logins, pay a developer a few hundred pounds to check the security once, and have a fresh Claude session run a security audit before that. The sweet spot for most owners stays where Part Two put it: tools you use inside your team, and pages you send to clients.
Getting started
A 30-day path to find your feet
Week 1, the basics (Part One). Install it. Run it in the terminal inside an IDE so you get the full power and still see your files. Run /init on a folder to make your first CLAUDE.md, then trim it toward 100 clear lines. Practise plan mode on anything that takes thought. Get used to /clear between jobs, and watch /context to feel where the tokens go.
Week 2, your first skill. Build one real skill for a job you do every week, using the skill-creator. Do the task by hand with Claude first. Connect one tool you use daily through its CLI, not an MCP.
Week 3, the operating system (Part Two). Start the memory layer: a staging folder, an index file, and a habit of filing call notes and decisions. Put one routine on a morning schedule. Use sub-agents for research and review. Use git commit as a save point before big changes.
Week 4, build something, carefully (Part Three). Build one internal tool your team will actually use, planning it with the PIV loop. If you're tempted to build something to sell, reread the warning. Turn two more repeatable jobs into skills. By now you've stopped learning the tool and started using it.
Two reminders to carry throughout. On mindset: ask it to explain anything you don't follow, and decide for yourself what's worth building. On safety: keep each project in its own folder, save checkpoints, keep secrets in one file, and get a developer to check anything that touches real customer data or payments before it goes public.
Power moves worth knowing exist
Don't start here. Just know these are waiting once the basics are second nature.
- Few-shot prompting. Show examples, don't just describe. For a web page, hand it a screenshot and the underlying code of a site you like. The more concrete examples, the closer the result.
- Don't run a monoculture. When everyone leans on one model and it has a bad hour, everyone's productivity drops at once. Keep Codex installed and know how to use it, so an outage or a degraded day doesn't stop you. That diversity is also why it's your best validator.
- Hooks. Small actions that fire automatically before or after a task. My favourite is a sound when a job finishes, so you can look away and get pulled back when it's done.
- Custom commands. Your own shortcuts. A
/your-commandthat runs a whole daily workflow, calling other skills in sequence. - Remote control. Drive a live Claude Code session from your phone, handy for checking a long job while you're away from the desk.
- Frameworks. Add-on layers that change how Claude Code plans and works. Some are clever, but the base tool keeps absorbing their best ideas, so hold off at the start. Less is more, and use nothing you don't understand.
- Staying current. This tool changes weekly. Point Claude Code at the trending projects on GitHub, or ask it to summarise the last month of discussion from heavy users, and let it tell you what's new.
- Cloud planning. A beefed-up plan mode that runs in the cloud and seems to put several helpers on the plan at once. You get a cleaner page to read, comment on, and tweak before you approve it. Worth it for a big plan you want to think hard about.
- Offload the heavy reading. For research-heavy work, a tool like Notebook LM does the reading on Google's servers and hands back the distilled answer, so it barely touches your own token budget. A lifesaver if you keep hitting usage limits.
The bottom line
The skill here was always knowing what's worth building, and judging whether what comes back is any good. You supply that. The machine supplies the hands.
The owners who win with this took the repeatable work in their business, the proposals, the lead lists, the onboarding, the inbox, the reports, and turned it into commands that run in seconds, often while they sleep. It has little to do with being technical. You're trading a small monthly fee, and some tokens, for hours of your week back.
You can start today. Install it, point it at one folder, and give it one real job from your business. That first command is the whole distance from knowing nothing to being on your way.
This is just the start
Everything here is the beginning, not the destination. I've handed you the map, but this tool moves so fast that half of what feels cutting-edge today will be baked into it by the time you're comfortable. So treat the guide as day one, and carry four habits with you.
Stay curious. When something doesn't make sense, that's exactly the thing to dig into. Curiosity is most of the job now.
Do the reading. The answers are all out there, and Claude Code will fetch most of them if you ask it to. Point it at the documentation, the trending repos, the threads where the heavy users pull each other apart.
Watch the videos. The people pushing this hardest put out what they learn on YouTube every week, for free. An hour of watching saves you a month of guessing.
And ask Claude when you're lost. The worst way to use this is to click accept, accept, accept like a yes monkey and learn nothing. When it reaches for a tool you've never heard of, or makes a call you don't follow, stop and ask it why. It will explain, patiently, for as long as you need. That back-and-forth is how you actually get good, and it's the one part no guide can do for you.
If you'd rather talk it through than read another guide, this is the work we do: building the operating system, the skills, and the custom agentic software that runs the repeatable parts of a sales function. The strategy call is half an hour and free, and we can work out where this actually moves a number in your business.