A chat is not a working system.

Why the chat window is the wrong unit of work

A conversation starts at zero. Every time. It does not know who your client is, how you write, what you agreed last week, or why you threw out the previous proposal. You are the memory of the system, which means every new tab charges you the same toll: retelling the whole context before you can ask for anything useful.

Chat is a good interface for a one-off question. It is a terrible unit for work that repeats, and an independent professional's work is almost entirely work that repeats. Audits with the same structure. Monthly reports in the same format. Proposals where the client name changes and 30% of the content changes with it. Follow-up emails you have already written forty times. If each of those starts from a blank conversation, you are rebuilding the same scaffolding every single day.

What replaces the chat is not a longer prompt. It is three things that already exist and that most people never use: Projects, which hold persistent context and apply it to every conversation inside them; context files, which state once and for all how you work; and Skills, folders with a SKILL.md that Claude loads on its own when the task calls for it. With those in place, the conversation stops being the container for your work and becomes what it should have been all along: the surface where you run something that is already built.

The context tax is the real cost

When people add up what AI costs them, they look at the subscription or the price per million tokens. Neither one is the big expense. The big expense is the minutes you spend every day explaining the same thing again: who the client is, what tone they use, what cannot be said, what the quarter's goal is, how you want the deliverable. Five minutes of preamble per conversation, six conversations a day, and you have spent half an hour writing text that is nearly identical to yesterday's.

You kill that tax by writing it once. Not in your head, not in a loose note: in a file, with structure, living where Claude will actually read it.

The first one is the client brief. One page, not ten. What the company does, who it sells to, how it speaks and how it does not, who decides, what was tried before and failed, which metrics genuinely matter, what is off limits. The test for whether it is written well is simple: if you hand it to a new collaborator and they can draft something defensible without calling you, it works. If they have to call you, it is missing context.

The second is an operating file, your personal equivalent of a CLAUDE.md: how you work, not how the client works. What format you want deliverables in, what annoys you about a generic answer, what level of detail you expect, when you would rather be asked than have something assumed, which words you never use. This file is boring to write and it pays the most, because it applies across every client at once.

The third is one Skill per repeated task. A Skill is a folder with a SKILL.md inside, and its mechanics matter: the Skill's description is always present in context, but the full file is only read when the task calls for it. That is progressive disclosure, and it has a practical consequence almost nobody accounts for. The description is not a decorative label, it is the trigger. Write it as a condition of use, not as a title. "Ad account audit" is a title. "Use when a Meta Ads or Google Ads account needs reviewing and the output is a diagnosis with prioritized recommendations" is a trigger.

One Project per client, not one Project per tool

The most common organizing mistake is grouping by task type: a Project for "writing", one for "analysis", one for "emails". It feels tidy and it is useless, because what changes between one job and the next is not the verb, it is the client. The context you need to write an email for Client A is far closer to the context you need to analyze their data than to the context you need to write an email for Client B.

One Project per client, brief inside, with the generic Skills living separately because they cut across all of them. Then add one more Project: your own. Your business, your pipeline, your bookkeeping, your proposals. It is the one you will abandon first and the only one whose client will never chase you, so put a recurring review on the calendar.

Choose the model per task, not out of habit

Almost everyone picks a model once and uses it for everything for months. It is comfortable and it is expensive in both directions: you overpay on the trivial work and you come up short on the hard work. The right call is made per task, and there are four options.

The working rule fits in one sentence: if the task repeats a lot and thinks a little, Haiku; if it is your normal work, Sonnet; if the problem is hard, Opus; if Opus genuinely stalls, Fable. The three large models carry a 1M-token window, which in practice means you can drop a client's entire history into a single session instead of slicing it up.

What to delegate and what never to delegate

This part gets told badly almost every time, and it is worth being honest because your business depends on getting it right. You delegate production: first drafts, meeting summaries, pulling data out of PDFs and screenshots, comparing two versions of a document, translating a deliverable, turning loose notes into a structure, generating the five variants you are then going to throw away. All of that is volume, and volume is exactly where an independent professional drowns.

Three things you do not delegate, and not out of moral caution but because it does not work.

Judgment. Deciding that this client needs to cut budget rather than expand reach is a call made with information that lives in no file: how the finance director breathed on the last call, what happened at the company last year, what can be defended internally. Use Claude to structure the decision and to attack it from the opposite side. The decision stays yours.

The relationship. Your client does not pay you for documents, they pay you because they trust you. A hard email, bad news, a scope renegotiation: draft it with help if you want, but the conversation is yours. The day a client notices that a system is answering them, you stopped being an advisor and became a replaceable vendor.

Final accountability. You sign it. If the number is wrong, the mistake is yours. That has a concrete operational consequence: every figure, quote, or legal claim going out under your name gets verified against the source before it ships. No exceptions, no matter how convincing it sounded.

The first week, in order

Five steps, one per day, each with an outcome you can verify. If you cannot verify it, you have not done it.

1. Write your operating file. One page on how you work: format, tone, level of detail, when to ask instead of assume. Verify: ask for a deliverable with no formatting instructions and it comes back in your format.
2. Create a Project for your main client and put the brief in it. Verify: open a fresh conversation inside the Project, ask for a draft, and never once explain who the client is.
3. Turn your most repeated task into a Skill. Pick the one you did most last month. Write the description as a condition of use, not as a title. Verify: in a new conversation, describe the job in your ordinary words and the Skill fires on its own, without you naming it.
4. Assign a model to your five habitual tasks. Write it into the operating file. Verify: you can say out loud which model you use for each one and why, without hesitating.
5. Connect exactly one data source. One, the one you open most, via MCP, the open standard that connects Claude to external tools such as Drive, GitHub or your database. Verify: ask a question about a real document and get an answer without having copied and pasted anything.

Five days, five verifiable outcomes. None of them requires programming. By the end of the week you have something you did not have on Monday: a system that survives you closing the tab.

The three ways to ruin it

Over-prompting. The first and the most common. People write seven-hundred-word prompts stuffed with "act as a senior expert with twenty years of experience", contradictory instructions, and warnings against mistakes the model was never going to make. The output gets worse, because conflicting instructions produce lukewarm answers that try to satisfy everything at once. If your prompt needs seven hundred words every time, that was not a prompt: it was context, and context belongs in a file. Prompts get shorter as the system gets better, not longer.

Treating output as finished work. What comes out is a competent draft, not a deliverable. The trap is that drafts now arrive so polished that they look final, and that polish switches off your reviewer instinct. Put an explicit step between generating and sending: read it, verify the data, cut what is padding, add the one thing only you know and that was in no file. That step is what you are charging for.

Building infrastructure for nothing. A Skill for something you do twice a year does not save time, it spends it, and it rots on top of that: by the second time it will be out of date and you will trust it anyway. The honest threshold is weekly. If you do not do it at least once a week, do it by hand and get on with your life. Building systems beats collecting tricks, but building systems nobody uses is just procrastination with better production values.

The only metric that matters

It is not how many Skills you have or how many Projects you opened. It is how much time passes between receiving a job and delivering something defensible, and whether that time drops month over month. If it drops, the system works. If it does not drop but you have twelve Skills, you built a museum. Start with the most boring thing, measure the time, and keep only what earns its space.