The Micro-Consulting Playbook

Small Enough to Say Yes To

This is a book about small work. Not small in ambition, small in shape: an engagement with a fixed scope, a short calendar and one deliverable a client can point at when it is finished. A paid audit of how a team uses AI. A fix for one painful workflow. A kit of tested prompts. A two-week agent pilot. A half-day training session. A documentation sprint that turns tribal knowledge into something a model and a new hire can both read. Each one is easy to buy, quick to deliver with Claude, and designed to lead to the next.

Why small? Because the hardest part of consulting has never been the work. It is the yes. A large engagement asks a buyer to commit budget they have not got, to a person they have not tested, for an outcome they cannot yet picture. A small one asks them to risk a little money on a specific result by a specific date. The first conversation goes to committee. The second goes to a card payment, or at worst to a manager who can sign without a meeting.

There is a second reason, and it is the one that makes this the right moment. Agentic tools have collapsed the effort behind a large class of useful work. What once took a consultant three weeks of reading, drafting and building now takes a few focused days with Claude doing the reading, drafting and much of the building. If you sell that work by the hour, the tooling makes you poorer. If you sell it as a fixed outcome, the tooling makes you a business. The micro-engagement is simply the commercial shape that fits the new economics.

A small yes is still a yes. It is also the only kind a stranger can give you.

The book is built on a hundred moves, grouped into ten parts. The early parts cover the offer itself and the craft you will use to deliver it: how to brief a model, how to feed it context, how to work in a repository with Claude Code, how to encode repeatable work as skills. The middle covers shipping, delivery and the shape of a price, without ever naming a number, because your numbers depend on your market and nobody else's. The last parts cover proof, pipeline and where this is all heading. Every chapter is either a move you can make this week or a micro-engagement you can run, and most chapters end with a nudge to try it.

One warning before we begin. Small engagements are not a lesser form of consulting. They are harder to do well, because there is nowhere to hide. A twelve-month programme can absorb a bad fortnight. A two-week sprint cannot. You will need to scope tightly, deliver visibly and measure honestly. In exchange you get faster feedback, happier clients and a pipeline that refills itself. The trick, it turns out, is not to sell more. It is to sell less, sooner, and then do it again.

Sell Outcomes, Not Hours

Hourly billing has one quiet flaw that becomes a loud one the moment you start working with Claude: it punishes you for getting faster. Every hour the tooling saves you is an hour you cannot invoice. Become twice as quick and, on a day rate, you have halved your income for the same result. Nobody designs a business that way on purpose. Plenty of consultants drift into it by default.

The alternative is to price the outcome. The client is not buying your attendance; they are buying an audited workflow, a working pilot, a trained team, a set of prompts that produce compliant copy on the first attempt. Describe that thing precisely, put one price against it, and agree a date. How long it takes you is now your business, not theirs. When Claude does in an afternoon what used to take a week, the efficiency is yours to keep, and it funds the next improvement in your method.

This also changes the conversation with the buyer, mostly for the better. A day rate invites haggling over inputs: why does this need five days, could it be four, who is on the team. A fixed outcome invites a discussion about value: what is this worth to you, what happens if it works, what does done look like. The second conversation is more useful to both parties and much less exhausting. It also forces you to define done, which, as later chapters will argue, is the single most valuable habit in this kind of work.

It is worth saying plainly what you are refusing. Staff augmentation, renting yourself out by the day to sit inside someone else's team, is a perfectly respectable job. It is just not micro-consulting. It makes you a contractor with extra steps, paid for presence rather than results, and it scales exactly as far as your calendar. The micro-consultant's deliverable is a system, a document, a capability or a decision. Your attendance is incidental.

Bill for the hole, not the drill. Especially now the drill is doing most of the work.

There are honest risks. A fixed outcome means you carry the overrun if you scoped badly, and some work genuinely cannot be bounded in advance. The answer is not to retreat to hourly rates. It is to scope smaller. If you cannot describe the outcome with confidence, sell a paid discovery that produces the description, then price the outcome once you can see it. Uncertainty is a reason to shrink the first engagement, never a reason to unfix it.

Try this on your current offer. Rewrite every line item that mentions days or hours as a noun the client will own at the end. Five days of AI consulting becomes a ranked list of the six workflows worth automating, with a working prototype of the first. It reads better, it sells better, and it quietly commits you to something you can actually be proud of. Your hours were never the product. They were just the only thing you knew how to count.

The Diagnostic Call

The first call with a prospective client is not a pitch. It is a diagnosis. Most consultants waste it by explaining what they do, which the buyer could have read on the website, instead of finding out what is wrong, which the buyer may not fully know themselves. The expensive problem rarely arrives in the first sentence. It arrives around question twelve, after you have stopped talking.

Go in with a list. Twenty questions is a good number, though you will not ask them all. Start with the work, not the technology: walk me through the last time this went wrong, who touched it, how long did it take, what did it cost, what did you do instead. Then move to the edges: what have you already tried, who would need to approve a change, what happens if nothing changes this quarter. Only at the end ask about tools, and even then ask what they use rather than what they want. People describe their aspirations in terms of software. They describe their problems in terms of Tuesdays.

Claude is useful on both sides of the call. Before it, paste in what you know about the business, their public material and the sector, and ask for a tailored question list ranked by how likely each is to surface a costly problem. After it, paste in your notes or a transcript, with permission, and ask for a structured summary: the presenting problem, the underlying problem, who owns it, what it costs, and which micro-engagement would address it. That summary becomes the first page of your proposal and, more usefully, the thing you send back the same afternoon so the buyer can correct it.

The correction matters. A buyer who edits your summary of their problem has started co-writing the proposal. They now own part of the diagnosis, and people rarely reject diagnoses they helped write. Keep the summary short, a single page, in their language rather than yours. If you find yourself writing leverage or synergy, ask Claude to rewrite it in the vocabulary the buyer used on the call.

Pitching on a first call is like prescribing before the patient sits down.

There is an art to ending the call, too. Do not close by offering a proposal. Close by naming the problem back to them, in one sentence, and asking whether you have it right. If they say yes, tell them what a small first step would look like and when you can send it. If they say no, you have just learned something far more valuable than a sale, and the call is not over.

Try it this week. Write your twenty questions, ordered from work to edges to tools, and keep them in a note you can open on any call. Then run your next conversation without describing your services until the last five minutes. You will talk less, learn more and quote on the right problem. The buyer will remember you as the person who listened, which in this market is a surprisingly rare distinction.

The Paid Audit

The fixed-scope AI audit is the best front door a micro-consultant can build. It is low risk for the buyer, fully paid for you, short enough to finish before anyone loses interest, and it ends with a roadmap that you are uniquely positioned to deliver. It is a sale that manufactures the next sale, provided you run it properly.

The shape is simple. Over a week or two you interview a handful of people, observe how work actually flows, review the tools and data in play, and produce a ranked list of opportunities. Each opportunity gets a short description, an honest estimate of value, an estimate of effort, a note on risk, and a recommended micro-engagement to address it. The top two or three are scoped tightly enough to be bought straight off the page. The rest are parked, visibly, so the client sees you are not simply selling everything you found.

Claude makes the audit faster without making it shallower. Interview transcripts go in, with consent, and come out as themes, quotes and repeated complaints. Process descriptions turn into simple flow diagrams you can check with the people who described them. A spreadsheet of tasks can be scored against a rubric you write together with the client. The synthesis that used to take days of rereading notes becomes an hour of reviewing and correcting what the model drafted. Your time goes where it should: on judgement about which opportunities are real.

Be strict about what the audit is not. It is not free, because free audits are treated as samples and their recommendations as opinions. It is not a strategy deck, because nobody in a small business acts on strategy decks. And it is not open-ended. Fix the number of interviews, the number of opportunities you will rank, and the date of the readout. When the client asks you to look at one more department, smile and add it to the list of things the next engagement could cover.

An audit that does not end in a decision is just an expensive way to feel modern.

The readout is where the audit earns its keep. Present the ranked list live, explain the top three, and show a rough prototype of the first if you can, even a single artifact built the night before. Then ask which one they want to start with. Not whether. Which. The audit has done its job if the buyer leaves the meeting choosing between your next engagements rather than wondering whether to have one.

To build your own, write the deliverable first. Draft a sample audit report for an imaginary client in your sector: the ranked table, the three scoped recommendations, the parked list. Then work backwards to the interviews and reviews you would need to fill it honestly. You now have a product, a template, and a fairly good idea of what you are selling. Most consultants describe their audit. Very few have one they could show.

The Two-Week Sprint

If the audit is the front door, the sprint is the first room. Two weeks, one problem, one working result. It is long enough to ship something real and short enough that nobody needs board approval, a procurement process or a steering committee. Most importantly, it is short enough that momentum survives. Long engagements do not usually fail from bad work. They fail from fading attention.

Two weeks has a natural rhythm. Day one is access and kick-off: credentials, a named decision-maker, a written definition of done. The first week is building, in small increments, with a demo at the end of it. The second week is refining, testing against real cases and preparing the handover: the runbook, the prompts, a short recorded walkthrough, a session with the person who will own it. On the last day you demo the finished thing, show the measured change, and propose what comes next.

With Claude as your delivery partner, two weeks holds a surprising amount. A workflow automation that reads incoming documents, extracts what matters and drafts a response for a human to approve. A small internal tool built as a single-file prototype and then hardened. A skill library for a team's recurring writing tasks. An agent pilot running against a sample of last month's real work. None of these are trivial, but all of them fit, provided the scope is one problem and not three.

That proviso is the whole discipline. The sprint lives or dies on the definition of done you write on day one. Make it specific, checkable and in the client's words: the team can process a week of supplier invoices with the assistant, and nine out of ten drafts need no more than light edits. Avoid adjectives like robust or seamless, which describe how you feel rather than what you can test. If you cannot write a definition of done in two sentences, the sprint is too big. Split it.

Two weeks is not a deadline. It is a container, and containers are what keep things from spreading.

There will be pressure to stretch. A client sees early progress and asks whether you could also handle a related process. The answer is yes, in the next sprint. Write it down, put it on the list for the closing demo, and keep going. A sprint that finishes on time with a smaller scope builds more trust than one that finishes late with everything in it.

Try sketching three sprints you could sell tomorrow. For each, write the problem in one line, the definition of done in two, and the handover pack in three. If any of them needs more than that, it is a programme pretending to be a sprint. Shrink it until it fits on a card. Small, finished and demonstrated beats large, nearly done and explained, every single time.

Name the Thing

An unnamed service is a favour. A named one is a product with a price. This sounds like marketing whimsy, and partly it is, but it rests on a practical truth about how buyers think. People file things by name. A bit of help with our AI stuff goes in the mental drawer marked miscellaneous, which is also where budget goes to die. The Inbox Triage Sprint goes in a drawer of its own, beside other things that cost money and produce results.

A name does three jobs at once. It tells the buyer what they are getting before you explain it. It lets them repeat it to someone else, which is how referrals travel. And it constrains you, because once the engagement has a name it has a shape, and shapes resist the kind of slow sprawl that turns a fixed-scope job into an open-ended one. The Prompt Kit for Customer Support cannot quietly become a CRM migration. The name would object.

Good names are plain. They say what the thing does, for whom, and sometimes how long it takes. The AI Readiness Audit. The Two-Week Agent Pilot. The Policy Documentation Sprint. The Team Claude Workshop. Clever names that need explaining defeat the purpose. If you have to describe the name before you can describe the service, you have built a second problem. Leave the wordplay for your blog posts.

Claude is quite good at this, if you brief it properly. Give it the problem the engagement solves, the buyer it is for, the deliverable, the duration and three names you already dislike, and ask for twenty plain options ranked by clarity. Then say the best five out loud to someone who does not work in your field. The one they can repeat back to you an hour later is the winner. Memorability is a test, not a vibe.

If they cannot say it to their boss, they cannot buy it from you.

Once a thing is named, give it a page. One page, with the problem, the deliverable, the timeline, what the client provides, what you provide, and what typically happens next. Do not put a price on the page if your market prefers a conversation, but do make clear that a price exists and is fixed. That page becomes the link you send after a diagnostic call, the attachment to a proposal and the thing a buyer forwards to the person who signs. It does more selling than you do.

Look at your last three engagements this week. Give each one a name, as if you had sold it as a product. Then notice which you would be happy to sell again exactly as described, and which you would want to change. The ones you would sell again are your catalogue. The rest were favours, which is fine, but you should stop pretending they were strategy.

One Vertical, Deep

Generalists compete with everyone. Specialists compete with almost no one. This is old advice, older than any of the tools in this book, but it matters more for micro-consulting than for most kinds of work, because small engagements live or die on how quickly you can scope them. A consultant who already knows a sector arrives with the scoping half done.

Consider the difference on a diagnostic call. A generalist asks a dental practice how appointments are booked and spends twenty minutes learning the vocabulary. A specialist already knows the booking software they probably use, the regulations that govern patient records, the three tasks that eat the receptionist's afternoon and the reasons previous automation attempts tend to fail. The specialist's first question is the generalist's fifteenth. That head start becomes a sharper proposal, a faster sprint and a client who feels understood rather than interviewed.

Specialising also sharpens your craft with Claude. Every engagement in the same sector teaches you something reusable: a prompt that handles the jargon, a skill that knows the compliance rules, a seed dataset that looks like real records, a checklist of the questions that matter. After five engagements you have a library tuned to one kind of client, and the sixth engagement starts from that library instead of from a blank page. Your margins improve, your quality improves, and your proposals start to read like they were written by someone who has done this before. Because they were.

Choosing a vertical is less mystical than people make it. Look for a sector where you already understand the work, where businesses are small enough to buy without committees, and where documents, messages and repetitive decisions make up a large share of the day. That last test matters, because it is where language models earn their keep. Legal practices, estate agents, accountancy firms, charities, clinics, trades businesses and small publishers all fit. Pick one you can tolerate talking about for years.

The riches are in the niches, as the saying goes. So, more reliably, is the repeat work.

The fear is that specialising shrinks the market. In practice it does the opposite, because a specialist becomes the obvious call, and obvious calls get referrals from inside the sector, where people talk to one another constantly. You can always take the occasional interesting job outside your lane. You simply stop needing to.

Try this as an exercise rather than a commitment. Pick one sector and spend an hour with Claude building a briefing on it: the typical business, its software, its regulations, its recurring pain, its vocabulary. Then write three named micro-engagements for that sector alone. If they come easily, you may have found your lane. If they feel forced, try another. The point is not to find the perfect niche. It is to stop being a little bit useful to everyone.

Productise the Repeatable

The third time you build the same thing, it stops being a project and becomes a product. The first time, you were learning. The second time, you were remembering. The third time, if you are still starting from a blank page, you are simply refusing to notice a pattern. Micro-consulting rewards the people who notice.

Productising does not mean building software. It means turning a repeated engagement into a repeatable one: a fixed description, a standard set of inputs, a template deliverable, a library of prompts and skills that do most of the heavy lifting, and a checklist that tells you what to do on each day of the sprint. The client buys the same named outcome. You deliver it with a fraction of the original effort, at the same price, and with better quality because every previous engagement has sanded down a rough edge.

Claude is the reason this is now realistic for a solo practitioner. In the old world, productising a consulting service meant hiring juniors and writing procedure manuals they would ignore. Now the procedure manual can be a skill that loads itself when relevant, the templates can be generated from structured inputs, and the repetitive analysis can be run by an agent following instructions you wrote once and refined over many runs. The juniors, in other words, are the tooling, and the tooling actually reads the manual.

The trick is to productise from evidence rather than from hope. Do not invent a product and then go looking for clients who want it. Look back at what clients have already paid for, find the engagement you have delivered most often, and write down what you did, step by step, while it is fresh. That write-up is the first draft of the product. Each subsequent delivery refines it. Within a handful of runs you have something you could, in principle, hand to a capable colleague.

A process you can describe is a process you can improve. A process you can only perform is just a habit with an invoice.

Watch for one trap. Productised services can become rigid, and rigid services start fitting clients badly. Keep a small, explicit space for tailoring in every engagement, perhaps a day of bespoke work inside a fixed frame, and be honest when a client's problem does not fit the product. Recommending something else, or nothing at all, builds more trust than forcing a square engagement into a round business.

This week, find your most repeated engagement and write its playbook: inputs, steps, prompts, outputs, checks, handover. Store the prompts and templates where you will find them in ten seconds next time. Then sell it again. The fourth delivery will be faster than the third, and the fifth faster still. That curve is the whole business case for small work, quietly bending in your favour.

Pilot to Retainer

A pilot that ends cleanly with nothing left to maintain is a pilot you designed wrong. That is not cynicism about clients. It is a recognition that useful AI systems need looking after: prompts drift as the business changes, models improve and open new options, new edge cases appear, and someone has to notice when quality slips. If the pilot proves value, the natural next step is ongoing care. Design for that from the start.

The design work happens before you write a line of code. When you scope a pilot, ask what will need to happen after it succeeds. Who will monitor the outputs? Who will update the prompts when the product range changes? Who will review the evaluation set each month and add new cases? Who will try the improved model when it arrives? In most small businesses the honest answer is nobody, and that answer is the retainer, offered openly, not sprung as a surprise at the end.

Be explicit about this in the proposal. Describe the pilot, its definition of done and its measured outcome. Then describe, in a short paragraph, what keeping it healthy would involve and what a monthly arrangement would cover. You are not selling the retainer yet. You are making sure that when the pilot succeeds, nobody is surprised that success needs maintaining. Buyers appreciate being told the whole shape of the commitment early.

The retainer itself should be small and specific, like everything else in this book. A monthly review of a sample of outputs against the evaluation set. Prompt and skill updates as needed. A short written report showing what the system did, what changed and what you recommend. A fixed number of small improvements per month. A response window for problems. Avoid the vague retainer that promises ongoing support, because vague retainers get cancelled at the first budget review, when nobody can remember what they were for.

Pilots prove something works once. Retainers prove it keeps working, which is the part the buyer actually needed.

Not every pilot should become a retainer. Some systems are simple enough that a good runbook and a trained champion are all the client needs, and recommending that is honest and occasionally excellent for referrals. But you should decide that deliberately, at the end, based on what the system needs, not drift into it because you never thought about what came after.

Try it on your next proposal. Add a section called after the pilot with three sentences: what the system will need, who could provide it, and what a small monthly arrangement would include. Notice how it changes the conversation. The buyer starts thinking about the pilot as the beginning of something, rather than as an experiment they might quietly abandon. Which, for most AI pilots in most businesses, is exactly what happens otherwise.

The Offer Ladder

Put the previous chapters together and you get a ladder. At the bottom, something free and small: a teardown, a tool, a useful article, a short diagnostic call. Above it, the paid audit, which finds the problem. Above that, the build sprint, which fixes it. At the top, the monthly retainer, which keeps it fixed and improves it. Every client enters low and climbs, and you never have to invent a proposal from scratch again.

The ladder solves a problem most consultants do not notice they have: every sale is a custom negotiation. Without a ladder, each prospect gets a bespoke proposal, each proposal takes a day to write, and each one is a fresh guess at what the buyer might accept. With a ladder, the question is simply which rung they should start on. A buyer who already knows their problem can skip the audit. A cautious one can start with a teardown. The structure is fixed; the entry point flexes.

Each rung should make the next one feel inevitable. The teardown ends by showing what a proper audit would find. The audit ends with a ranked list whose top item is a scoped sprint. The sprint ends with a working system and a clear description of what keeping it healthy involves. Nothing about this is manipulative, provided each rung is genuinely valuable on its own. A client who stops at the audit should still feel they got their money's worth. Most will not stop, because they have seen what the next step looks like.

Your catalogue of micro-engagements slots into the ladder neatly. Training sessions and prompt kits often sit beside the audit as small, low-risk first purchases. Workflow fixes, documentation sprints and agent pilots are build sprints. Monitoring, evaluation reviews and continuous improvement are retainer work. Map each named offer to a rung and you can see, at a glance, where your gaps are. Many consultants discover they have five ways to start and no way to continue.

A ladder is just a sequence of small yeses arranged so that each makes the next one easier.

Draw yours this week. Four rungs, named offers on each, and a single sentence explaining how each rung leads to the next. Then look at your last ten clients and mark where each one entered and where they stopped. The places where clients stop climbing are where your offers are weakest, or where the bridge from one rung to the next has not been built. Fix the bridge before you add more rungs.

This is the shape the rest of the book fills in. The craft parts teach you to deliver each rung quickly with Claude. The delivery and pricing parts teach you to run each rung cleanly. The proof parts teach you to turn each finished rung into the reason for the next one. The ladder is not the strategy. It is the frame that lets small work add up to something large.

Brief Like a Client

Every consultant knows what a bad client brief looks like. We need something modern for our website. You will know it when you see it. Then most consultants turn round and write exactly that brief to a model. Write me a proposal for this client. The model, like the junior designer before it, is not psychic. It fills the gaps with averages, and averages are what you get back.

The fix is to brief Claude the way you wish clients would brief you. Four parts are enough. Context: who the work is for, what situation they are in, what has already been tried. Task: the single thing you want done, stated as a verb. Format: what shape the answer should arrive in, from length to structure to tone. Check: how you, and the model, will know the result is good. That last part is the one almost everyone leaves out, and it is the one that changes the output most.

Here is the difference in practice. Draft a follow-up email after a diagnostic call is a wish. Now try this: Context: I run fixed-scope AI engagements for small accountancy firms. Yesterday I spoke to a two-partner practice whose month-end close is slowed by manual reconciliation notes. Task: draft a follow-up email that summarises their problem in their words and proposes a paid audit as a first step. Format: under two hundred words, plain UK English, no bullet points, one clear question at the end. Check: a partner should be able to read it in under a minute and reply with a yes or a correction. The second version takes ninety seconds longer to write and produces something you might actually send.

The deeper habit is fluency: learning to replace ten clarifying turns with one dense, unambiguous brief. Early on you will brief thinly and correct often, which is fine. Over time, notice which corrections you keep making and move them into the brief. Shorter, less formal, stop using the word leverage, include a next step. Those are not edits. They are missing parts of the brief, arriving late.

A one-shot brief is slower to write and dramatically faster to finish.

This matters more for consultants than for most users, because your briefs are often the deliverable. The prompt you hand a client's support team, the instructions inside a skill, the system prompt for an agent pilot: each of these is a brief that someone else will rely on without you in the room. If you cannot brief a model well in your own work, you cannot teach a client's team to do it, and you certainly cannot sell them a prompt kit.

Try it today on a task you repeat. Write the four-part brief, run it, and note every correction you still need to make. Fold each correction back into the brief and run it again. When the first draft comes back right, save the brief somewhere you can find it. You have just made your first asset, and it took less time than the corrections you were going to make anyway.

Role, Task, Format

If the four-part brief feels like too much for a quick question, there is a smaller skeleton that fixes most bad prompts on its own. Three lines. Who is answering, what they must do, and what shape the answer arrives in. Nothing else in most prompts is load-bearing, and a surprising amount of what people add is actively in the way.

Role sets the expertise and the register. You are an operations consultant who works with small logistics firms gets you different vocabulary, different assumptions and different priorities from you are a helpful assistant. Role is not magic and it does not make the model know things it does not know. It does tell the model which of the many ways it could answer is the one you want, which is most of the battle.

Task is the verb. Summarise, rank, draft, critique, extract, compare, rewrite. One verb per prompt, ideally, with its object stated plainly. Rank these twelve workflow ideas by likely time saved for a five-person office is a task. Have a look at these and let me know your thoughts is a mood. When a prompt contains three verbs, the model will usually do the first one well, the second one adequately and the third one briefly, in exactly the order you least wanted.

Format is the shape. A table with named columns. Three paragraphs. A single sentence. A JSON object with specified keys. Plain text with no markdown. Name it and the model stops improvising around it. Leave it out and you get whatever the model considers a typical answer to questions like yours, which is usually a heading, some bullets and a cheerful closing line offering more help.

Who, what, what shape. If you remember nothing else about prompting, remember the order.

For micro-consulting, this skeleton is also a teaching tool. When you run a training session for a client's team, it is the first thing you hand them, because it is short enough to remember and strong enough to change results immediately. People who have spent months typing loose questions into a chat box are visibly surprised when three lines produce something they would actually use. That surprise is worth a great deal in a workshop. It is the moment a sceptical team decides you might be worth listening to.

It also gives you a quick diagnostic for other people's prompts. When a client shows you a prompt that is not working, check the three lines. Usually one is missing, most often the format, sometimes the role, occasionally the task itself, buried under paragraphs of background. Restore the missing line and the prompt often fixes itself. You will look cleverer than you are, which is a perfectly acceptable outcome for a consultant.

This week, take five prompts you use regularly and rewrite each in three lines. Run both versions side by side. Keep the winner. You will rarely need more than this skeleton for everyday work, and when you do, you will know exactly which line to expand.

Show Three Examples

Style is faster to demonstrate than to describe. You can spend a paragraph explaining that you want copy that is warm but professional, confident but not arrogant, concise but not curt, and get back something that is none of those things, or all of them in the wrong proportions. Or you can paste three examples of copy you like and say match these. The second approach usually wins, and it collapses a five-turn negotiation into one.

The reason is simple. Adjectives are ambiguous; examples are not. Warm means one thing to you and something else to a model averaging over everything it has read. An example carries its tone, length, structure, vocabulary and rhythm all at once, without anyone having to name them. The model is very good at noticing patterns in examples. It is merely adequate at turning adjectives into patterns.

Three is a useful number. One example invites slavish copying: the model reproduces its structure, even its specific phrases. Two show a pattern but can be read as a pair of opposites. Three let the model triangulate what they have in common and generalise from it. Choose examples that vary in content but share the qualities you care about. Three client emails about different topics, all in the right voice. Three summaries of different documents, all the right length and structure.

This is where micro-consulting gets interesting, because example collection is itself a service. Most businesses have a house style that lives only in the heads of their best people. When you run a prompt kit engagement or a documentation sprint, part of the work is finding the examples: the proposal that won, the complaint response that turned a customer around, the report the board actually read. Gathering those, annotating why each one works and building them into prompts and skills is genuinely valuable, and it is work the client could not easily do alone, because they are too close to it.

A good example is a style guide that cannot be misread.

There are two cautions. First, examples carry their flaws as faithfully as their virtues. If your three samples all open with the same tired phrase, so will everything the model writes. Read your examples critically before you use them, and edit them if needed. Second, be careful with confidential material. Client examples used inside that client's own prompts are fine, with their agreement. Client examples carried into another client's work are not. Keep libraries separate.

Try this on a piece of writing you produce often. Find three good past examples, paste them in with a short instruction to match their voice, structure and length, and give the model a new topic. Compare the result with what you get from a description alone. Then keep the three examples beside the prompt, in the same file, so the next time you need that kind of writing you start from demonstration rather than adjectives.

Negative Examples

Showing a model what you want is powerful. Showing it what you do not want, right beside what you do, is often more powerful still. A single bad example next to a single good one teaches the boundary in one pass, in a way that a page of instructions about tone rarely manages. The contrast does the explaining.

Think about how you learned to write well, if you did. Somebody probably showed you a clumsy paragraph and then a better version of the same paragraph, and you saw the difference at once. That is what a negative example does for a model. It does not merely say avoid jargon; it shows a sentence full of jargon and a plain sentence saying the same thing, and the line between them becomes obvious.

The technique works best when the bad example is plausible. A deliberately terrible example teaches nothing, because the model would never have produced it anyway. The useful negative example is the one the model is likely to produce by default: the over-enthusiastic opening, the hedged conclusion, the summary that repeats the question, the email that apologises three times. Write down the output you keep getting and do not want, label it clearly as the thing to avoid, and put the version you want beside it.

For consultants, negative examples are particularly useful in regulated or sensitive work. A prompt for a financial services firm can show an example of a reply that strays into personal advice and an example that stays safely on the right side of the line. A prompt for a charity's supporter communications can show an example that sounds guilt-inducing and one that sounds grateful. These pairs carry the compliance and the tone simultaneously, and clients find them far easier to review and approve than abstract rules.

One bad example, honestly labelled, is worth a page of instructions written in hope.

There is a subtlety. Do not let negative examples dominate the prompt. Too many of them and the model starts orienting around what to avoid rather than what to produce, which can make output stilted and cautious. One or two clear contrasts are usually enough. If you find yourself listing ten things not to do, the positive brief is probably too thin. Strengthen that instead.

This is also a fine exercise in a training session. Ask a client's team to bring an output they disliked. Together, write a short good version beside it, then add both to the prompt as a labelled pair and rerun. The improvement is usually immediate, and the team learns more from that ten minutes than from an hour of slides on prompt engineering.

Try it on your most stubborn prompt this week, the one that keeps producing something slightly off. Paste in the off output, label it not like this, write the version you wanted, label it like this, and run again. Boundaries are easier to respect when someone has drawn them. Models are no exception.

Constrain the Output

An unconstrained model writes an essay. A constrained one writes something you can use. The difference matters enormously in consulting work, because so much of what you build involves a model's output going somewhere other than a human's eyes: into a spreadsheet, a ticketing system, a database, the next step of an automated workflow. Essays do not fit into spreadsheet cells. Structured outputs do.

Constraint starts with naming the format precisely. Not give me a list but return a table with columns for task, owner, frequency and estimated minutes per week. Not summarise as JSON but return a JSON object with the keys category, urgency and suggested_reply, where urgency is one of low, medium or high. The more precisely you name the shape, the less the model has to guess, and the less it guesses, the more reliably your downstream steps work.

Constraint also means limiting what is allowed inside the shape. Specify allowed values for categories. Set maximum lengths. Say what to do when information is missing: return null, return the word unknown, or skip the field. Models are eager to please, and an eager model asked to fill a field it has no information for will sometimes invent something plausible. Telling it explicitly how to signal I do not know is one of the most valuable lines you can add to a production prompt.

For anything that feeds software, go further. Where the platform you are building on supports structured outputs or tool definitions with a schema, use them, because a schema enforced by the system is stronger than one described in prose. Then validate what comes back anyway. A small script that checks the output matches the expected shape, and retries or flags it when it does not, will save you from the one malformed response in a hundred that would otherwise break a client's process at an inconvenient moment.

Prose is for people. Structure is for pipelines. Know which one you are writing for.

This is the hinge between a prompt that impresses in a demo and a system that survives in production. Many first AI pilots fail not because the model's judgement was poor but because its outputs were inconsistent in shape. A field arrived with a different name one day. A category was spelled differently. A summary ran to three paragraphs when the interface had room for one line. None of these are intelligence problems. They are constraint problems, and they are entirely preventable.

Look at one workflow you are building or planning this week and ask where model output flows next. For each step, write down the exact shape the next step needs, then put that shape, with allowed values and missing-data rules, into the prompt. Add a validation check. It is unglamorous work. It is also the reason your systems keep working after you have stopped watching them, which is the only kind a client should pay for.

Make It Think First

On hard problems, quality comes from the loop, not the first attempt. Ask a model for an answer straight away and you get its first thought, delivered with confidence. Ask it to reason through the problem first, then draft an answer, then critique the draft against the original goal and revise, and you usually get something noticeably better. The loop costs you a line or two in the prompt. It often saves you an hour of edits.

Modern Claude models can reason before answering on their own, and when extended thinking is available it is worth using for genuinely hard tasks. But you can shape the loop explicitly too, and in consulting work you often should, because you want the reasoning visible. Before recommending which workflow to automate first, list the factors that matter for this client, weigh each candidate against them, then give your recommendation and the single biggest risk to it. That prompt produces a recommendation and the reasoning behind it, which is what a client actually needs to make a decision.

The critique step is the one people skip. After the draft, ask the model to review it against the brief: does it answer the question asked, does it fit the format, has it made any claims it cannot support, what would a sceptical reader object to. Then ask for a revised version. You will be surprised how often the critique catches something real: a missed constraint, an assumption stated as fact, a recommendation that contradicts something in the source material.

This pattern is especially useful when the stakes are higher than a quick draft. An audit recommendation that a client will act on. A summary of a contract clause. A ranked list of options with money attached to the choice. In each case, the extra loop is cheap insurance. It does not replace your review, but it means the version you review has already survived one round of scrutiny, so your attention goes to the subtle problems rather than the obvious ones.

The first answer is a draft. Models know this. It helps if you do too.

Do not overuse it. A request to reformat a table does not need a reasoning phase, and asking for one simply makes the response slower and longer. Reserve the full loop for tasks where a wrong answer would cost something, or where the right answer depends on weighing several factors. For simple transformations, a clear instruction and a constrained format are enough.

In a client's system, this loop can be built in as separate steps rather than one long prompt: one call reasons and drafts, a second critiques against a rubric, a third revises. That makes each step easier to test and improve independently, and it gives you somewhere to put a human checkpoint if the work needs one. This week, pick one decision-shaped task you hand to Claude and add the loop explicitly. Compare the before and after. Thinking first is not slower. It just moves the slowness to where it belongs.

Ask for the Rubric

Here is a move that feels slightly backwards and works remarkably well. Before the model answers, ask it to write the marking scheme. What would an excellent response to this task include? What would a weak one get wrong? Then let it answer, grade its own answer against that rubric, and rewrite until it would score full marks. The model becomes its own examiner, with criteria written before the exam rather than after.

Why does this help? Because writing a rubric forces the model to make the hidden requirements of a task explicit. A request to write a project update for a client has unstated criteria: it should lead with what changed, quantify progress, flag risks honestly, ask for any decisions needed, and stay short. The model knows all of this in some sense, but it does not necessarily apply all of it in a single pass. Writing the rubric surfaces the criteria; grading against it applies them.

You can also write the rubric yourself, or better still, with the client. This is where the technique becomes a consulting tool. In an agent pilot or a prompt kit engagement, sit down with the person who will judge the output and ask them what makes a good one. Write their answers down as a rubric, in their words. Then build that rubric into the prompt and into the evaluation process. Suddenly the client's tacit standards are explicit, the model is held to them, and acceptance testing has a basis that everyone agreed to in advance.

A rubric also makes improvement measurable. If you run twenty test cases and score each one against the same five criteria, you can see exactly where the system is weak. Perhaps it always quantifies progress but rarely flags risks. That tells you which part of the prompt to strengthen. Without a rubric you are left with a general feeling that the outputs are mostly fine, which is a sentiment rather than a finding.

If you cannot write down what good looks like, neither you nor the model will reliably produce it.

A caution: models grading their own work tend to be generous. Self-assessment is a useful step, not a final verdict. For anything important, have a separate pass grade the work, ideally a fresh context with no attachment to the draft, and keep a human looking at a sample. The rubric makes both of those reviews faster and fairer, but it does not replace them.

Try it on a recurring piece of writing this week. Ask Claude to write a five-point rubric for an excellent version, edit the rubric until you agree with it, then have the model draft, score and revise against it. Save the rubric beside the prompt. You will find you reuse it more than the prompt itself, because a good definition of quality outlives any particular way of asking for it.

Prefill the Answer

Starting the reply for the model steers its format harder than almost any instruction. Write the opening of the answer yourself, the first bracket of a JSON object, the first heading of a report, the first cell of a table, and the model continues in that shape. It is a small move with a large effect, and it is one of the oldest tricks in working with language models.

The principle is that models continue patterns. An instruction is a request; a started answer is a pattern already in motion. If the reply already begins with an opening brace, the model is strongly inclined to finish the JSON rather than preface it with a friendly sentence about what it is about to do. If the reply begins with a specific heading, the model continues with content under that heading rather than inventing its own structure.

How you use this depends on where you are working. When you build on the API, you can supply the opening of the assistant's turn directly in many configurations, which makes prefilling precise. In a chat interface you approximate it by showing the opening you want: begin your answer with the line Summary for the partners: and continue from there. In a template or skill, you can include the skeleton of the output, with the first section partly filled, and ask the model to complete it. All three nudge the same tendency.

Prefilling is particularly useful for removing the preamble that creeps into model outputs. You know the kind: Certainly! Here is a summary of the document you provided. Harmless in a chat, irritating in a client deliverable, and actively broken when the output feeds a system expecting data. Starting the reply removes the space where the preamble would go. Combined with a clear format constraint, it is usually enough to get clean output every time.

If you want the answer to start somewhere particular, start it there yourself.

There is a gentle art to it. Prefill too much and you constrain the content as well as the form, sometimes in ways you did not intend. Prefill only the structural opening, the bracket or heading or first label, and leave the substance to the model. Also note that some features and configurations limit or change how prefilling works, so if a technique that worked in one place behaves differently in another, check the current documentation rather than assuming the model has become stubborn.

For consultants, prefilled templates make excellent deliverables in their own right. A client's team can open a saved prompt that already contains the skeleton of the report they need, fill in the specifics, and get a consistent document every time. That consistency is often what the client actually valued, more than any particular cleverness in the prompt.

This week, take one output where the format keeps wandering and start the reply yourself. Notice how much of your previous instruction becomes unnecessary. Sometimes the shortest way to say what you want is simply to begin it.

Prompts Are Assets

A prompt you use twenty times is not a message. It is infrastructure. It deserves a name, a version, a home, and a note explaining what it is for and how you know it works. Most people treat their best prompts the way they treat brilliant remarks at a dinner party: delivered once, vaguely remembered, impossible to reproduce. For a consultant, that is money left on the table, repeatedly.

Start by naming things. Diagnostic call summary, audit opportunity scorer, runbook drafter, case study first draft. A name lets you find a prompt, refer to it, and notice when you have two that do the same job. Then give each a home: a folder in a repository, a section of a notes app, a project in Claude where it sits as reference material. The test is whether you can find the right prompt in under ten seconds when you need it. If you cannot, it does not really exist.

Versioning matters more than it sounds. Prompts improve through use. You tweak a line after a bad output, add an example after a client complaint, tighten a constraint after a downstream failure. Without versions, you cannot tell which change helped, and you cannot roll back the one that made things worse. Plain text files in git are perfectly adequate. So is a simple changelog at the bottom of each prompt noting the date and the reason for each change.

Testing turns a good prompt into a reliable one. Keep a handful of test inputs beside each important prompt, including at least one awkward case, and rerun them whenever you change the prompt or when a new model becomes available. You do not need elaborate tooling to start. A short script or even a careful manual check against the same five inputs will catch most regressions before a client does.

A clever prompt is a moment. A tested, versioned prompt is a tool. Only one of them compounds.

Once your prompts are assets, you begin to see your practice differently. Your library is the difference between your first engagement in a sector and your tenth. It is what lets a two-week sprint deliver what used to take a month. It is also, increasingly, something you can hand over: a client's own library, built during your engagement, documented and tested, becomes part of what they bought. The next part of this book goes further and turns the best of these assets into skills that load themselves.

This week, gather the prompts you have used more than three times. Give each a name, a home, a version number and a few test inputs. It will take an afternoon. It will repay that afternoon within a month, and it will quietly change how you think about everything you write for a model. Every good prompt you write from now on is either an asset or a waste of a good prompt.

Sell the Prompt Kit

Everything in this part can be packaged and sold. The prompt kit is one of the simplest micro-engagements there is: a fixed-scope project to give a team a tested set of prompts for the tasks they do every day. It is easy to explain, quick to deliver, low risk for the buyer and visibly useful from the first morning. It is also an excellent first rung for clients who are curious about AI but not yet ready for an audit or a pilot.

The shape is straightforward. Start with a short workshop or a few interviews to list the team's recurring tasks that involve reading, writing or deciding. Pick the ten that are most frequent and most painful. For each one, gather real examples, good and bad, and write a prompt using everything in this part: a proper brief, a clear role, a constrained format, worked examples, a negative example where it helps, a rubric for quality. Test each prompt against real inputs with the people who will use it. Then hand over the kit with a short guide and a session showing the team how to use it.

What makes it valuable is not the prompts alone. It is that the prompts are tuned to this team's work, in this team's voice, with this team's examples, and tested against this team's real inputs. A generic list of prompts is free on the internet and worth roughly that. A kit that produces their proposal format, their complaint replies and their weekly report on the first attempt is worth a great deal, because it saves time every single day from the moment it lands.

Where the kit lives depends on the client. For a team on Claude, prompts can sit in a shared project as reference material, alongside the examples and a short guide. For teams further along, the best prompts can become skills, so they load when relevant rather than being copied and pasted. Either way, document each prompt with its purpose, an example input and output, and the name of the person who owns it inside the business.

A prompt kit is the smallest thing you can sell that a team will use every day.

Be clear about scope. Ten prompts, not fifty. One team, not the whole company. Tested against real inputs, not hypotheticals. A fixed handover date. When the client asks for prompts for another department, which they will if the first set is good, that is the next engagement. Write it down and propose it at the handover.

The kit also does quiet work for your pipeline. It produces measurable before and after examples, it creates an internal champion who uses it daily, and it surfaces the bigger workflow problems that a prompt alone cannot fix, which are precisely the problems your next rung addresses. This week, sketch a prompt kit for a team you know: the ten tasks, one tested prompt for the first. If that first prompt saves twenty minutes a day for one person, you already have the case study.

Context Is the Product

Model quality, for any given piece of work, is roughly fixed. What you feed the model is not. Most of the gap between a mediocre answer and a brilliant one is assembled before the prompt is sent: which documents the model can see, which examples it has, what it knows about the client, the decisions already made, the goal it is working towards. Prompt craft gets the attention. Context does most of the work.

This is good news for consultants, because context is where your value lives. Anyone can open Claude and ask a question. Very few people can assemble the right context for a specific business problem: the relevant policy pages, the three emails that show the real issue, the spreadsheet with the actual numbers, the note explaining why the last attempt failed. Knowing what to gather, and what to leave out, is expertise. It is the expertise clients are buying when they hire you instead of just buying a subscription.

Think of context in layers. At the bottom, durable knowledge that rarely changes: who the client is, their sector, their style, their constraints. Above that, project knowledge: the goal of this engagement, decisions made so far, the definition of done. Above that, task context: the specific documents and examples relevant to the question in front of you. And at the top, the instruction itself. Each layer should be curated separately, because each changes at a different rate and goes stale in a different way.

The tools have grown up around this idea. Projects in Claude let you pin reference material that every conversation can see. Claude Code reads memory files from a repository at the start of each session. Skills load detailed instructions only when they are relevant. Connectors let the model fetch live information from a client's systems rather than relying on what you pasted last week. Each of these is, at heart, a way of getting the right context in front of the model at the right time without you having to do it by hand.

Garbage in, garbage out was always true. The new rule is: thoughtfully chosen in, surprisingly good out.

The practical shift is to treat context assembly as a step in its own right, not an afterthought. Before you ask the hard question, ask yourself what a brilliant human expert would want to read first. Then gather exactly that, no more and no less, and put it where the model will see it. The chapters that follow cover how: pasting the real thing, ordering it well, keeping it lean, killing what is stale and structuring what remains.

This week, pick a task where Claude's answers have been disappointing. Before rewriting the prompt, rewrite the context. Add the document you have been summarising from memory. Remove the three that are not relevant. Add a short note on the decision already made. Then ask the same question again. You will often find the prompt was fine all along. It was simply being asked to answer a question about a room it could not see.

Paste the Real Thing

Summaries lose exactly the detail that mattered. When you describe an error message from memory, you leave out the line number. When you paraphrase a contract clause, you drop the qualifying phrase that changes its meaning. When you summarise a client's complaint, you smooth away the tone that tells you how angry they are. Then you ask the model to help, and it helps with your summary, which is a slightly different problem from the real one.

The fix is almost embarrassingly simple: paste the actual thing. The actual error, in full. The actual clause, with its numbering. The actual email, with its typos. The actual spreadsheet export, not your description of what is in it. Models are very good at reading raw material, often better than people, because they do not get bored halfway through and they do not skim. Give them the source and they will usually find what you would have missed.

This matters doubly in consulting, because you are often working at one remove from the problem. A client tells you their invoicing process is slow. If you ask Claude how to speed up invoicing, you get generic advice. If you paste in an anonymised export of last month's invoices, the email thread where a customer disputed one, and the internal checklist the accounts team follows, you get specific observations: the same three fields are re-entered by hand, disputes cluster around one product line, the checklist has a step nobody does. That is the difference between a consultant and a search engine.

There are limits, and they are important. Real material often contains personal and confidential information. Before you paste anything from a client, know what your agreement allows, what their policies require and what the data protection rules in your jurisdiction say. Anonymise where you can, remove what you do not need, and use tools and plans whose data handling the client has approved. Pasting the real thing is good practice. Pasting someone's customer list into a tool they have not sanctioned is not.

A paraphrase is a lossy copy. The model deserves the original, and so does your client.

There is also a craft to choosing which real thing. Pasting everything is its own kind of failure, as the chapter on the context budget will argue. The skill is to find the specific source material that contains the problem: the failing case, not all cases; the disputed invoice, not the whole ledger; the paragraph of policy that applies, not the whole handbook. Real and relevant, in that order.

Try it the next time you are stuck. Notice the moment you start typing a description of something you could simply paste. Stop, find the original, clean it of anything that should not leave the client, and paste it in. Then ask your question. You will save the round trip where the model asks for more detail, and you will avoid the subtler failure where it never asks and confidently solves the wrong problem.

Order Matters

Where you put things in a prompt affects how well the model uses them. The general guidance, which holds up well in practice, is simple: long documents first, your question last. Put the material at the top, the instructions and the actual question at the bottom, so the instruction is fresh when the model starts answering rather than buried under ten thousand words of source text.

The intuition is easy to grasp. Imagine handing a colleague a thick report with a sticky note on the front saying please check the payment terms, and imagine handing them the same report with the sticky note on the last page. In the first case, by the time they reach page forty they may have forgotten precisely what they were looking for. In the second case, the question arrives at the moment they are ready to answer it. Models are not people, but long prompts behave in a similar way often enough to plan for it.

A good default structure for a substantial prompt runs like this. First, the reference documents, each clearly labelled. Then any examples of the output you want. Then a short statement of who the work is for and why. Then the specific task, the format and the success check. Finally, if it helps, a one-line restatement of the most important constraint. That structure reads naturally, and it keeps the instruction close to the answer.

Within the documents, order matters too. Put the most relevant material where the model is most likely to weigh it, and label each piece with what it is and why it is there. The following is the client's current returns policy, which the new process must comply with is far more useful than an unlabelled block of text. Labels tell the model how to use each document, not merely that it exists.

Material first, question last. The model answers what it read most recently with the most care.

For consultants building systems rather than one-off prompts, ordering becomes a design decision. When you assemble a prompt programmatically, pulling in a customer record, the relevant policy, a few past examples and the incoming message, decide the order deliberately and keep it consistent. Inconsistent ordering is a quiet source of inconsistent output, and it is one of the first things to check when a system that worked in testing behaves strangely in production. Consistent structure also helps with prompt caching where the platform supports it, since stable material at the start can be reused across calls.

This is also a useful point to make in training sessions, because it is so easy to apply. Most people paste their question first and their material afterwards, because that is how they think about the problem. Showing a team the same prompt in both orders, with visibly different results on a long document, converts the principle into a habit faster than any explanation.

This week, take your longest regular prompt and reorder it: documents at the top with labels, examples next, instruction and question at the bottom. Run it on the same input as before. If the answer improves, keep the order. If it does not, you have lost nothing but a minute, and you have learned something about that particular task.

The Context Budget

Context windows are large now, large enough to hold whole books and sizeable codebases. That size invites a bad habit: putting everything in because you can. Every irrelevant document in the context is a distraction the model has to work around. It may not fail outright, but the answer gets vaguer, the focus drifts and the details you cared about get less attention. Three right files beat thirty, and the answer usually sharpens as the pile shrinks.

Think of context as a budget rather than a container. The container can hold a great deal. The budget is the amount of attention you want the model to spend on any one thing. Spend it on the material that bears directly on the question. Leave out the material that is merely related, the background you included just in case, the old versions, the meeting notes from a different project. If you would not hand it to a sharp human expert on this question, do not hand it to the model.

Curating is a skill, and it is one of the most valuable things a consultant brings. A client who has given you access to their shared drive has given you thousands of documents. The value you add is knowing which six matter for this problem. With Claude, you can do this curation in two steps: first, ask the model to read a broader set and identify which documents are relevant to the question, with a sentence on why; second, start a fresh conversation with only those documents and ask the real question. The first step is triage. The second is the work.

The budget idea also applies to long-running work. In Claude Code, the context fills as a session goes on, with files read, commands run and output produced. Subagents help here, because they can do exploratory work in their own context and return only a summary. Compacting or starting fresh sessions helps too. The principle is the same everywhere: the main thread should carry what the current task needs, and the noise should be somewhere else.

The model can read everything. That does not mean it should.

Cost is a factor as well, though rarely the main one. Larger contexts take longer to process and cost more to run, and in a production system called many times a day those differences add up. A lean, curated context is faster, cheaper and usually better. That is a rare alignment of incentives, and worth taking advantage of when you design a client's system.

Try this on your next research-shaped task. Before asking the question, list every document you were about to include and mark each one as essential, useful or just in case. Include only the essentials, plus useful ones if there is a specific reason. Run it and compare with the everything version. Most people find the lean version answers more precisely. It also teaches you something uncomfortable about how much of your usual context was there for your reassurance rather than the model's benefit.

Long-Chat Rot

After forty turns, a conversation is carrying a lot of baggage. Dead assumptions you corrected twenty messages ago. Approaches you tried and abandoned. Old versions of a document. A misunderstanding from early on that you fixed but the model may still half-remember. All of it sits in the context, and all of it can influence the answer. The result is a gradual slide in quality that is easy to miss, because each individual answer is only slightly worse than the last.

The symptoms are recognisable once you know them. The model reintroduces a phrase you told it to remove. It reverts to an earlier structure. It mixes details from two versions of a plan. It seems to be arguing with a position you no longer hold. You find yourself repeating instructions you gave an hour ago. None of this means the model has got worse. It means the conversation has become a muddle, and the model is doing its best with the muddle you have given it.

The fix is to start fresh with a clean brief. Before you leave the long conversation, ask the model to write a summary of where things stand: the goal, the decisions made, the current version of the work, the open questions and the next step. Read it carefully, because it will occasionally preserve something you wanted to discard, and correct it. Then open a new conversation, paste in the corrected summary and the current version of the work, and carry on. The new conversation has everything that matters and nothing that does not.

This is not a sign of failure. Experienced users start fresh conversations routinely, often at natural break points: when a phase of work finishes, when the direction changes, when the topic shifts. In Claude Code, clearing the context between unrelated tasks is a normal part of a good session, and the tool can compact long sessions for you. The habit is the same in either place: do not try to make one conversation carry a whole project.

Arguing with your own history is a poor use of an afternoon. Write the handover and begin again.

For consultants, long-chat rot has a client-facing side. If you hand a client's team a workflow that involves one ever-growing conversation, quality will degrade for them too, and they will conclude the tool is unreliable. Build fresh starts into the workflow: a new conversation per case, per document, per day, with the durable context pinned in a project so it is always present. That small design choice prevents a large share of the it used to work better complaints that arrive a month after handover.

This week, notice the next time a conversation starts to feel sluggish or confused. Instead of correcting it again, ask for the summary, fix it, and start a new conversation with it. Compare the next answer with what you were getting. Fresh starts feel like lost progress. In practice they are usually the fastest route to the progress you actually wanted.

Project Knowledge

Some context changes with every task. Some barely changes at all: the client's brand rules, the glossary of their sector's jargon, the data schema their systems use, the decisions made at kick-off, the definition of done for the engagement. Re-pasting those into every conversation is tedious and error-prone. Pin them once, somewhere every conversation can see them, and they stop being a chore.

Projects in Claude are built for this. You upload or write reference material into the project, and every conversation inside it starts with that material available. Add custom instructions and those apply throughout too. For an engagement, a project per client is a natural shape: the brief, the scope, the glossary, the house style, a few annotated examples, the running decision log. Every conversation about that client begins with the right foundation, and you never again explain their business model at the start of a chat.

The same idea appears in other places. A repository can carry a memory file that Claude Code reads at the start of every session. A skill can carry durable instructions for a recurring type of task. A team workspace can share project knowledge between colleagues so everyone works from the same foundation. Different surfaces, same principle: durable knowledge belongs somewhere durable, not in someone's clipboard history.

Curate project knowledge as carefully as task context, perhaps more carefully, because it influences everything. Keep it short and specific. A ten-page brand guidelines document may contain one page that matters for writing; extract that page. A long glossary may contain a dozen terms that cause confusion; lead with those. Date your decision log so it is clear which decisions are current. And review the project's knowledge when the engagement changes phase, because what mattered during the audit may be noise during the build.

If you have explained it twice, it belongs in the project. If you have explained it five times, you are the project.

Project knowledge also makes a fine handover artefact. At the end of an engagement, a well-organised project containing the client's context, tested prompts, examples and instructions is something their team can keep using the next morning. Many clients find this more useful than any report, because it is not a description of how to work with AI on their business. It is a working environment already set up for it.

There is a security point too. Project knowledge is visible to anyone with access to the project, so think about what goes in and who can see it. Keep client material in client-specific projects, never mixed with other clients' material, and agree with the client who on their side should have access when you hand it over.

This week, create a project for your busiest client or your own practice. Add the five things you find yourself re-explaining most often, written as short, clear notes. Then work inside it for a week and notice how much shorter your prompts become. That shortening is time you were spending on remembering, now spent on thinking.

Restate the Goal

Long tasks drift. You start out asking for a process redesign that reduces turnaround time, and three hours later you are deep in a debate about the naming of status fields. Each step made sense from the one before it, but the path has wandered away from the destination. Models drift in exactly the same way, and for much the same reason: they respond to what is in front of them, and what is in front of them is the most recent step, not the original goal.

The remedy costs very little. Restate the objective mid-flight. A short line, at the point where you notice the work branching, does the job: Reminder: the goal is to cut quote turnaround from days to hours for the sales team. Does this naming decision serve that? Twenty words. They pull the conversation back to the question that matters and frequently reveal that the current sub-task is a detour you can drop.

This is especially useful in agentic work, where Claude may run for many steps without you steering each one. A task brief that begins with a clear objective is good. A task brief that also asks the agent to check its progress against the objective at intervals is better. In Claude Code, a short plan with the goal at the top, kept in a file the agent updates as it works, acts as a running reminder. The agent reads its own plan, sees the goal, and is less likely to spend an hour polishing something the goal does not require.

The same discipline applies to the humans in a consulting engagement. Client meetings drift as readily as models. A sprint that began as an invoice-processing pilot can become, over a few friendly calls, a discussion of the client's entire finance stack. Restating the goal at the start of every check-in, ideally in the client's own words from kick-off, keeps everyone honest. It also gives you a polite way to park scope creep: that sounds valuable; does it help with the turnaround target, or shall we add it to the list for next time?

Twenty words of reminder can save an hour spent solving a problem nobody has any more.

There is a subtler benefit. Restating the goal regularly forces you to check whether the goal is still right. Sometimes the drift is telling you something: the original objective was the wrong one, and the work has wandered towards the real problem. That is worth noticing and discussing openly, rather than either ignoring the drift or blindly following it. Either way, the restatement is what makes the choice conscious.

Try it during your next long working session. Set a gentle reminder, perhaps every hour or at each natural break, to restate the goal in one sentence and ask whether the current step serves it. Do the same at the start of your next client check-in. You will cut some work you did not need to do, and occasionally you will discover that the goal itself needs a polite edit, which is the most valuable kind of drift there is.

Kill Stale Context

When something changes, the old version is not merely out of date. It is actively harmful. If the model can still see last week's pricing table, the previous draft of the policy or the old file structure, it will often blend the two and produce a plausible hybrid: mostly the new version, with one old detail quietly carried forward. Plausible hybrids are the worst kind of error, because they look right until someone relies on them.

The first defence is to say so, loudly and explicitly. The refund policy changed today. The version below replaces all earlier versions. Ignore any refund terms mentioned earlier in this conversation. That is not over-emphatic. It is the minimum. Models do not automatically know that a newer document supersedes an older one, especially when both are in the context. Telling them which is current, and that the other must be disregarded, removes the ambiguity.

The second defence, and the stronger one, is to remove the stale material altogether. Update the document in the project knowledge rather than adding a new version beside the old one. Start a fresh conversation rather than correcting a long one. In a repository, update the memory file and delete the outdated instruction rather than appending a contradiction. Every copy of old information you leave lying around is a chance for it to resurface at the worst possible moment.

This is a frequent source of trouble in client systems after handover. A business changes a policy, updates the document on their intranet, but forgets that the AI workflow you built has its own copy of the old policy pinned somewhere. A month later a customer receives an answer based on rules that no longer apply. The fix is design, not vigilance: wherever possible, have systems read from a single source of truth rather than keeping their own copies, and put a review of AI reference material into the client's change process. Write it into the runbook.

Old context does not fade politely. It waits for an opportunity to be confidently wrong.

There is a personal version too. Your own prompt library and project knowledge accumulate stale material: instructions written for an older model, examples from a client whose style has changed, workarounds for problems that no longer exist. Prune them periodically. A short instruction that is current beats a long one that is half obsolete, and the half that is obsolete may be contradicting the half that is not.

This week, look at one project or long-running workflow and find the stale material. Old versions of documents, superseded decisions, instructions that no longer apply. Delete what you can, mark what you must keep as historical, and make the current version unmistakable. Then add a line to your handover checklist reminding clients to do the same whenever their policies change. The cheapest error to fix is the one that never had a stale document to come from.

Structured Input

When a prompt contains several kinds of material, the model has to work out where one ends and the next begins. Where does the transcript stop and your instruction start? Is that paragraph an example of good output or part of the source document? Usually it guesses correctly. Sometimes it does not, and the errors are maddening: an instruction treated as content, an example summarised as if it were the document, a customer's message obeyed as if it were your request.

The fix is to structure the input. Wrap each distinct block in clearly named tags: the source document in one, the examples in another, the client's background in a third, your instruction in a fourth. Claude responds well to XML-style tags in particular, and the names do not need to follow any standard. Plain, descriptive labels work best: contract, previous_emails, style_examples, task. Then refer to the tags in your instruction: using the policy in the policy tags, draft a reply to the message in the customer_message tags.

Structure in tends to produce structure out. When the input is clearly sectioned, the model is better at keeping track of what each section is for, at quoting accurately from the right one and at following the instruction rather than being distracted by the material. You can also ask for structured output using the same idea, with the reasoning in one tag and the final answer in another, which makes it easy for software, or a busy reader, to pick out the part that matters.

There is a security dimension worth taking seriously. In client systems, much of the input comes from outside: customer emails, uploaded documents, web pages. Some of that content may contain text that looks like instructions, whether by accident or by design. Clearly separating untrusted content from your instructions, labelling it as data to be processed rather than commands to follow, and telling the model explicitly not to act on instructions found inside it, is a basic defence. It is not a complete one, which is why later chapters discuss guardrails and human checkpoints, but it is the foundation.

Tell the model which part is the letter and which part is your note about the letter. It cannot always tell by looking.

Structured input also makes prompts easier to maintain. When a client's system assembles a prompt from several sources, a customer record, a policy extract, some examples and an incoming message, tags make each component visible and replaceable. A colleague reading the prompt template a year later can see at once what goes where. That legibility is part of what makes a system operable by someone who has never met you.

Take one of your more complex prompts this week and restructure it with tags. Name each block for what it is, keep your instruction in its own tagged section at the end, and refer to the blocks by name in the instruction. Run it on a tricky input. If nothing changes, you have still made the prompt easier to read and maintain. Usually something does.

The Documentation Sprint

Every small business runs partly on knowledge that exists only in people's heads. How the month-end close actually works. Which supplier needs a phone call rather than an email. Why the second spreadsheet exists. When that knowledge walks out of the door, on holiday or for good, things break. And when the business tries to use AI, it discovers that a model cannot read heads either. The documentation sprint addresses both problems at once, and it is one of the most quietly valuable micro-engagements you can sell.

The shape is a fixed-length sprint, typically a week or two, focused on one area of the business. You interview the people who do the work, record walkthroughs with permission, gather the existing scattered documents, and use Claude to turn all of it into clear, structured documentation: process guides, decision rules, glossaries, checklists and frequently asked questions. Each draft goes back to the person who does the work for correction. The output is a set of documents a new hire could follow and a model could use as context.

That dual audience is the selling point. Traditional documentation projects were hard to justify because the documents were rarely read. Documentation written for both people and AI gets used constantly: it becomes the project knowledge behind the team's assistant, the reference material for an agent pilot, the context that makes prompts work. A client who buys a documentation sprint is buying the foundation that every future AI engagement will sit on, and they can see that foundation being used within days.

The craft lessons of this part apply directly. Paste the real thing: transcripts and actual documents, not your summary of them. Kill stale context: find and retire the outdated versions as you go. Structure the input: consistent headings and labelled sections make documents easier for models to use. And the handoff principle, writing the state, decisions, open questions and next action at every shift change, becomes a habit you leave behind with the client, so the documentation stays alive after you have gone.

Documentation used to be written for the auditor. Now it is written for the new hire and the model, both of whom actually read it.

Be precise about scope. One process area, not the whole business. A fixed number of interviews. A named owner on the client side who will keep the documents current. A clear statement of where the documents will live and how they will be maintained. Without an owner, documentation decays within months, and decayed documentation fed to a model produces confidently outdated answers, which is worse than none.

This engagement leads naturally to others. Once a process is documented clearly, the opportunities for automation become obvious, and you are the person who has just read every step of it. This week, pick a process in your own practice that lives only in your head. Spend an hour with Claude turning it into a written guide. Then read it back and notice how much you assumed nobody needed to be told. That gap is what clients will pay you to close.

Read the Repo First

A good share of micro-engagements happen inside someone else's repository. A script that reconciles two exports. An internal tool the operations team relies on. A website with a form that should route enquiries more intelligently. You arrive as a stranger, usually with a short calendar, and the temptation is to start changing things on the first afternoon. Resist it. Ten minutes of exploration buys hours of correct code, and with Claude Code those ten minutes are cheap.

Claude Code is Anthropic's agentic coding tool. It reads a codebase, edits files, runs commands and checks its own work, and you direct it in conversation. Before you ask it to change anything, ask it to look. Read this repository and explain its architecture: the main components, how data flows between them, the conventions it follows, how it is built and tested, and anything that looks fragile. It will search, open files, read configuration and come back with a map. Your job is to read the map critically and ask follow-up questions until you understand the terrain.

This exploration phase is where many of a client's hidden problems surface. The test suite that has not run in a year. The configuration file with credentials in it. The two modules that do the same thing differently. The dependency several versions behind. None of these may be in scope for your engagement, but you need to know about them, partly because they affect how you work and partly because they are often the material for the next engagement. Note them, tell the client and keep going.

Plan mode helps here, because in it Claude can read and analyse without editing anything. For a first look at an unfamiliar codebase, that is exactly the right setting. You get the agent's full reading ability with no risk that an eager first suggestion turns into an unreviewed change. Once you understand the shape of things, you can move to a mode where edits are allowed, with the boundaries you choose.

An agent that has read the codebase writes code that belongs in it. One that has not writes code that merely compiles.

There is a client-facing benefit too. The architecture summary is useful in its own right. Many small businesses have code nobody fully understands, written by a contractor who has since moved on. A clear written map of their own system, produced in the first hour of your engagement and checked by you, is often received with real gratitude. Some consultants offer it as a standalone micro-engagement: a codebase review that ends with a written map, a list of risks and a ranked set of improvements.

Make exploration a ritual for every repository you touch. Before the first edit, ask for the map, read it, correct it where you know better, and save the corrected version somewhere the agent will see it next time. The next chapter describes exactly where. You will make fewer mistakes, you will make them smaller, and you will look like someone who takes the client's system seriously, which is the impression you want to leave on the first afternoon.

CLAUDE.md First

The first file you write in a client's repository should usually be the one that explains the repository to Claude. A file called CLAUDE.md at the root of the project is read automatically at the start of every Claude Code session. Whatever you put there, the agent knows before it does anything else: how to build and test, which conventions to follow, which directories to leave alone, which commands are safe and which are not. It is the highest-leverage piece of writing you will do all week.

Start with commands. How to install dependencies, run the tests, start the application, lint the code. These are the things an agent most often needs and most often guesses at, and a wrong guess wastes time or, worse, runs something unwanted. Then conventions: naming, folder structure, preferred libraries, how errors are handled, how tests are written. Then gotchas: the module that looks unused but is not, the environment variable that must be set, the deployment step that must never run from a laptop. Keep it short. A long memory file is read less carefully, by agents and humans alike.

You can bootstrap it quickly. Claude Code can generate a starting CLAUDE.md from the codebase with its init command, and the architecture map from your exploration phase is good raw material. But do not accept the generated version without editing. The most valuable lines are the ones only a human knows: the finance team runs the export script on the first working day of each month; do not change its output format without telling them. No amount of reading the code would reveal that. You learned it on the diagnostic call.

For consultants, the memory file does double duty. It makes your own sessions faster and more reliable during the engagement. And it is a handover asset: when you leave, the client's next developer, or the client's own Claude sessions, inherit everything you learned about their codebase. A good CLAUDE.md is a runbook that the tooling reads for you. Clients who use Claude Code themselves notice the difference immediately; their sessions suddenly behave as if someone had briefed the agent properly, because someone did.

Every explanation you put in the memory file is one you never have to give again.

Keep it current. When you discover a new gotcha, add it. When a convention changes, update it. Delete instructions that no longer apply, because stale instructions are worse than none. Claude Code also supports memory files in subdirectories and a personal file for preferences that should not be shared with the team, so put project rules in the shared file and your own habits in yours.

On your next repository engagement, make the memory file your first commit. Commands, conventions, gotchas, under a page. Then work for a day and add every correction you found yourself making to the agent. By the end of the engagement you will have a document the client did not know they needed and will not want to lose. It is the smallest deliverable you will ever hand over, and quite possibly the one used most often.

Plan Before the Edit

Make the agent write the plan before it touches a file. Reading a wrong plan takes thirty seconds. Unwinding a wrong refactor across nine files takes an afternoon, and on a two-week engagement you do not have many afternoons to spare. Plan first is the single cheapest habit for avoiding expensive mistakes in agentic coding, and it suits consulting work particularly well.

Claude Code has a plan mode for exactly this. In it, the agent can read files, search the codebase and reason about the change, but it cannot edit anything or run commands that change state. You describe the task; it investigates and proposes a plan: which files will change, what each change will be, what order to do them in, how it will verify the result. You read the plan, push back on the parts you disagree with, ask questions, and only then let it proceed.

The value is in the conversation about the plan. This is where you catch the agent proposing to rewrite a module you know is fragile, or choosing a library the client does not use, or missing a downstream consumer of the data format it wants to change. It is also where you apply the knowledge from your diagnostic call and exploration: the reporting team reads that table directly; do not change its columns. Thirty seconds of reading and one sentence of correction can save a day of repair.

Plans are also good client artefacts. For a change that matters, a written plan, checked by you, can go to the client's technical lead before any code changes. That turns a potentially nervous moment, an outside consultant with an AI agent in their codebase, into a reassuring one: here is exactly what will change, here is why, here is how we will check it. People are far more comfortable with change they have seen described in advance. Small clients rarely get that courtesy from contractors, and they notice when they do.

The plan is where you are allowed to be wrong cheaply. Spend your mistakes there.

Not every change needs a formal plan. Renaming a variable or fixing a typo does not. A good rule of thumb is to plan whenever a change touches more than one file, alters a data format or interface, or does anything you would struggle to undo. When in doubt, plan. The cost is small, and the habit of always planning for consequential work will keep you out of most of the trouble this book warns about.

There is a quieter benefit. Reading plans makes you better at specifying work. You start to notice what you left out of your request because the plan reveals the gap: the agent assumed a format you did not specify, or chose an approach you would not have. Over time your requests get sharper and the plans need less correction. This week, use plan mode for every multi-file change you make. Read each plan as if a junior had written it and you were responsible for the result. You are.

Small Diffs, Fast Loops

One concern per turn, verified before the next. That is the working rhythm that makes agentic delivery reliable. Big-bang sessions, where you ask for five changes at once and review the result as a whole, fail in ways that are expensive to untangle. Small diffs fail in ways you can simply undo. On a short engagement, the difference between those two failure modes is often the difference between finishing on time and not.

The pattern is easy to describe and takes discipline to follow. Ask for one change. Let the agent make it and run the relevant checks. Review the diff. If it is right, commit it. If it is wrong, undo it and ask again with a better instruction. Then move to the next change. Each cycle might take a few minutes. A day of such cycles produces a clean, reviewable history of small, working steps, which is exactly what you want to hand a client.

The temptation to batch is strong, because the agent is fast and big requests feel efficient. But a large diff is hard to review properly. Your attention fades halfway through, and the subtle problem in file seven slips past. When something breaks later, you cannot easily tell which of the five changes caused it. Small diffs keep each review short enough to do well, and they keep the causal chain clear. If change four broke something, you know exactly where to look.

This also suits the way clients like to see progress. A sprint whose history reads as a sequence of small, sensible, described commits is easy to explain at a Friday demo and easy for the client's own developers to understand after you leave. Ask Claude Code to write clear commit messages that explain why each change was made, not just what changed. That history becomes documentation in its own right: a readable account of what you did and why.

Small steps are not slow. They are the fastest way to arrive somewhere you can still find your way back from.

Fast loops depend on fast verification, which is the subject of the next chapter. If running the checks takes ten minutes, the rhythm breaks and you will be tempted to batch again. Part of setting up an engagement is making sure there is a quick way to verify each change: a focused test command, a script that exercises the relevant path, a simple check the agent can run in seconds. Time invested in a fast feedback loop on the first day pays back on every cycle that follows.

Try this rhythm for a whole day on your next coding task. Before each request, ask yourself whether it contains more than one concern. If it does, split it. After each change, insist on a verification step and a commit before moving on. At the end of the day, read your commit history. If it tells a clear story a stranger could follow, the rhythm worked. If it reads like a series of panicked saves, you were batching. Most people find the first version less tiring, too.

Let It Run the Tests

An agent that can run its own verification stops guessing. Give Claude Code the command to run the tests and it will make a change, run them, read the failures, adjust, and run them again until they pass, without you acting as a message relay between the agent and the terminal. This one capability turns an assistant that suggests code into an agent that delivers working code, and it is the foundation of fast, reliable delivery.

The first job on any repository engagement is therefore to establish how verification works. Is there a test suite? Does it run? How long does it take? Is there a quicker way to run just the relevant tests? Put the answers in the memory file, so the agent knows them from the start of every session. If the tests are broken, fixing them may be the first small task of the engagement, and it is worth doing, because every subsequent task depends on it.

Many small-business codebases have no tests at all. That is not a reason to give up on verification; it is a reason to create some. Before changing existing behaviour, ask Claude Code to write tests that capture what the code currently does, run them to confirm they pass, and then make the change. The tests become a safety net for your work and an asset for the client. Where automated tests are impractical, a small script that exercises the feature and prints the result is far better than nothing. The principle is that the agent should have a way to check its work that does not depend on its own opinion.

Ask for evidence, not reassurance. When the agent reports that something works, ask to see the test output. An agent that says all tests pass and one that shows the output where all tests pass are making different claims, and only one of them is evidence. In client work this matters a great deal: you will be reporting results to people who are trusting you, and you want every claim you make to rest on something you have seen.

A test the agent can run is a mirror. Without one, it is only admiring its own reflection in your trust.

Verification also defines done for each task. Fix the date bug is vague. Fix the date bug so that the test in the reports module passes and no other tests break is checkable. Writing tasks this way makes the agent more effective and makes your own review faster, because you know exactly what to look for. It also gives you clean material for the client update: the bug, the fix and the proof.

On your next coding task, start by confirming the test command works and putting it in the memory file. Then phrase every request with a verification step attached, and ask to see the output before accepting any claim of success. If there are no tests, make writing them the first task. It will feel slower for a day. After that, everything will be faster, and you will never again have to wonder whether something works.

Git Is the Undo Button

Commit before you let an agent loose. A clean working tree turns every bad session into a two-second reset instead of a forensic recovery. Version control has always been good practice; with an agent making changes quickly across many files, it becomes the most important safety net you have. On a client's codebase, where your mistakes are their problem, it is not optional.

The routine is simple. Before starting a task, make sure everything is committed. Let the agent work. Review the changes with a diff. If they are good, commit them with a clear message. If they are not, discard them and start again with a better instruction. Because each task starts from a clean state, a bad result costs you only the time of that task, never the work that came before it. Claude Code also keeps its own checkpoints within a session, so you can rewind to an earlier point in the conversation, but git is the record that survives the session and the one the client's team will see.

Branches make this safer still. Do your work on a branch, not on the client's main line, and merge only when the change is reviewed and verified. Many clients will want to review changes before they reach production, and a branch with a pull request is the natural shape for that. Even if the client does not ask, work this way. It costs nothing and it protects everyone.

When you are running several pieces of work at once, worktrees help. A git worktree is a separate working directory attached to the same repository, on its own branch. Two Claude Code sessions in two worktrees can work on two features in parallel without stepping on each other's files. For a micro-consultant juggling a bug fix and a small feature for the same client, or running an experimental approach beside a safe one, this is a tidy way to avoid confusion. Each worktree is its own clean room.

The cheapest insurance in agentic work is a commit made thirty seconds before you needed it.

Agree the rules with the client at the start. Which branch to work on, who reviews and merges, whether you may push directly or only via pull request, and what must never be committed: credentials, personal data, large binary files. Put the essentials in the memory file so the agent follows them too. Clients who have had bad experiences with contractors will be reassured by seeing these rules written down and followed. Clients who have not will simply never have a bad experience with you.

Make it a reflex this week. Before every agent task, check the working tree is clean. After every task, review and commit or reset. If you are running parallel work, try a worktree for the second strand. It will feel fussy for a day or two. After that it will feel like wearing a seatbelt, unremarkable and quietly essential, and you will be faintly alarmed by people who work without one.

Custom Slash Commands

Any workflow you run twice in Claude Code should become a command. Claude Code lets you save a prompt as a reusable command that you, or anyone on the team, can trigger with a slash and a name. Over the course of an engagement, a client's repository can grow a small private toolkit shaped exactly like the way their team actually works. That toolkit is useful during your engagement and valuable long after it.

Think about the tasks that recur in a typical small codebase. Reviewing a change before it is merged. Preparing a release with a changelog. Generating a weekly report from a data export. Onboarding a new developer by explaining the architecture. Each of these involves a fairly standard set of instructions, the same checks and the same output format, every time. Writing those instructions once, testing them and saving them as a command means nobody has to remember them again.

Commands can take arguments, so a single command can serve many cases: review this branch, report on this month, explain this module. They can also be shared through the repository, so everyone who works on the project has the same set. That shared set quietly standardises how the team works with the agent. Instead of five people writing five versions of a review prompt, of varying quality, everyone uses the one that has been tested and improved.

In recent versions of Claude Code, commands and skills have moved closer together, and much of what was once a simple command can now be packaged as a skill that also loads itself when relevant. The next part covers skills in depth. The practical lesson is the same either way: recurring work deserves a named, reusable, shared form, not a fresh prompt typed from memory each time.

A team's command list is a portrait of how it works. Make sure the portrait is flattering and accurate.

For micro-consultants, commands are an excellent handover item and a natural micro-engagement in their own right. A short engagement to identify a development team's recurring tasks, write and test a command for each, and train the team to use them is easy to scope, quick to deliver and immediately useful. It also introduces a team to the idea of encoding their workflows, which is the doorway to larger engagements involving skills, automation and agents.

Look at your own work this week and find two things you have asked Claude Code to do more than once with roughly the same words. Turn each into a command, with a clear name and a short description of when to use it. Then use them for a week and refine them. When you next start a client engagement, keep a running list of anything the team asks for twice. By the end of the sprint that list is a toolkit, and the toolkit is a deliverable the client did not know to ask for.

Connectors as Hands

For a long time the reasoning was not the bottleneck. A model could work out what needed to be done; it simply could not reach the systems where the doing happened. Connectors change that. Through the Model Context Protocol, an open standard for connecting AI applications to tools and data, Claude can read tickets, query databases, check calendars, search document stores and update records. A code assistant becomes something closer to an operator, and an operator can deliver a very different class of micro-engagement.

The Model Context Protocol, usually shortened to MCP, defines a common way for tools and data sources to present themselves to a model. Many popular services now offer connectors, and for those that do not, a small custom server can expose exactly the capabilities you want. In Claude Code, you add servers to a project, and the agent can then use their tools alongside its built-in ones. In Claude's apps, connectors bring the same reach to everyday work.

For consulting, the interesting engagements often sit precisely at this junction. A support team whose assistant can look up the customer's order before drafting a reply. An operations manager whose agent can read the project tracker and write the weekly status summary. A developer whose session can check the error-tracking service and the relevant code at the same time. None of these require exotic engineering. They require knowing which systems matter, connecting them safely and writing the instructions that tell the agent how to use them.

Safety is the heart of the craft. A connector grants real capabilities in real systems, and the principle of least privilege applies with full force. Give read access where read access is enough. Scope write access tightly, to specific actions. Use accounts and credentials created for the purpose, not someone's personal login. Keep a human approval step for anything that sends, spends or deletes. Remember that content fetched from external systems is data, not instructions; a document or email retrieved by a tool may contain text that tries to steer the agent, and the system should be designed with that in mind.

Reach without limits is not capability. It is an incident waiting for a date.

This is also a place to be clear with clients about what you are and are not doing. Connecting an agent to their systems is a change to their security posture. Document which connectors you set up, what each can do, which credentials they use and how to revoke them. Put that in the runbook. A client who can see exactly what the agent can reach, and how to switch it off, is a client who will trust you with the next, larger connection.

This week, pick one system you consult constantly during your own work, a tracker, a document store, a calendar, and connect it to Claude with the narrowest permissions that are useful. Use it for a few days and notice which tasks change. Then imagine the same change for a client's team. That picture, described clearly, is the pitch for your next engagement.

Headless in CI

The same agent that helps you interactively can run unattended. Claude Code can operate in a non-interactive mode, given a prompt and a set of permissions, and return its result without anyone at the keyboard. Put that into a continuous integration pipeline and every pull request can be reviewed, every release can get a draft changelog, and every failing build can get a first diagnosis, automatically. For a small development team, this is a micro-engagement with a very clear before and after.

The most common starting point is automated review. When a pull request opens, the pipeline runs Claude Code with instructions to review the diff against the team's conventions, check for common problems and leave comments. It does not replace human review. It catches the things humans skim past: the missing test, the inconsistent naming, the error that is swallowed silently, the change to an interface that has callers elsewhere. Human reviewers can then spend their attention on the questions that need judgement. There is an official GitHub integration for Claude Code that makes this kind of setup much simpler than building it from scratch.

Other uses follow naturally. Drafting release notes from the commits since the last tag. Triaging new issues by labelling them and suggesting which part of the code they concern. Updating documentation when an interface changes. Running a scheduled check that summarises dependency updates. Each is a small, well-bounded task that runs without supervision and produces something a human reviews. That is the pattern to look for: repetitive, checkable, low-risk if wrong, and useful if right.

Unattended runs need tighter guardrails than interactive ones, because nobody is watching each step. Restrict the tools the agent may use to what the task requires. Give it the narrowest credentials possible. Have it comment or propose rather than merge or deploy. Treat the content of pull requests and issues as untrusted input, because anyone who can open a pull request can put text in front of the agent. These precautions are not elaborate, but they must be deliberate.

An agent that reviews every pull request will not catch everything. It will, however, never be too busy, which is more than can be said for the rest of the team.

As an engagement, this is attractive to sell and to deliver. It can be scoped tightly: set up automated review and release notes for one repository, tune the instructions on the team's real pull requests for a week, document how it works and how to adjust it, and hand over. The outcome is visible on every pull request from the first day. It also creates a natural follow-on, because once a team sees an agent doing useful work unattended, they start to imagine what else it could do.

Try this on a repository you control this week. Set up a non-interactive review run on pull requests with conservative permissions, tune the instructions on a handful of real changes, and see what it catches. You will learn what good instructions for unattended work look like, and you will have a demonstration ready for the next development team that asks what AI could do for them.

The Workflow Fix

Put this part together and you have one of the core micro-engagements of the book: the workflow fix. One painful, recurring workflow, diagnosed, fixed with Claude Code, verified and handed over, inside a fixed scope and a short calendar. Not a transformation programme. Not a platform migration. One workflow that currently wastes hours every week, made to waste minutes instead.

Good candidates are everywhere once you look. The monthly report someone builds by hand from three exports. The script that only one person knows how to run, and which fails if the input file has an extra column. The enquiry form whose submissions are copied into a spreadsheet and then emailed to the right person by whoever notices. The data clean-up that happens every Monday morning. Each is small, specific, measurable and painful enough that the client will happily pay to be rid of it.

The engagement follows the moves in this part. Diagnose first, on a short call and by watching the workflow being done. Read the repository, or the scripts and spreadsheets that make up the current process. Write a memory file. Plan the change and check the plan with the client's technical contact. Build it in small diffs with verification at every step. Connect only the systems that are necessary, with the narrowest permissions. If it suits, add a command or an unattended run so the workflow can be triggered easily or run on a schedule. Then hand it over with a runbook, a short recorded walkthrough and a session with the person who will own it.

The measurement matters as much as the build. Before you start, time the current workflow, or ask the client to estimate it honestly, and note how often it goes wrong. After handover, measure again. The difference, expressed in the client's terms, hours per month, errors per quarter, days of delay avoided, is the result you report and the evidence for your next engagement. A fixed workflow with no measured result is a nice favour. A fixed workflow with a before and after is a case study.

Fix one thing properly and the client will show you the other nine.

Scope discipline is everything. The workflow fix works because it is one workflow. When the client sees how well it went and asks about the adjacent process, that is excellent news, and it is the next engagement, not an extension of this one. Write it on the list. Mention it in the closing demo. Quote it separately. A string of small, finished, measured fixes builds far more trust than one sprawling project that never quite ends.

This week, write the one-page description of your own workflow fix offer: what kind of workflows it suits, what the client provides, what you deliver, how long it takes, how success is measured and what typically comes next. Then look around your own practice for a workflow you could fix as a practice run. The first one you fix will teach you more about scoping than any chapter can.

Skills Beat Prompts

A prompt is a message. A skill is a capability. The difference is that a prompt has to be found, copied and pasted every time you need it, while a skill sits in the background and loads itself when the task calls for it. The moment you paste the same instructions into Claude for the second time, you needed a skill. By the fifth time, you have been doing the tooling's job by hand.

In Claude's world, a skill is a folder containing a short instruction file, with a name and a description at the top, plus any supporting material it needs: reference documents, templates, examples, scripts. Claude sees the names and descriptions of available skills and, when a task matches, reads the full instructions and follows them. Skills work across Claude's apps, Claude Code and the developer platform, so the same capability can travel with you, and with your clients, from one surface to another.

The practical effect is that expertise stops depending on memory. Consider a consultant who writes audit reports in a particular structure, with a ranked opportunity table, a risk note per item and a parked list. As a prompt, that structure lives in a document they must remember to paste. As a skill, it loads whenever they ask Claude to write an audit report, complete with the template, a good example and the scoring rubric. The instructions are applied consistently, whether it is their first report of the week or their fifteenth, and whether they remember the details or not.

Skills also change what a consultant can hand over. A prompt library is helpful, but it depends on people using it correctly. A skill library is closer to a set of trained colleagues: the client's team asks for a supplier summary or a compliance check in plain language, and the right instructions arrive automatically. The expertise you encoded is applied without anyone needing to know it exists. That is a step change in how much of your value survives after you leave.

A prompt is advice you have to remember to take. A skill is advice that turns up on time.

Not everything needs to be a skill. One-off questions, exploratory conversations and tasks that are genuinely different each time are fine as plain prompts. Skills earn their place on recurring work with a stable shape: reports, reviews, analyses, document types, checks, transformations. A good test is whether you could write down what excellent looks like for this task and have it hold for the next twenty instances. If you could, it is a skill waiting to be written.

This week, go back to your prompt library from Part Two and find the three prompts you use most. Turn one of them into a skill: a folder, an instruction file with a clear name and description, and the examples and templates it needs. Use it for a week. Notice whether it fires when you expect, and whether the output is as consistent as you hoped. The next few chapters cover how to make both of those reliable. The first step is simply to stop pasting.

The Trigger Description

A skill that never fires is worthless. The instructions inside it can be immaculate, the templates beautiful and the examples perfectly chosen, but if Claude does not recognise when to use it, none of that matters. The description at the top of the skill file is what Claude reads to decide, which makes it the most important text in the whole skill. It is not documentation. It is the trigger.

Think about how the decision is made. Claude sees the descriptions of the skills available to it, alongside the user's request. If a description clearly matches what the user is asking for, the skill is loaded. If it is vague, generic or phrased in terms the user would never use, the skill sits unused. The description has to bridge the gap between how you think about the skill and how people will actually ask for the thing it does.

So write descriptions in the language of requests. Say what the skill does and when to use it, then include the exact phrasings, synonyms and adjacent asks that should wake it up. A skill for drafting audit reports might mention audit reports, AI readiness reviews, opportunity assessments and requests like write up the findings from the interviews. A skill for supplier summaries might mention vendor briefs, supplier one-pagers and what do we know about this supplier. Real users say things in many ways. The description should anticipate most of them.

Equally important, say when not to use the skill. If two skills cover neighbouring territory, each description should make the boundary clear: this one is for initial audits, the other is for progress reports. Ambiguous overlaps lead to the wrong skill firing, which is in some ways worse than none, because the output will be confidently shaped for a different task.

The description is the front door. Nobody admires the furniture in a house they cannot find.

Test triggering deliberately. Write a list of ten or fifteen requests that should invoke the skill, phrased as different people would phrase them, and a few that should not. Try them. Note which ones miss and adjust the description until most of them land. This takes perhaps half an hour per skill and makes the difference between a library that works and one that people abandon after a week because it is unreliable.

For client work, involve the people who will use the skill in this testing. Ask them how they would naturally request the task, and use their words in the description. A finance team might say month-end pack where you would have written financial summary report. If the description uses your vocabulary instead of theirs, the skill will fire for you during the demo and fail for them afterwards, which is the worst possible order of events.

Take the skill you wrote after the last chapter and rewrite its description with this in mind. List the ways you, and others, actually ask for that task, and work them in. Then test it with a dozen varied requests. You will probably find a few misses. Fix them, and the skill moves from an interesting experiment to a tool that shows up when it is needed, which was the whole point.

Progressive Disclosure

Context is finite, and skills should respect that. A skill that dumps forty pages of instructions into the conversation every time it fires crowds out the material the task actually needs. The better design is progressive disclosure: a short core file that covers what almost every use requires, with detailed references kept in separate files that the model reads only when a particular situation calls for them. Instructions, in other words, should be lazily evaluated.

Skills are built for this. Only the name and description are visible until a skill is triggered. Then the main instruction file is read. Within that file, you can point to other files in the skill's folder: for regulated financial clients, read the compliance reference before drafting, if the user asks for a slide version, follow the template in the slides guide. Those files are only read when the condition applies. A simple request uses the core instructions; an unusual one pulls in exactly the extra detail it needs.

This design has several benefits. It keeps the context lean, so the model attends properly to the task in front of it. It makes the skill easier to maintain, because each reference file has a single purpose and can be updated independently. And it lets a skill grow to cover many cases without becoming unwieldy, because the cases live in their own files rather than piling up in one long document that nobody wants to read.

Writing a good core file is a discipline. Put in what applies every time: the purpose, the main steps, the output format, the quality bar. Leave out anything that applies only sometimes, and replace it with a clear pointer. Keep it short enough that you could read it in a couple of minutes. If the core file keeps growing, look for sections that only apply in particular circumstances and move them into references.

Tell the model what it always needs. Tell it where to look for the rest. Then trust it to look.

This structure suits consulting work especially well, because client engagements vary in predictable ways. A core skill for writing audit reports might have references for different sectors, different report lengths and different audiences. One skill, many situations, with the right detail arriving in each. When you specialise in a vertical, the sector reference becomes a concentrated record of everything you have learned about that kind of client, loaded only when it is relevant.

It also makes handover cleaner. A client receiving a skill library can see at a glance what each skill does from its core file, and can find and update the specific reference that needs changing when their business changes, without disturbing the rest. A skill organised this way is easier to understand, easier to trust and easier to own.

This week, look at your longest skill or prompt. Mark each section as always needed or sometimes needed. Move the sometimes sections into separate reference files with a clear pointer in the core. Run it on a simple case and an unusual one. The simple case should be faster and cleaner; the unusual one should still get the detail it needs. That is the design working.

Bundle the Scripts

Deterministic work belongs in code, not tokens. If a step in a task always works the same way, converting a file format, validating a data structure, calculating a total, renaming files to a pattern, it should not be re-derived by the model every time. Ship a script inside the skill and let the model call it. The model supplies judgement; the script supplies precision. Each does what it is good at.

Skills can include executable scripts alongside their instructions. When the skill runs in an environment where code execution is available, the instructions can tell Claude to run a particular script for a particular step: to check the export is valid, run the validation script and report any errors, to produce the final spreadsheet, run the build script with the cleaned data. The script's code does not need to sit in the conversation; only its output does, which keeps the context lean as well.

The advantages are considerable. Scripts are reliable: the same input produces the same output every time, without any chance of a creative interpretation. They are fast and cheap, because running a few lines of code costs far less than having a model reason through the same transformation. They are testable in the ordinary way. And they encode precise logic, such as a specific calculation rule or a strict file format, which is exactly the kind of thing a model may approximate rather than reproduce.

For consultants, this changes what a skill can deliver. A skill that produces a client's monthly report can include a script that pulls the figures from an export, calculates the agreed metrics and builds a chart, while the model writes the commentary and flags anything unusual. A skill that checks contracts against a policy can include a script that extracts the clauses into a structured format before the model reviews them. The combination is more reliable than either part alone, and much more reliable than asking the model to do everything in prose.

Let the model decide what to do. Let the code do the parts that must be done exactly the same way every time.

Claude can write the scripts too, of course. A sensible pattern is to watch the model perform a task a few times, notice which steps are mechanical, and ask it to write a script for those steps, with tests. Then update the skill to call the script. Over time, your skills accumulate small, well-tested tools that make them faster and more dependable with every engagement.

A note of caution for client handovers: scripts are code, and code needs an owner. Document what each script does, what it needs to run and how to test it. Keep dependencies minimal. If the client's team cannot maintain code, prefer simpler scripts and make sure the skill fails clearly, with a helpful message, if a script breaks. A skill that silently produces wrong results because a script failed is worse than one that does not try.

This week, find a step in one of your recurring tasks that is purely mechanical. Ask Claude to write a small script for it, with a test, and bundle it into the relevant skill. Run the task again. Notice how much more consistent that step becomes. Then look for the next one.

Subagent Fan-Out

Some work splits naturally into independent pieces. Review twelve supplier contracts. Summarise interviews with eight staff members. Analyse five years of support tickets, one year at a time. Doing these in a single long conversation fills the context with detail from every piece, so by the time you reach the last one, the model is wading through everything that came before. The better pattern is fan-out: hand each piece to a subagent with a clean context, and have an orchestrator collect the results.

In Claude Code, subagents are specialised assistants that the main agent can delegate tasks to. Each runs in its own context, with its own instructions and its own set of permitted tools, and returns a summary rather than its full working. The main conversation keeps the plan and the results, not the noise. You can define custom subagents for recurring roles, a contract reviewer, an interview summariser, a test writer, each with a focused brief.

The pattern suits audit work particularly well. During a paid audit, you might have a dozen interview transcripts and a pile of process documents. Fan the transcripts out to subagents, each producing a structured summary in the same format: themes, pain points, quotes, suggested opportunities. Then have the orchestrator, or you, synthesise across the summaries. Each transcript gets full attention; the synthesis gets a clean view of all of them. What used to be days of reading becomes an afternoon of review.

The key to good fan-out is a consistent brief for the workers and a consistent shape for their output. If each subagent returns its summary in a different structure, synthesis becomes harder rather than easier. Define the output format precisely, ideally with an example, and make it the same for every worker. Give each worker only the context it needs for its piece, plus any shared background, and nothing else.

One agent holding everything is a juggler. An orchestrator with workers is a kitchen. Kitchens serve more people.

There are costs to weigh. Each subagent consumes its own resources, so fanning out trivial tasks is wasteful. Parallel work also produces parallel mistakes: if the brief has a flaw, every worker inherits it. Test the brief on one piece before sending it to twelve. And keep the synthesis step, whether it is done by the orchestrator or by you, honest about disagreements and gaps between the workers' outputs, rather than smoothing them into a falsely tidy conclusion.

For clients, fan-out is often invisible but its effects are not. It is what lets a two-week engagement handle a volume of material that would once have needed a team. It also appears in the systems you build: an agent pilot that processes a batch of documents might use exactly this pattern under the hood. This week, find a task in your own work that splits into independent pieces. Write one brief, test it on one piece, then fan it out. Compare the result, and the time it took, with doing it all in one conversation.

The Verifier Subagent

One agent builds; a second one checks, with fresh eyes and no attachment to the work. Self-review is weak, for models and for people. The author of a piece of work knows what they meant and reads that into what they wrote. A reviewer with a clean context and a clear rubric sees only what is actually there. Adversarial review by a separate context is one of the most effective quality moves available to a solo practitioner.

The pattern is simple to set up. When a substantial piece of work is finished, a report, a set of code changes, a batch of processed documents, hand it to a separate subagent whose only job is verification. Give it the original brief, the definition of done and a rubric, and ask it to find problems: claims not supported by the source, requirements missed, inconsistencies, edge cases not handled, tests that pass for the wrong reason. Ask it to be specific and to cite evidence. Then review its findings yourself and decide which to act on.

The verifier's independence is the point. It should not see the builder's reasoning or the conversation that produced the work, only the work and the criteria. That way it cannot be persuaded by the builder's justifications. It judges the output on its merits. In practice it often catches things that both the builder and you missed, because neither of you could unsee what you intended.

For consulting deliverables, this is cheap insurance against the most embarrassing kind of failure: a confident claim in a client report that turns out to be wrong. Run every important document through a verifier with an instruction to check each factual claim against the source material provided and flag any that are not supported. Run every significant code change through a verifier with the tests, the requirements and an instruction to look for what the tests do not cover. The verifier will sometimes raise false alarms. That is a small price.

The builder wants the work to be good. The verifier only wants to know whether it is. You need both, in separate rooms.

Verifiers can also be part of the systems you deliver. An agent pilot that drafts customer replies can include a verification step that checks each draft against the policy before a human sees it, flagging any that need closer attention. That makes the human review faster and more focused, and it gives the client a measurable quality layer they can see working. It also makes acceptance testing easier, because the verifier's rubric doubles as the acceptance criteria.

Be honest about limits. A verifier built on the same model may share some of the builder's blind spots, and it cannot check facts it has no access to. It is a second line of defence, not a guarantee. Your own review, and the client's, remain essential for anything that matters. This week, take the next substantial thing you produce and hand it to a fresh verifier with a rubric and an instruction to find problems. Read what comes back with an open mind. You may be slightly annoyed. You will almost certainly be better off.

One Skill, Many Harnesses

A skill you can run in only one place is a clever trick. A skill you can run in the desktop app, in Claude Code, in an automated pipeline and through the developer platform is an asset that compounds. Portability is what turns a well-written prompt into infrastructure, and it is increasingly achievable because skills share a common format across Claude's surfaces.

Consider how a single skill might travel through an engagement. You write a skill that produces a client's weekly operations summary from a set of exports. During the build sprint, you run it in Claude Code while you develop and test it. The client's operations manager uses it in the Claude app on Monday mornings. Later, it runs in an automated job that produces the summary before anyone arrives at work. Same instructions, same templates, same scripts; three very different ways of invoking them. Each improvement you make reaches all three.

Writing for portability takes a little care. Keep the instructions independent of any one interface: do not assume a particular button or a particular command exists. Make scripts work in a standard environment with minimal dependencies. Describe inputs and outputs explicitly, so the skill works whether a person supplies the files in a chat or a pipeline supplies them automatically. And note any environment-specific requirements, such as code execution or network access, at the top, so whoever installs the skill knows what it needs.

This matters commercially as well as technically. A client buying a skill library wants it to keep working as their use of AI matures. Today their team might use the Claude app; in a year they might have automated half their reporting. Skills written for portability move with them. Skills hard-wired to one surface have to be rewritten, which is either a cost to the client or, if you built them badly, a quiet embarrassment for you.

Write it once, run it wherever the work happens. Anything else is a rewrite you have scheduled without noticing.

There are limits, of course. Some capabilities are only available in certain environments, and some tasks only make sense interactively. Not every skill needs to run everywhere. The aim is to avoid accidental lock-in, where a skill only works in one place because nobody thought about the others, not to force every skill into every harness regardless of sense.

Portability also benefits your own practice. Your personal skills, the audit report writer, the proposal drafter, the case study builder, are more useful if they work wherever you happen to be: at your desk in the app, in a terminal during a coding engagement, or on your phone between meetings. This week, take one of your skills and try it on a second surface. Note what breaks, fix it so it works in both, and write down the requirements at the top of the skill file. The second surface is the hardest. After that, the rest tend to follow.

Version Your Canon

Skills drift. You improve one on your laptop, forget to copy the change to the shared folder, tweak a different copy for a client, and three weeks later you have three versions of the same skill, each slightly different, none of them clearly the latest. When something goes wrong, you are debugging three different truths. The cure is unglamorous and entirely effective: put your skills in version control, treat one repository as the canon, and sync from it deliberately.

Git is the obvious home. Each skill is a folder; the repository holds them all. Every change is a commit with a message explaining why. Releases can be tagged, so you can say with certainty which version a client is running. When a change makes things worse, you can see exactly what changed and roll it back. This is basic software practice, and it applies to skills because skills are, in every important sense, software: instructions and code that other people and systems depend on.

The canon also gives you a clear process for distribution. Rather than copying skills by hand to each place they are used, you sync from the repository: to your own machines, to the shared skill locations for your team, to each client's environment. Plugins can bundle skills, commands and other extensions into a package that installs consistently. Whatever mechanism you use, the principle is the same. Changes flow outwards from one source. Nobody edits a deployed copy and leaves it there.

Client skill libraries deserve their own repositories, separate from yours. A client's skills contain their context, their examples and sometimes their confidential processes. They should live where the client controls them, with your general-purpose skills supplied as a separate, versioned dependency if needed. That separation protects the client's information, keeps your own canon clean and makes it obvious what belongs to whom when the engagement ends.

If you cannot say which version is running, you do not have a skill. You have a rumour.

A changelog helps everyone. A short note at the top of each skill, or in the repository, recording what changed in each version and why, makes it easy for a client's team to understand updates and easy for you to remember why a particular line exists. It also supports the retainer conversation: a monthly list of improvements to the client's skills is a tangible record of ongoing value.

There is a testing angle too. Each skill can carry a small set of test cases, inputs and expected qualities of output, that you run before tagging a new version. When a new model becomes available, run the tests across your whole canon and see which skills improve, which stay the same and which need adjustment. That is how you turn model upgrades into improvements rather than surprises.

This week, if your skills are not yet in a repository, put them there. One folder per skill, a short changelog, a first tag. Then pick one place you use skills and make it sync from the canon instead of holding its own copy. It is a dull afternoon. It will spare you a great many confusing ones.

Skills as Deliverable

Clients pay for outcomes, but they keep assets. A report describes what could be done. A prompt kit helps people do it. A skill library does a good part of it for them, every time, in their language, to their standard. Handing over a working skill library is worth more than any report, and it is a different kind of deliverable altogether: not advice about the work, but a durable capability that performs it.

A skill library engagement usually starts where an audit or prompt kit leaves off. The audit identified recurring tasks; the prompt kit gave the team better ways to ask for them. The skill library encodes the best of those tasks as skills: each with a trigger description in the team's own words, core instructions, references for unusual cases, examples of excellent output, bundled scripts for mechanical steps and test cases for quality. The team then asks for the work in plain language and gets output that meets the standard they agreed with you.

The delivery follows the patterns in this part. Start with the five or ten most valuable recurring tasks, not every task you can think of. For each, gather real examples and the client's definition of good. Write the skill, test its triggering with the people who will use it, test its output against real inputs, and refine. Put the library in a repository the client controls, with a changelog and a short guide. Train the team, and name an internal owner who can make small changes and knows when to call you for larger ones.

Pricing shape matters here, as Part Eight discusses. A skill library is an asset that will save time every working day, and it should be priced against that value, not against the hours it took you to write it. Some consultants also offer a small ongoing arrangement to maintain and extend the library as the business changes and models improve. That is honest work, because skills do need care, and it turns a one-off delivery into a relationship.

A report gets read once. A skill gets used every morning. Price accordingly, and deliver accordingly.

There is a question of ownership to settle at the start. The client should own the skills built from their context and examples. You may want to retain the right to reuse general techniques and generic skills you brought to the engagement. Say so clearly in the agreement. Most clients are entirely comfortable with this arrangement when it is explained up front, and nobody is comfortable when it comes up for the first time at handover.

A skill library is also excellent evidence. Each skill can be demonstrated, its output shown and its time saving measured. A case study that says we built eight skills that the team now uses daily, cutting report preparation from a day to an hour is concrete, credible and easy for the next prospect to imagine in their own business.

This week, imagine your most recent engagement had ended with a skill library instead of whatever you actually delivered. Which five skills would it contain? Write the names and descriptions. If they come easily, you have just designed your next offer.

The Agent Pilot

The agent pilot is the most ambitious micro-engagement in this book, and the one clients ask about most. They have heard that agents can do work, not just answer questions, and they want to know whether one could do some of theirs. The pilot answers that question in a fixed time, on real work, with a measured result. Done well, it is the most persuasive engagement you can sell. Done badly, it is an expensive demonstration of why people distrust the word agent.

Choose the task carefully. A good pilot task is frequent, bounded and checkable. Triage incoming enquiries and draft first replies. Reconcile two data sources and report discrepancies. Process a batch of supplier documents and extract key terms into a register. Each has clear inputs, a clear output and a way to tell whether the output is right. Avoid tasks where errors are costly and hard to detect, or where success depends on judgement the client cannot articulate. Those come later, if at all.

Run the pilot on real work from the recent past, not hypothetical cases. Take a sample of last month's enquiries, documents or records, with the client's permission and appropriate data handling, and let the agent process them. Compare its output with what the team actually did, using a rubric agreed with the client in advance. This gives you a fair, specific, measurable picture: how often the agent was right, where it went wrong and how much time it would have saved. Then, if the results justify it, run it in parallel with live work for a week, with a human approving every output.

Everything in this book comes together here. A clear brief and constrained output from Part Two. Curated context and project knowledge from Part Three. Careful work in the repository from Part Four. Skills, scripts, subagents and a verifier from this part. Guardrails, human checkpoints and evaluations from Part Seven. A pilot is not a single clever prompt. It is a small, well-engineered system with the client's real work flowing through it.

A pilot is an experiment with a hypothesis, a method and a result. Anything else is a demo with a longer invoice.

Define the decision the pilot supports before you start. The question is not do agents work? but something like can an agent draft acceptable first replies to most routine enquiries, with a human approving each one, reducing response time meaningfully? State the threshold that would justify going further. At the end, report honestly against it. Sometimes the answer is no, or not yet, and saying so clearly, with evidence, earns more trust than a stretched yes.

When the answer is yes, the next step is obvious and you designed it at the start: a retainer to run, monitor and improve the system, or a sprint to extend it. This week, sketch an agent pilot for a client you know: the task, the sample, the rubric, the threshold, the guardrails. If you can fit it on one page, you can sell it. If you cannot, the pilot is too big. Shrink the task until it fits.

The Demo Is the Deck

A working prototype closes deals that slides can only describe. Show a buyer a deck about how an assistant could triage their enquiries and they nod politely and ask about security. Show them the assistant triaging five of their own enquiries, on a screen, while they watch, and the conversation moves from whether to when. People believe what they see far more readily than what they are told, and with Claude, showing is now cheap enough to do before you are paid.

This is a genuine shift in the economics of selling. A few years ago, building a convincing prototype took days of a developer's time, which meant you could only afford it after a client had committed. Now a single-page interactive prototype, a small working script, or a realistic sample of output can be produced in an hour or two. The cost of showing has fallen below the cost of explaining. Most consultants have not yet adjusted their sales process to match.

The prototype does not need to be complete. It needs to answer the buyer's real question, which is usually some version of would this work for us? That means it should use their kind of data, their vocabulary and their workflow, even if only one path through it works. A demo that processes a realistic version of their invoices is far more persuasive than a polished generic demo that processes somebody else's. Specificity is what makes it believable.

Use the demo as a diagnostic tool, too. As the buyer watches, they will react: that is exactly our problem, or that is not how we do it, or what happens when the supplier sends a scanned image. Each reaction is information about the real requirements, offered freely and enthusiastically, which is a rare combination. Write it down. Half your scope document will come from the comments a buyer makes while watching a prototype.

Slides ask the buyer to imagine. Demos let them recognise. Recognition is faster.

There are honest boundaries to keep. Never let a prototype imply that production is finished. Say clearly what is real, what is simulated and what would be needed to make it robust. A buyer who later discovers that the impressive demo was held together with sample data and good intentions will not trust your next estimate. A buyer who was told exactly what they were seeing will trust you more for having been straight with them.

This part of the book covers the craft of building and shipping these things: single-file prototypes, realistic data, clickable flows, focused artifacts, sharing them as links, turning them into leave-behinds, verifying them and, at the far end, building in the meeting itself. All of it serves the same principle. This week, take your next sales conversation and prepare a small demonstration instead of extra slides. Use the buyer's kind of data. Show one thing working. Then stop talking and watch their face. That is the moment the sale actually happens.

Single-File Prototypes

One file, no build step, runs anywhere you can open it. That constraint is the secret to fast prototypes. Setup time is where prototypes go to die: installing frameworks, configuring tooling, wiring up a database, deploying to a server. All of it is necessary eventually and none of it is necessary to answer the question a prototype exists to answer. A single file sidesteps all of it.

In practice, this means a single HTML page with its styles and scripts included, or a single React component that can be rendered as an artifact in Claude, or a single script that runs from the command line. Claude is very good at producing these. Describe the tool, the data it works with and the main interaction, and you will usually get a working first version in one response. Ask for changes conversationally. Within an hour you can have something that looks and behaves enough like the real thing to show a client.

Artifacts in Claude make this especially convenient. A prototype built as an artifact can be viewed, tried and refined in the same place you created it, and published as a page you can share. You can iterate with the client on a call: they suggest a change, you ask for it, the prototype updates while they watch. The constraint of a single file keeps each change quick and the whole thing easy to understand.

The discipline is to resist growing it. Once a prototype works, the temptation is to add features until it is nearly a product, still in one file, now several thousand lines long and impossible to maintain. That is a trap. A prototype's job is to answer a question and then be thrown away or rebuilt properly. When the client says yes and the real build begins, start the production version with appropriate structure, tests and deployment. Keep the prototype as a reference for what the client approved.

A prototype is an argument, not a foundation. Build it fast enough that throwing it away does not hurt.

For micro-consultants, the single-file habit has another benefit: it makes the prototype itself a portable deliverable. A client can open it, forward it, show it to their manager, without anyone needing to install anything. Many small engagements, a calculator, a decision tool, an internal dashboard over a fixed dataset, can be delivered as a polished single file and never need to grow beyond it. Do not underestimate how many business problems are solved by a well-made single page.

Constraints help Claude, too. A request to build a single-file tool with no external dependencies beyond a few well-known libraries produces focused, readable code. A request to build an application with no constraints produces something sprawling. Tell it the shape you want, and it will build to the shape.

This week, pick a small tool you have been meaning to build, for yourself or a client, and build it as a single file with Claude in one sitting. Time how long it takes. Most people are surprised, and slightly annoyed at how long they spent putting it off.

Fake Data, Real Feel

Realistic sample data makes a prototype persuasive. Placeholder text makes it a wireframe. The difference is not cosmetic. When a buyer sees a demo filled with customer names that look like their customers, products that look like their products and numbers in the range they deal with, their brain stops evaluating the tool and starts imagining using it. When they see Customer A, Product 1, 123.45, they stay in evaluation mode. Spend ten minutes generating data that looks like theirs.

Claude makes this almost effortless. Describe the client's business, the kind of records the tool will handle and the shape of the data, and ask for a realistic synthetic dataset: fifty enquiries of the kind a small accountancy firm receives, a year of orders for a specialist food supplier, a list of support tickets for a software company with a plausible mix of urgent and trivial issues. Ask for realistic variation, including a few awkward cases. The result looks real enough to make the demo credible without containing anything real.

That last point matters. Synthetic data is the right default for prototypes, especially before you have an agreement in place. Real client data brings data protection obligations, confidentiality questions and the risk of an embarrassing leak if a prototype is shared more widely than intended. Synthetic data that mirrors the shape and feel of the real thing gives you the persuasive benefit with none of those risks. Make it clear that it is synthetic, and the client will appreciate the care.

Awkward cases are where synthetic data earns its keep. A prototype that handles only clean, typical records will look good and teach nobody anything. Include the enquiry written in capital letters, the order with a missing postcode, the ticket that is actually two problems, the invoice in a foreign currency. Show how the prototype copes, or does not. The buyer will immediately recognise those cases from their own work, and their trust in you will rise because you clearly understand what real data looks like.

Lorem ipsum tells the buyer you have not thought about their business. Good fake data tells them you have.

There is a reusable asset here as well. If you specialise in a vertical, build a library of synthetic datasets for it: sample customers, typical transactions, common document types, frequent edge cases. Each new prototype starts from that library, tailored slightly to the specific client. Over time, your sample data becomes quietly authoritative, a portrait of the sector that buyers recognise at once.

When the engagement starts and real data becomes available under proper agreements, test the prototype against it promptly. Synthetic data, however good, will miss something. The real data will contain a pattern nobody predicted. Finding it early is cheap; finding it at handover is not.

This week, take any prototype or demo you have and replace its placeholder data with realistic synthetic data for a specific kind of client. Include five awkward cases. Show it to someone in that sector and watch whether they start talking about the tool or about their own work. If it is their own work, the data is doing its job.

Screenshot to Spec

A picture of the interface you want is worth a surprising number of words. Clients often struggle to describe what they need in text, but they can usually point at something: a screenshot of a tool they like, a photo of a whiteboard sketch, a page from a competitor's product, a spreadsheet layout they have been using for years. Paste the image into Claude, explain what it should do, and let the model write the implementation. Visual briefs collapse an entire round of design ambiguity.

Claude can read images well: layouts, labels, tables, hand-drawn sketches and annotated screenshots. Give it a screenshot of the client's current spreadsheet and ask for a simple web tool that does the same job with validation and a summary view. Give it a photo of a whiteboard with boxes and arrows and ask for a working prototype of that flow. Give it a screenshot of a dashboard the client admires and ask for one with the same structure, using their data and their brand colours. The first version will not be perfect, but it will be recognisably what they meant, which is the hard part.

This works well on calls. Ask the client to share their screen and show you how they do the task today. Take a screenshot, with permission. After the call, or during it if you are confident, use it as the brief for a prototype. The client sees their own process reflected back as a better tool, and the conversation becomes concrete immediately. That button should be here. That column is not needed. Can it sort by date? Each comment is precise because there is something precise to comment on.

Screenshots also help in the opposite direction. When you are reviewing a prototype with a client asynchronously, ask them to screenshot what they want changed and annotate it. A screenshot with a circle and the words make this bigger is far clearer than a paragraph of description, and Claude can act on it directly. The feedback loop shortens, and both of you spend less time interpreting each other.

People cannot always say what they want. They can nearly always point at it.

Mind confidentiality. Screenshots of a client's systems may contain customer names, figures or other sensitive information. Crop or blur what is not needed before sharing images with any tool, and make sure the tools you use are ones the client has agreed to. Treat screenshots with the same care as any other client data.

Also mind the line between inspiration and copying. Using a competitor's product as a reference for layout and flow is normal practice. Reproducing its distinctive design, branding or content is not. The aim is to capture what the client wants from the interface, not to clone someone else's work.

This week, the next time a client or colleague describes an interface in words, ask them to show you something instead: a screenshot, a sketch, a page they like. Use it as the brief. Compare the result with what you would have built from the description alone. You will rarely go back to text-only briefs for anything visual.

The Clickable Prototype

Half-real beats fully imagined. A prototype where three flows genuinely work and everything else is a clearly labelled stub answers more questions than any specification document ever will. Specifications describe intentions, and intentions are infinitely flexible. A working flow is stubborn: it either does what the client needs or it visibly does not, and that visibility is precisely what makes it useful.

Choose the three flows carefully. They should be the paths that matter most to the client's decision: the most common task, the most painful task and the task where the new approach differs most from the old one. For an enquiry triage tool, that might be routing a routine enquiry, handling an urgent complaint and dealing with an enquiry that does not fit any category. Make those three work end to end, with realistic data and real logic. Everything else, settings, reports, user management, can be a placeholder that says what it would do.

The working flows do the heavy lifting in conversations with the client. They can try the most common task themselves and judge whether it feels faster. They can see how the urgent case is flagged and decide whether the threshold is right. They can watch the awkward case and tell you what their team does in that situation today. These are the decisions that shape the real build, and they are made far more reliably with something clickable than with a document full of assumptions.

Stubs should be honest. Label them clearly, with a short note about what the finished version would do and roughly how much work it involves. This prevents the classic misunderstanding where a client sees a polished screen and assumes it works. It also gives you a natural way to discuss scope: here are the three flows we proved, here are the stubs, which of these matter for the first release and which can wait?

A specification is a promise about the future. A working flow is evidence about the present. Buyers prefer evidence.

With Claude, building a clickable prototype is fast enough to fit inside an audit or before a sprint begins. Start from the single-file approach, add the realistic data from the previous chapters, implement the three flows carefully and stub the rest. A day's work, often less, produces something that de-risks a two-week build considerably. Some consultants include a clickable prototype in every audit readout as a matter of course, so the top recommendation arrives not as a paragraph but as something the client can try.

Be careful not to let the prototype set expectations about effort. A flow that took an hour to prototype may take days to build robustly, with error handling, security, integration and testing. Say so. The prototype shows what the tool will do, not how long it takes to make it dependable.

This week, take an idea you have been describing in words and build three working flows with stubs for the rest. Show it to someone who would use it. Count the decisions they make in the first ten minutes. Then imagine how many meetings it would have taken to reach the same decisions from a document. That gap is what clickable prototypes are for.

One Artifact per Question

Resist the mega-app. When you build something for a client, the temptation is to make it comprehensive: a dashboard with nine tabs, every metric, every filter, every view anyone might ever want. It gets admired at the handover, bookmarked by everyone, and then quietly forgotten, because nobody can find the one thing they actually need in it. A focused artifact that answers exactly one business question gets used, every week, for years.

Start from the question, not the data. Which customers are at risk of not renewing this quarter? Which supplier invoices are overdue for approval? How did this week's response times compare with last week's? Each question has an audience, a frequency and a decision attached to it. Build a tool that answers that question clearly, for that audience, at that frequency, and makes the decision easier. Leave everything else out. If someone needs a different question answered, build a different artifact.

Focused artifacts are easier to build, test, explain and maintain. With Claude, each one is a short, contained piece of work: one data source, one view, one or two interactions. Each is easy to verify, because you know exactly what correct looks like. And each is easy to hand over, because its purpose is obvious from its title. A client with six small tools that each answer one question is much better served than one with a single tool that tries to answer all of them.

They also make excellent micro-engagements. A client with a question they cannot easily answer from their existing systems, which is most clients, can buy a focused tool that answers it. The scope is clear, the delivery is fast, and the value is obvious from the first use. A series of these, each tackling a different question, builds a relationship one small win at a time, which is exactly the pattern this book recommends.

A dashboard that answers everything answers nothing in particular. Build the one that answers Monday's question.

Name each artifact after its question. Renewal risk this quarter is a better title than Customer Analytics Dashboard, because it tells the user what they will learn before they open it. The naming discipline also keeps you honest: if you cannot name the artifact after a single question, it is probably trying to answer several, and should be split.

There is a design point here as well. When an artifact answers one question, its layout can be built around the answer: the key figure at the top, the supporting detail below, the action prompt at the bottom. When it answers many, the layout has to be built around navigation, which is why so many dashboards feel like menus rather than answers.

This week, look at any dashboard or report you or a client use regularly. Identify the one question people actually open it to answer. Build a single-purpose artifact that answers only that question, as clearly as possible. Put it beside the original and see which one gets opened next Monday.

A Link Beats an Attachment

A URL beats an attachment. Send a prototype as a file and it sits in an inbox, waiting for someone to download it, find the right application to open it and wonder whether it is safe. Send it as a link and the client can open it on their phone in a taxi, forward it to a colleague, show it to their manager in the corridor. It stops being a demo and starts being a thing that exists, and things that exist get talked about.

The tools for this are now ordinary. Artifacts in Claude can be published as private pages and shared with specific people. Simple static hosting services let you put a single-file prototype online in minutes. For code engagements, a preview deployment of a branch gives the client a link to the work in progress. Whatever the route, the aim is the same: put the work where the client can reach it with a single tap, on whatever device they happen to be holding.

Links change the feedback loop. A client with a link looks at the prototype more often and shows it to more people. Comments arrive sooner and from a wider group, including people you would never have met in the formal meetings. Sometimes those people are the actual users, who notice things the buyer did not. Sometimes they are the person who signs the budget, who now has a concrete reason to approve the next stage. A link travels through an organisation in a way an attachment never does.

Think carefully about access. A prototype with synthetic data can usually be shared fairly freely. One that touches real data needs proper access control: private by default, shared only with named people, behind the client's authentication if necessary. Never put real client data on a public link for convenience. The speed of sharing is a benefit only if the right people are the ones receiving it.

An attachment waits to be opened. A link is already open, in someone else's hand, being shown to someone you have never met.

There is a professional polish to this, too. A link to a clean, working prototype, titled with the client's name and the question it answers, signals competence more effectively than any capability statement. It says you build things and you finish them. For a micro-consultant, whose entire offer rests on fast, visible delivery, that signal is worth a great deal.

Keep track of what you have shared. A simple list of live links, with who has access and when each should be retired, saves confusion later. Prototypes left online indefinitely can cause problems: outdated versions being mistaken for current ones, or a demo being treated as a production tool. When an engagement ends, retire the prototype links or clearly mark them as historical.

This week, take something you would normally send as an attachment, a prototype, a report, a small tool, and share it as a link instead, with appropriate access settings. Notice how quickly the responses come back, and from whom. You may find people engaging with your work who would never have opened the file.

The Leave-Behind

Some people still want something they can hold, or at least something they can file. The board member who prints papers before meetings. The finance director who keeps a folder of every proposal. The client who wants to forward your findings to a parent company that does not accept links. For them, you need a leave-behind: a clean document that stands on its own after you have left the room. The good news is that you rarely need a separate design tool to make one.

A browser print stylesheet turns any web artifact into a tidy document. A few rules telling the page how to lay itself out when printed, hiding navigation and buttons, setting margins, avoiding page breaks in awkward places, using print-friendly colours, and the same artifact that works as an interactive tool prints as a professional report. Save it as a PDF from the browser and you have a leave-behind with no extra export pipeline and no extra dependency to maintain. Claude can write the print styles for you in a single request.

This matters for consultants because it collapses two deliverables into one. You no longer build a prototype and then separately write a report about it. You build one artifact that is interactive on screen and a document on paper. Audit readouts, case studies, proposals and handover guides can all work this way. The client gets a live version to explore and a static version to file, and they always match, because they are the same thing.

Design the printed version deliberately rather than as an afterthought. Put a clear title, the client's name and the date at the top. Make sure the most important content appears on the first page, for the reader who never turns over. Include enough explanation that the document makes sense without you there to narrate it. If the interactive version relies on hovering or clicking to reveal information, make sure that information is visible in print.

The meeting ends. The document stays on the desk, making your argument without you.

Leave-behinds are also durable marketing. A well-made audit summary or case study, printed or saved as a PDF, gets passed around inside the client's organisation and sometimes beyond it. It carries your name, your method and your results into rooms you will never enter. Make it something you would be proud for a stranger to read.

Keep the brand consistent and quietly professional. A simple, readable layout with your name and contact details in a footer is enough. Avoid heavy decoration that will look poor in black and white. Avoid putting anything in a leave-behind that would be awkward if forwarded to the wrong person, because sooner or later it will be.

This week, take an artifact you have built and add a print stylesheet. Print it, or save it as a PDF, and read it as a stranger would. Fix what does not stand on its own. Then make print styles part of your standard approach, so every artifact you deliver has a leave-behind built in from the start.

Verify Before You Claim

Never say it works until you have run it. Evidence before assertion is the difference between a trusted operator and one who quietly stops being called. In fast, AI-assisted delivery the temptation to claim success early is strong: the agent says the change is done, the code looks right, the demo is in ten minutes. Resist it. Run the thing. Look at the output. Then, and only then, say it works.

Models are fluent and confident, which is useful in many ways and dangerous in this one. An agent that has made a change will often report that it has worked, sometimes before actually checking, sometimes on the basis of a check that did not test the right thing. That is not dishonesty; it is the nature of the tool. Your job is to insist on evidence: the test output, the screenshot of the working page, the result of running the script on a real input. If the evidence is not there, the claim is not yet true.

This applies with special force to client-facing statements. When you tell a client that a workflow is fixed, a prototype handles their edge cases or an agent pilot achieved a particular accuracy, you are staking your reputation on the claim. One false claim, discovered later, undoes a great deal of good work. A habit of showing evidence, here is the run, here are the results, here is the case it got wrong, builds a reputation that is very hard to dislodge.

Make verification visible. In demos, run the thing live rather than showing a recording, where practical. In reports, include the evidence: the test cases, the scores, the before and after measurements. In status updates, distinguish clearly between what has been verified and what is still being checked. Clients notice the difference between a consultant who says it should work and one who says it works; here is the run.

Confidence is free. Evidence costs a few minutes. Only one of them survives contact with the client's real data.

Verification also protects you from yourself. The most dangerous moment in any delivery is when you are tired, the deadline is close and the agent says everything is fine. That is exactly when you are most tempted to believe it. A simple personal rule, nothing goes to the client until I have seen it run, removes the decision from the tired moment. You do not have to judge whether to check. You just check.

Build verification into the tools themselves where you can. Prototypes with a visible self-test. Workflows that log what they did and whether it succeeded. Agents that report their results with evidence attached. These make verification easy for you and for the client after you leave. A system that shows its own evidence is a system people trust.

This week, before every claim of success, to yourself or to a client, pause and ask what evidence you have seen. If the answer is none, go and get some. It will cost minutes. Over a year, it will save you at least one very uncomfortable conversation, and probably several.

Ship in the Meeting

Building the change live while the client watches is the single most effective sales move available to a solo operator. It converts scepticism instantly. A buyer who doubted that AI could help with their problem watches you take their real example, describe the change in plain language, and see a working result appear on the screen in minutes. No deck can compete with that. It is the purest demonstration of everything this book argues.

It works because it removes every layer of doubt at once. The buyer sees that the tool is real, not a staged recording. They see that it works on their kind of problem, not a cherry-picked example. They see how quickly change happens, which reframes their sense of what a two-week sprint could achieve. And they see you working, calmly and competently, which is what they are actually deciding whether to buy.

Preparation makes it look effortless. Before the meeting, build the scaffolding: a single-file prototype with realistic data, a skill with the right instructions, a project with the relevant context already loaded. Rehearse the change you expect to make, so you know it works. Then, in the meeting, invite the buyer to suggest the change themselves, within the area you prepared. They feel in control; you are on ground you know. When they suggest something unexpected, try it honestly. If it works, wonderful. If it does not, say so plainly and note it as something to explore. Honesty under pressure impresses more than a flawless performance.

The risks are real and manageable. Live demos can fail: a service is slow, a connection drops, the model takes an unexpected approach. Have a fallback ready, such as a recording or a prepared version of the result, but use it only if the live attempt genuinely fails. And never build live on real client data unless the agreement and their systems allow it. Synthetic data that mirrors their reality is the safe default.

The most persuasive sentence in consulting is not a sentence. It is a working change that appeared while they watched.

This move also works inside engagements, not just in sales. During a Friday demo, make a small change the client asks for, live. During a training session, build something useful from a participant's suggestion. Each time, you demonstrate that change is cheap and fast, which encourages clients to ask for improvements rather than tolerating problems. That is good for them and very good for the relationship.

It is the natural climax of this part. Everything before it, single-file prototypes, realistic data, focused artifacts, links, verification, is preparation for this moment. Get those habits right and building in the meeting stops being a stunt and becomes your normal way of working.

This week, in your next client conversation, find one small change you can make live. Prepare the scaffolding, rehearse it once, and then do it while they watch. Pay attention to the moment their posture changes. Remember it. It is what you are selling, and you have just found the fastest way to deliver it.

Week One Is Access

Nothing ships until you have three things: credentials, access to the data or repository, and a named decision-maker. On a two-week engagement, losing three days to waiting for a password is losing a fifth of the calendar before you have started. Chase all three on day one, or week two quietly becomes week one again and the client wonders why the sprint feels short.

Access always takes longer than anyone expects. The person who can create an account is on holiday. The IT provider needs a ticket. The repository is owned by a contractor who has not replied to an email since spring. The data sits in a system nobody has the admin password for. None of this is anyone's fault, exactly, but all of it lands on your timeline unless you get ahead of it. The best consultants treat access as the first deliverable, with the same seriousness as the work itself.

So send the access checklist before the engagement starts, ideally with the agreement. List every system you will need, the level of access required for each, the name of the person who can grant it and the date you need it by. Ask for accounts created for the engagement rather than shared personal logins, which are a security problem and an audit headache. Ask for the minimum access that will do the job, and say so explicitly; clients are reassured by a consultant who asks for less rather than more.

The named decision-maker is the access item people forget, and it matters most. Someone on the client side must be able to answer questions within a day, approve the plan, accept the result and say no to scope creep. Without that person, every question becomes a meeting and every decision drifts. Ask for them by name at kick-off. Agree how you will reach them and how quickly they can respond. If the answer is vague, the engagement is at risk, and it is better to know on day one.

The sprint does not start when you start working. It starts when you can.

Use Claude to make the start smoother. A good kick-off pack, with the definition of done, the access checklist, the weekly rhythm, the communication plan and the handover contents, can be drafted from your template and the diagnostic summary in minutes and reviewed with the client in the first meeting. It looks thorough because it is thorough, and it costs you very little once the template exists.

If access genuinely cannot be arranged in time, say so early and adjust. Move the start date, reduce the scope, or start with the parts of the work that do not need the missing access. What you must not do is quietly absorb the delay and then deliver less than promised at the end. That converts an administrative problem into a reputational one.

This week, write your access checklist template: systems, access levels, who grants, by when, plus the named decision-maker and their response time. Attach it to your next agreement. The first time a client has everything ready on day one because you asked in advance, you will feel faintly smug. You will have earned it.

Guardrails over Guesswork

Decide up front what the agent may never do. Send anything externally. Spend money. Delete records. Change permissions. Contact customers. Whatever the list is for a particular client, write it down at the start, and then write it into the system itself, not into a hopeful sentence in a document that nobody reads. Guardrails that depend on the model remembering an instruction are guesswork. Guardrails enforced by the system are guardrails.

The difference is important. An instruction in a prompt, never send emails without approval, is usually followed, but usually is not good enough for actions with real consequences. Models can misunderstand, be confused by unusual inputs or be manipulated by text hidden in the content they process. A system-level control, an agent that simply does not have the ability to send emails, or whose sending tool requires an explicit human approval before it executes, cannot be talked out of its limits. That is the level of certainty clients need for anything that matters.

The tools support this. Claude Code has permission settings that control which tools and commands can run without approval, and which are blocked entirely. Hooks can enforce rules at specific points, such as checking every command before it runs. Connectors can be configured with read-only access or narrow write scopes. In custom systems built on the API, you decide which tools exist at all. In every case, the principle is to grant the least capability the task requires, and to make the dangerous capabilities either absent or gated behind a human.

Write the guardrails with the client. Walk through the actions the system could take and ask, for each one: what is the worst plausible outcome if this goes wrong, and how easily could it be undone? Actions that are low risk and easily reversed, reading data, drafting text, can be free. Actions that are moderate, editing records, writing files, can require approval. Actions that are high risk or irreversible, sending, spending, deleting, should be blocked or tightly gated. The result is a short, clear table that the client understands and the system enforces.

A guardrail in a prompt is a request. A guardrail in the system is a fact.

This conversation also builds trust. Clients worried about AI, which is most clients, are reassured not by promises that the system is clever, but by evidence that it is constrained. Showing them the list of things the agent cannot do, and demonstrating that it really cannot do them, is often more persuasive than any demonstration of what it can do. It turns an abstract fear into a concrete, inspectable boundary.

Put the guardrails in the runbook, along with instructions for changing them. Businesses change, and a guardrail that made sense at handover may need adjusting a year later. The client should know where the controls live, what each one does, and who is authorised to change them.

This week, take any agent or automated workflow you have built, for yourself or a client, and list every action it could take. Mark each as free, ask first or never. Then check that the system actually enforces your marks. Any that rely only on an instruction in a prompt are your first fixes.

Human in the Loop

Design the human checkpoint deliberately, rather than bolting it on after the first incident. Every system that does real work will occasionally get something wrong. The question is not whether a human should be involved, but where, how and for which kinds of action. Autonomy should be earned per action type, based on evidence, not granted to the whole system at once because the demo went well.

Start by mapping the workflow and marking where a mistake would be costly. A drafted reply to a routine enquiry might be safe to send after a quick human glance. A reply to a complaint might need a careful read. A refund above a certain size might need a manager's approval. A message to a regulator should probably never be drafted by an agent without close supervision. Each of these is a different checkpoint, designed for the risk at that step, not a single blanket approval that people stop reading after the first week.

Make the checkpoint easy to do well. A human approving outputs needs to see the right information: the original input, the agent's output, any flags the system raised and the reasoning if relevant. They need a fast way to approve, edit or reject, and a way to record why. If the approval screen is cluttered or slow, people start clicking approve without reading, and the checkpoint becomes theatre. Good checkpoint design is mostly good interface design.

Use the checkpoint to gather evidence. Every approval, edit and rejection tells you something about how the system is performing. Log them. Review them regularly. If the team approves a certain type of output unchanged ninety-something times in a row over a meaningful period, that is evidence that the checkpoint for that type could be relaxed, perhaps to sampling rather than full review. If they keep editing another type, that is evidence the system needs improvement there. Autonomy expands where the evidence supports it, one action type at a time.

Trust the system as far as the evidence goes, and not one step further.

This approach suits micro-engagements well. An agent pilot typically starts with a human approving every output. That is safe, it gives the client confidence, and it generates exactly the evidence needed to decide what comes next. A follow-on engagement can then relax checkpoints where the data supports it and improve the system where it does not. Each step is small, justified and measurable.

Be honest with clients about what a human in the loop can and cannot catch. A reviewer skimming fifty drafts an hour will miss subtle errors. Design for that: flag outputs that are unusual or low-confidence for closer attention, so the reviewer's attention goes where it is most needed. Combine human review with automated checks, such as the verifier pattern from Part Five, rather than relying on either alone.

This week, take one workflow you have automated, or plan to, and mark each step with the checkpoint it needs: none, glance, careful review or senior approval. Look at the steps with no checkpoint and ask whether you have evidence that they are safe, or merely hope. Where it is hope, add a checkpoint and start gathering the evidence.

Evals as Acceptance

Replace vague sign-off with a scored test set. At the end of a typical engagement, the client is asked whether they are happy, and the answer depends on their mood, the last output they saw and whether anything went wrong that morning. That is a poor basis for accepting work and a fertile ground for disputes. When acceptance is a score on twenty real cases, agreed in advance, disputes tend to end before they start.

An evaluation set, usually shortened to evals, is simply a collection of realistic inputs with a clear way to judge each output. For an enquiry-drafting system, it might be twenty real past enquiries, anonymised where necessary, each with a note of what a good reply would cover. For a document extraction pipeline, it might be twenty documents with the correct extracted values. For a prompt kit, it might be a set of tasks with a rubric for quality. The test is run, each output is scored, and the result is a number everyone can see.

Build the evaluation set with the client, early. In the first days of the engagement, ask the person who will accept the work to pick representative cases, including some awkward ones, and to say what a good output looks like for each. Write that down as a rubric. Agree the threshold for acceptance: perhaps a certain number of cases must meet the rubric fully, and none may contain a serious error. Now everyone knows what done means, in concrete, testable terms.

The evaluation set then becomes your development tool. Run it after every significant change. You see immediately whether a new prompt, a new skill or a new model improves things or makes them worse. You stop arguing about whether an output is good in general and start fixing the specific cases that fail. Claude can help run and score evaluations, using the rubric, with you reviewing the scores. The verifier pattern applies directly.

Acceptance by feeling invites an argument. Acceptance by score invites a fix.

Evals also make the handover stronger and the retainer more credible. At handover, the client receives the evaluation set along with the system, so they can rerun it whenever something changes: a new model, a new policy, a new product line. During a retainer, the monthly report can show the score over time, with any new failure cases added to the set. That is a concrete, ongoing demonstration of value, much more convincing than a list of hours spent.

Two cautions. First, an evaluation set is only as good as its cases. If all twenty are easy, a high score means little. Include the difficult cases, and add new ones whenever a real failure occurs. Second, do not let the score become the only measure. A system can score well on its test set and still frustrate users in ways the set does not capture. Combine the score with user feedback and real-world measures.

This week, for the next thing you deliver, write the evaluation set before you build: ten to twenty realistic cases, a rubric and a threshold, agreed with whoever will accept it. Then build until it passes. You will find that the conversation at the end is much shorter, and much friendlier, than usual.

Demo Every Friday

A weekly demo is the cheapest insurance against building the wrong thing. Every Friday, show the client what you have built that week: working, on screen, with their kind of data. It takes half an hour. It forces you to produce a shippable increment every week, it catches misunderstandings while they are still cheap to fix, and it keeps the client emotionally invested in the work. Few habits deliver so much for so little.

The forcing function matters. Without a demo on the calendar, work drifts towards the comfortable and the invisible: refactoring, polishing, exploring. With a demo every Friday, you need something to show, which means you need something working. That pressure keeps the work focused on what the client will see and use. On a two-week sprint, two Friday demos are the backbone of the engagement: one to check direction, one to deliver.

The demo is also where misunderstandings surface. You built the triage tool to route by product type; the client assumed it would route by urgency. In a document, that misunderstanding might survive until handover. In a demo, it surfaces in thirty seconds, when the client watches an urgent complaint routed to the wrong queue and says wait, that should go straight to Sarah. Better to hear that on the first Friday than the last.

Keep the format consistent. Start by restating the goal and the definition of done. Show what changed since last week, working, preferably live. Show the evaluation score if you have one. Mention anything that went wrong or changed. Ask for specific feedback on specific decisions. Close with what you will do next week. Thirty minutes, the same structure every time, so the client knows what to expect and comes prepared.

A demo every Friday means bad news arrives in small, survivable pieces rather than one large, memorable one.

The emotional side is underrated. Clients who see progress every week feel ownership of the work. They talk about it to colleagues. They start imagining how they will use it. By handover, they are already invested in its success, which makes adoption much more likely. Clients who see nothing for two weeks and then receive a finished system feel like recipients rather than participants, and recipients are much more likely to find fault.

Invite the right people. The decision-maker, certainly. The person who will own the system after handover, definitely. One or two of the people who will actually use it, if possible. Users notice practical problems that managers miss, and involving them early makes the eventual training far easier.

This week, if you are in the middle of an engagement, schedule a Friday demo, even if it is just fifteen minutes. If you are not, add a weekly demo to your standard engagement template and to your next proposal. Clients consistently say that weekly demos are one of the things they valued most, and it is one of the cheapest things you will ever provide.

The Scope Creep Protocol

Say yes to the idea and no to the timeline. Scope creep is the natural enemy of fixed-scope work, and it rarely arrives as a demand. It arrives as an enthusiastic, reasonable, small-sounding request from a client who is pleased with progress. Could it also handle returns? While you are in there, could you look at the reporting? Each request seems trivial. Together, they turn a two-week sprint into a six-week one at the same price.

The protocol is simple and friendly. When a new request arrives, welcome it, because it means the client is engaged. Then write it down as a change note: what is being asked for, what it would involve, how it would affect the timeline and what it would cost. Send the note promptly, ideally the same day, with a clear choice: add it to this engagement with the stated change, or put it on the list for the next one. Most clients choose the list, cheerfully, because they can see the current work is on track.

The tone matters as much as the process. A scope creep protocol delivered grudgingly feels like bureaucracy. Delivered warmly, it feels like professionalism. That is a great idea, and it fits naturally after this sprint. I have added it to the list for our closing demo, and I can send you a quick outline of what it would involve. The client hears enthusiasm and a plan, not a refusal. The answer to the timeline question is no; the answer to the idea is yes.

Claude can make the protocol nearly effortless. Keep a change note template, and when a request arrives, ask Claude to draft the note from the request, the current scope and your standard terms. Review it, adjust the estimate, send it. Five minutes. Keep all the notes in one place. By the end of the engagement, that collection of parked requests is a ready-made pipeline: a list of things the client has already said they want, described and roughly scoped, waiting for the closing demo.

Every parked request is a proposal the client wrote for you. Treat the list with care.

Agree the protocol at kick-off, so it is never a surprise. Explain that the engagement has a fixed scope and that new requests will be welcomed, written up and either added with a change or parked for later. Clients appreciate knowing the rules. It also means that when you invoke the protocol, you are following an agreed process, not inventing a reason to say no.

There is one exception worth naming. If a request reveals that the original scope was wrong, that the thing you are building will not solve the problem, stop and discuss it properly. That is not scope creep. It is new information, and it may mean changing direction. The protocol is for additions, not corrections.

This week, write your change note template: request, impact, timeline, choice. Agree the protocol in your next kick-off. When the first request arrives, use it, warmly and the same day. Then watch the parked list grow. It is the most reliable source of next engagements you will ever have.

Write the Runbook

The system you leave behind must be operable by someone who has never met you. That is the test of a good handover, and the runbook is how you pass it. Without a runbook, your work is a project: it exists, it works today, and it depends on knowledge in your head. With a runbook, it becomes an asset: something the client can run, check, fix and change without calling you. That is what they paid for, whether they realised it or not.

A good runbook covers three things. First, what the system does and why: its purpose, its inputs and outputs, the decisions that shaped it and the guardrails that limit it. Second, how to run and check it: where it lives, how to start it, how to tell whether it is working, where the logs are, how to rerun the evaluation set. Third, what to do when it breaks: the common failure modes, how to recognise each one, the steps to fix it, and when to escalate. Add contacts, credentials locations and change procedures, and you have a document the client can rely on.

Write it during the engagement, not at the end. Every time you set something up, write down how. Every time something goes wrong, write down what happened and how you fixed it. Claude can turn your notes, the memory file, the commit history and the system's configuration into a well-structured draft, which you then check and complete. The runbook written in the last two hours of a sprint is always thinner than the one written as you went.

Test it. Ask the person who will own the system to follow the runbook without your help: start the system, run a check, simulate a common failure and fix it. Watch where they get stuck. Every place they get stuck is a gap in the runbook. Fix the gaps. This test takes an hour and is one of the most valuable hours of the engagement, because it reveals exactly how much of your knowledge has not yet been transferred.

If the system only works while you are reachable, you have not delivered a system. You have delivered a dependency.

Keep the runbook where the client will find it: in the repository beside the code, in the project knowledge beside the prompts, or in their usual documentation system. Make it easy for them to update. Systems change, and a runbook that is not kept current becomes misleading, which is worse than having none. Name an owner on the client side who is responsible for keeping it accurate.

A runbook is also a quiet piece of marketing. Clients who receive a clear, tested runbook remember it, because most contractors do not provide one. It signals that you care about what happens after you leave, which is exactly what makes clients trust you with the next engagement.

This week, write a runbook for something you have built, even something small for yourself. Three sections: what and why, how to run and check, what to do when it breaks. Then ask someone else to use it. You will discover how much you assumed. That discovery is the point.

Train the Champion

Every account needs one internal person who can demonstrate the system without you. Adoption dies when the only competent operator invoices monthly. You can build the most elegant workflow, the most reliable agent pilot, the most useful skill library, and if nobody inside the business understands it well enough to champion it, it will slowly fall out of use. Training the champion is not an add-on to delivery. It is part of delivery.

Choose the champion carefully, ideally with the client at kick-off. The best champion is not necessarily the most senior person or the most technical. It is someone who uses the system day to day, who is respected by their colleagues, who is curious about AI rather than threatened by it, and who has enough time to learn. Ask for them by name, involve them in the Friday demos, and give them real responsibilities during the engagement: testing outputs, contributing examples, reviewing the runbook.

Train them properly before handover. A champion should be able to demonstrate the system to a colleague, explain what it does and does not do, handle the common problems from the runbook, make small changes such as adding an example to a skill or updating a prompt, rerun the evaluation set and judge when to escalate to you or to their own technical support. That is a substantial set of skills, and it takes more than a single meeting to build. Plan a few short sessions across the engagement, with practice in between.

This is also where the training session becomes a micro-engagement in its own right. Many businesses want their wider team to use AI tools well, and a focused, practical session, half a day, a specific team, their real tasks, a set of tested prompts to take away, is an easy purchase with immediate results. Run it with the champion as your co-presenter. The team learns from someone they work with, the champion's standing rises, and the training continues after you leave because the champion is still there.

The system will be used as long as someone inside believes in it and knows how to show it. Make sure that someone exists.

Good training is practical, not theoretical. Use the team's real work, not invented examples. Have every participant produce something useful during the session. Teach a small number of techniques well, rather than surveying everything. Leave them with a short reference, the prompt kit or a one-page guide, and the champion's name as the person to ask. Follow up a few weeks later to see what stuck.

Look after the champion after handover, too. A short check-in a month later, a note when a relevant new feature appears, an invitation to share their success in a case study. Champions are also your best source of referrals and your best advocates when the next engagement is being considered. They know what you did, they have seen it work, and they have a personal stake in its continued success.

This week, think about the systems you have delivered. For each, name the internal champion. If you cannot name one, that system is at risk. Reach out and offer a short training session. It may be the most valuable hour you spend this month.

Hand Over the Prompts

Withholding the prompts to create dependency is a short game that ends badly. Some consultants keep the instructions, skills and configuration behind their systems to themselves, on the theory that a client who cannot see how it works must keep paying to keep it working. It sometimes succeeds for a while. Then the client changes consultants, or hires a developer, or simply resents the arrangement, and you lose the account and your reputation along with it. Give them everything, and sell them the next system instead.

What does everything mean? The prompts and system instructions. The skills, with their references and scripts. The memory files. The evaluation sets and rubrics. The configuration of connectors and permissions. The runbook. The prototypes and their source. Anything that was built for the client, from the client's context, to do the client's work, belongs to the client. Hand it over in a form they can use, store and change, and document it well enough that someone else could pick it up.

This is not just ethics; it is good business. Clients who receive everything trust you more, not less. They see that your value is not in secret prompts but in judgement, speed and the ability to solve the next problem. They are more likely to call you for the next engagement, because they know you will not trap them. They are more likely to refer you, because they can tell others honestly that you were straightforward. And they are less likely to haggle, because they feel they got full value.

It is also realistic. Prompts are not a durable moat. A competent person with access to the system's outputs could often reconstruct a good part of the prompt in an afternoon, and models improve so quickly that clever wording loses its edge in months. What does not depreciate is your method, your library of general skills, your experience across many clients and your judgement about what to build next. Those stay with you whatever you hand over.

Your prompts will be out of date within a year. Your reputation for handing them over will not.

Be clear about what is theirs and what is yours, as the earlier chapter on skills as a deliverable suggested. Client-specific work belongs to the client. General techniques, templates and skills you brought with you remain yours, and the client receives a licence to use them as part of the delivered system. Put this in the agreement at the start, in plain language. Most clients are entirely satisfied with this arrangement, and it protects your reusable library.

Make the handover itself a moment. A short session walking through what they now own, where it lives and how to change it. A tidy repository or project with a readme at the top. A clear statement that they are free to modify, extend or hand it to someone else. Clients remember a consultant who says, in effect, this is all yours now; call me when you want the next thing.

This week, look at the last system you delivered and check: does the client have everything? If not, send it, with a short note. It costs you nothing that matters and buys you more trust than any marketing you could do.

Close the Loop Loudly

Quantify what changed and tell the buyer in their language. Unmeasured wins do not get renewed, referred or remembered at budget time. You may have transformed a workflow, but if nobody can say by how much, the improvement fades into the general background of things that are now fine. Six months later, when the budget is reviewed, the question is what did that consultant actually achieve, and the honest answer is that nobody wrote it down.

Closing the loop starts at the beginning. On day one, establish the baseline: how long the task takes today, how often it goes wrong, how many cases it handles, what it costs in time or delays. Get the numbers from the client, or measure them yourself, or estimate them carefully together and write down the method. Without a baseline, any after measurement is a claim without a comparison.

At the end, measure the same things in the same way. Time per task, error rate, volume handled, turnaround. Report the difference in the client's terms. Not the system achieves high accuracy but the team now drafts routine replies in a fraction of the time, and the evaluation set shows the drafts meet the agreed standard in most cases, with every exception caught at review. Not the workflow has been automated but the monthly report that took a full day now takes under an hour. Specific, comparable, in their language.

Then tell the buyer loudly. Not in a footnote of the handover document, but as the headline of the closing demo and a short written summary they can forward. Make it easy for them to share the result upwards and sideways: to their manager, their board, their colleagues in other departments. The buyer looks good, which they will remember, and the result travels to people who might want something similar.

The work is not finished when it works. It is finished when someone who signs budgets knows it works.

Follow up later. A month after handover, check the numbers again. Systems sometimes perform better in use than in testing, as people learn to work with them, and sometimes worse, as edge cases appear. Either way, the follow-up is valuable: good results become a stronger case study, and problems can be fixed before they undermine the whole effort. The follow-up is also a natural moment to raise the next engagement, from the parked list.

Be honest. If the result is smaller than hoped, say so, and explain why. Clients trust consultants who report modest results accurately far more than those who inflate everything. And an accurately reported modest result, with a clear explanation of what would improve it, is often the opening for the next engagement.

This week, for your current or most recent engagement, write a one-paragraph result summary: baseline, after, difference, in the client's language. If you do not have a baseline, estimate one with the client and note the method. Send it to the buyer with a short note. Then build baseline measurement into your kick-off template, so you never have to reconstruct it again.

Price the Value Gap

Anchor the price on what the problem costs the client, not on what the work costs you. There are two numbers in every engagement: the cost of the problem to them, over a year or more, and the cost of the work to you. With Claude doing much of the heavy lifting, the second number has fallen sharply. The first has not. The gap between those two numbers is where your fee should live, and understanding that gap is the foundation of pricing small engagements well.

This book does not give prices, and deliberately so. Your prices depend on your market, your sector, your reputation and your clients, and any figure printed here would be wrong for most readers. What it can give you is the shape of the reasoning. Start with the client's problem and estimate, together with them, what it costs: hours of staff time each week, errors and their consequences, delays and their effect on customers, opportunities missed. That estimate, honestly made, is the ceiling of what the fix is worth to them.

Then consider your cost: your time, your tools, your risk. That is the floor below which the engagement is not worth doing. Your fee should sit comfortably between the two, close enough to the value that it reflects what you are delivering and far enough below it that the client sees an obvious return. A buyer who pays a fee that is clearly a modest fraction of the problem's cost is not haggling. They are making an easy decision.

The diagnostic call is where you gather the material for this. The questions about how often the problem occurs, how long it takes, what goes wrong and what it costs are not just diagnosis; they are the inputs to your price. When you present the proposal, show the reasoning briefly: here is what we estimated the problem costs, here is what the engagement will deliver, here is the fee. The fee looks small beside the cost because, if you have done this properly, it is.

Price the hole in their bucket, not the hours it takes you to fix it.

Value pricing has an honest limit. If you cannot estimate the value with any confidence, do not invent a large number to justify a large fee. Either run a paid discovery to find out, or price the engagement modestly as a first step that will produce the evidence for a larger one. Clients can tell the difference between a careful estimate and a convenient fiction, and the second destroys trust quickly.

It also has an ethical edge. Value pricing does not mean extracting as much as possible. It means pricing in a way that rewards you for results rather than effort, and leaves the client clearly better off. A consultant who prices at the full value of the problem leaves the client with no gain and no reason to return. Leave room for a clear win on both sides.

This week, take a recent or upcoming engagement and estimate, as carefully as you can, what the problem costs the client over a year. Write down your cost of delivery. Look at your fee in relation to both. If it sits much closer to your cost than to their value, you have probably been pricing your hours rather than their outcome.

Never Quote First

Ask what the client has allocated before you name a number. It feels awkward the first few times, and it is one of the most useful questions in consulting. The answer is often above what you were about to propose. When it is below, you learn that early and can shape the engagement to fit rather than discovering the mismatch after writing a long proposal. Either way, it tells you what game you are in.

The question can be phrased gently. Do you have a budget in mind for this, or a range you would want to stay within? Is there an amount already allocated for this kind of work this year? To make sure I propose something sensible, what level of investment were you thinking of? Most buyers will give you something, even if it is approximate. Some will say they have no idea, which is useful information too: it suggests you are early in their thinking and might need to help them build the case.

When the answer comes, use it to shape scope rather than to set price. If the allocation is generous, you can propose a fuller engagement or the comprehensive option. If it is modest, you can propose a smaller first step: an audit rather than a sprint, a prompt kit rather than an agent pilot, one workflow rather than three. The aim is not to capture every penny of the budget. It is to propose something that fits the client's means and delivers clear value within them.

There are times when the buyer insists that you go first. That is fine. In that case, give a range rather than a single figure, anchored on value, and tie each end of the range to a different scope. For a focused engagement on one workflow, it would be around this; for a fuller one covering the adjacent processes, around that. A range with explained scopes invites a conversation about what they want, rather than a yes or no on a single number.

The first number spoken sets the room. Let it be theirs whenever you can.

Claude can help you prepare. Before a pricing conversation, write down what you know about the client, the problem and its estimated cost, and ask for a set of scope options at different sizes, each with a clear deliverable and outcome. Then you go into the conversation ready to match whatever the client says with a shape that fits. Preparation makes the question feel natural rather than evasive.

Above all, keep the conversation about value rather than cost. When a buyer reveals a budget, they are telling you what they think the problem is worth solving. If that seems low compared with what you estimated, ask about it. Perhaps they have underestimated the cost of the problem, and a few questions will reveal that. Perhaps they have constraints you did not know about. Either way, you learn something important before committing to anything.

This week, practise the question. Write two or three phrasings you are comfortable with and use one in your next sales conversation. Notice how the conversation changes when the buyer speaks first about money. Most consultants find it is far less awkward than they feared, and far more useful than they expected.

Three Options Always

One price invites a yes or a no. Three options invite a choice about which. That is a very different decision for the buyer to make, and a much better one for you. When a proposal has a single option, the buyer is deciding whether to work with you at all. When it has three, lean, standard and comprehensive, they are deciding how much of what you offer they want. The question has moved, quietly, from whether to which.

Design the options around scope and outcome, not around arbitrary extras. The lean option solves the core problem in the simplest way: one workflow, one team, a fixed handover. The standard option, which you expect most clients to choose, solves the core problem thoroughly, with the extra pieces that make it robust: an evaluation set, a trained champion, a follow-up check. The comprehensive option extends the solution to adjacent problems or adds ongoing care. Each option is a real, coherent engagement that you would be happy to deliver.

The middle option does most of the work. Buyers tend to avoid extremes, so the middle option often wins, which means you should design it as the one you most want to sell: the right balance of value, effort and outcome for this client. The lean option makes the middle look sensible. The comprehensive option shows what is possible and occasionally gets chosen by clients who want the full version. Neither is a decoy. Both are honest alternatives.

Make the differences clear and easy to compare. A short table, with the deliverables, timeline and outcomes of each option side by side, helps the buyer see exactly what they gain at each step up. Avoid long lists of small features; focus on the differences that matter to the buyer's problem. And keep the descriptions in the buyer's language, about their outcomes, not about your activities.

A single price is a test. Three options are a menu. People prefer menus.

Claude can draft the three options quickly from the diagnostic summary and your offer templates. Give it the problem, the client's context, the allocation if you know it, and your standard engagement shapes, and ask for three coherent options with a comparison table. Then edit carefully. The model will happily invent extras to pad out the options; your job is to make sure each one is a real engagement you would deliver well.

There is a subtle benefit for scoping, too. Designing three options forces you to think clearly about what is core and what is extension. That clarity helps during delivery, because you know exactly what the client bought and what they did not. When a scope creep request arrives that corresponds to something in the comprehensive option they declined, you can point to it gently. They already know what it would involve.

This week, rewrite your next proposal with three options instead of one. Make the middle option the one you would recommend, and make sure the other two are genuinely useful alternatives. Present them side by side. Notice whether the conversation shifts from whether to work together to which version to choose. It usually does, and quite quickly.

Charge for Discovery

Free scoping trains buyers to treat your thinking as a sample. When you spend days investigating a client's problem, interviewing their staff and designing a solution, all before any agreement, you are giving away the most valuable part of the work. Some buyers will take that work and use it themselves, or hand it to a cheaper provider. Others will simply never decide, because nothing is at stake for them. A paid discovery filters out the tyre-kickers and makes the resulting proposal far harder to refuse.

The distinction is between a conversation and an investigation. The diagnostic call is a conversation: an hour, free, enough to understand the problem in outline and decide whether there is a fit. Anything beyond that, detailed interviews, process mapping, data analysis, a written recommendation, is an investigation, and investigations are work. Paid discovery is simply the honest acknowledgement of that. It is also, in effect, the paid audit from Part One under another name, sized to the specific question at hand.

Frame the discovery as a deliverable, not a fee for your time. A short, fixed-scope engagement that ends with a clear, written document: the problem, its cost, the options for solving it, a recommended approach with a scoped engagement and a measured outcome. That document is valuable to the client whether or not they proceed with you. They could take it to another provider, or use it internally. Most do not, because the person who wrote it is the obvious person to deliver it.

Paid discovery also improves your proposals dramatically. With a few days of proper investigation, you understand the problem well enough to scope tightly, price confidently and avoid the nasty surprises that wreck fixed-price engagements. The client, having invested in the discovery, has a stake in acting on it. Proposals that follow paid discovery are accepted far more often than proposals that follow a single free call, because both sides have done the work.

Free advice is valued at what it cost. Give it away and it gets treated as a sample.

Some buyers will object, especially those used to consultants who scope for free. Explain the difference calmly: the diagnostic call is free, and you are glad to have it; the detailed investigation is a piece of work with a valuable output. Offer to credit some or all of the discovery fee against the subsequent engagement if they proceed within a set period. That makes the decision easy for serious buyers and filters out those who were only ever collecting free ideas.

Claude makes discovery efficient. The interview synthesis, the process maps, the option analysis and the draft recommendation can all be produced quickly, leaving your time for the judgement about which option is right. That means you can offer a meaningful discovery in a short, fixed timescale, which makes it easier to buy.

This week, look at how you currently scope engagements. Where does free conversation end and unpaid investigation begin? Draw the line, name the paid discovery as a product with a clear deliverable, and offer it to your next prospect who needs more than a call to scope properly.

Deposit Before Access

Work begins when money moves. That simple rule eliminates most of the payment problems you would otherwise have. A deposit, typically a meaningful share of the fee and often half, paid before the engagement starts, is standard practice in many kinds of professional work. Asking for it is unremarkable. Not asking for it is a gift to the minority of clients who would otherwise pay late, pay partially or not pay at all.

For small engagements, the deposit does more than secure payment. It confirms commitment. A client who has paid a deposit has made a real decision, has involved whoever approves spending and has a stake in the engagement starting well. They are more likely to provide access promptly, attend the kick-off, nominate the decision-maker and engage with the Friday demos. A client who has paid nothing can drift, delay and reconsider without cost, and some will.

Tie the deposit to the start date. The engagement begins on the agreed date provided the deposit has arrived and the access checklist is complete. If either is missing, the start moves. This links neatly to the access chapter: the deposit and access are the two preconditions, and you chase both in the days before kick-off. The client understands that the timeline is theirs to protect.

Ask for it plainly. In the agreement, state the deposit, when it is due and what it secures: the start date, your time reserved for the engagement, the preparation work. Send the invoice with the agreement. Do not apologise for it or bury it. Professional buyers are used to deposits and think nothing of them. The only buyers who object strongly are, more often than not, the ones you most needed the deposit from.

A deposit is not a sign of distrust. It is a sign that both sides have decided.

The balance should have a clear trigger too. On handover, on acceptance against the evaluation set, or on a fixed date after delivery: choose one and write it down. Tie acceptance to the agreed definition of done and evaluation threshold, so there is no ambiguity about when the work is complete and payment is due. Clear terms at the start make for easy conversations at the end.

For retainers, invoice in advance for each period. The work for a month begins when that month is paid. This keeps retainers clean and prevents the slow accumulation of unpaid months that occasionally sours an otherwise good relationship.

Keep your financial administration as tidy as your delivery. Simple, prompt invoicing, with clear descriptions referring to the named engagement and its deliverables. Claude can help draft the agreement, the invoice descriptions and polite reminders, from your templates. A consultant who is organised about money is reassuring to work with, because it suggests they are organised about everything else.

This week, check your standard terms. If they do not include a deposit, add one, with a clear link to the start date and access. If they do, check that you actually enforce it. The first time you hold a start date for a missing deposit, you may feel uncomfortable. The client, almost always, will simply pay it.

Setup Plus Monthly

Charge properly for the build, and then charge again to keep it alive. Most of the systems in this book need ongoing care: prompts and skills that adapt as the business changes, evaluation sets that grow as new cases appear, improvements as better models become available, monitoring to catch quality drift, a person to call when something breaks. A setup fee covers the work of building. A monthly fee covers the work of keeping it valuable. Recurring revenue is what turns a freelance income into a business.

The structure is easy to explain to clients because it matches their experience of other services. They pay to have something installed and then pay a modest ongoing amount to have it maintained and supported. Software subscriptions work this way, as do many professional services. The important thing is that both parts deliver clear, distinct value: the setup delivers a working system; the monthly arrangement delivers continued performance and improvement.

Define the monthly arrangement precisely, as Part One argued for retainers. A monthly review of output quality against the evaluation set. A fixed amount of improvement work. Updates when models or tools change. A response window for problems. A short written report each month showing what the system did, what changed and what you recommend next. Clients renew arrangements they can see working. They cancel vague ones at the first budget review.

Price the monthly fee against value, like everything else. A system that saves a team many hours a week is worth looking after, and the monthly fee should reflect the value of keeping it working, not just the hours you spend each month. At the same time, keep it modest relative to the setup, so it feels like maintenance rather than a second purchase. The aim is an arrangement that clients barely think about because it is obviously worth it.

The build pays for the month you built it. The care pays for every month after.

There is a delivery discipline that makes this sustainable. If each retainer client requires constant bespoke attention, the monthly arrangement becomes a time sink. Standardise the monthly work: the same review process, the same report template, the same improvement cycle, supported by skills and scripts that do the routine parts. Claude can run the evaluation set, draft the monthly report from logs and highlight cases that need attention. Your time goes on judgement and improvement, not administration.

Not every engagement needs a monthly arrangement. Some systems are simple enough to run on a good runbook and a trained champion. Recommend that honestly when it is true. But where a system does need care, say so in the proposal and price it in from the start. A client who knows from the beginning that the system has a monthly cost plans for it. A client who finds out at handover feels misled.

This week, look at the systems you have delivered and ask which ones would benefit from ongoing care. For each, sketch a monthly arrangement: what it includes, what it reports, what it improves. Then offer it, starting with the client who has had the best results. The best time to propose a retainer is when the evidence of value is fresh.

Know Your Token Cost

Agentic delivery has a real marginal cost, and it is easy to ignore until it bites. Every call to a model costs something, and agentic work makes many calls: reading files, running tools, verifying results, fanning out to subagents, iterating to a passing test. Most of the time the cost is small relative to the fee. Occasionally, a badly scoped task or an inefficient workflow consumes far more than expected, and your fixed-price sprint quietly becomes a fixed-price loss. Track spend per engagement.

Tracking is not difficult. Most platforms provide usage reporting, and plans differ in how usage is measured and limited, so understand the one you are on. For engagements built on the API, use separate keys or workspaces per client so costs are attributed clearly. For work in Claude's apps and in Claude Code, keep an eye on usage during intensive work and note which tasks consumed the most. Over a few engagements, you will develop a sense of what each type of work costs to deliver, which makes pricing more accurate.

The bigger issue is the systems you hand over. A client's agent pilot that processes hundreds of documents a day has an ongoing running cost, and the client needs to know what it is before they commit. Estimate it during the pilot, from actual usage on real work, and include it in the handover and the proposal for the next stage. Clients are understandably unhappy to discover, a month after go-live, that their new system has a running cost nobody mentioned.

There are many ways to reduce cost without reducing quality. Use smaller, faster models for simple steps and the most capable ones only where judgement matters. Keep contexts lean, as Part Three recommended. Use prompt caching where the platform supports it for stable instructions and reference material. Replace repetitive model work with bundled scripts. Batch non-urgent work where batch processing is available. Each of these is also good engineering, so cost optimisation and quality usually point in the same direction.

A fixed price with an unknown cost is not a fixed price. It is a bet you did not mean to place.

Build the running cost into your pricing structure where relevant. For managed systems under a retainer, decide whether the client pays for usage directly on their own account, which is usually cleanest, or whether you include an allowance in the monthly fee. Either way, make it explicit. Ambiguity about who pays for usage is a common source of friction in AI engagements, and it is entirely avoidable.

Do not let cost anxiety distort your work. In most micro-engagements, the cost of model usage is modest compared with the value delivered and the fee charged. The point of tracking is not to minimise every call, but to avoid surprises and to price accurately. Spend where it improves the outcome; trim where it does not.

This week, look at the usage for your most recent engagement and work out roughly what it cost to deliver in model usage. Compare that with the fee. Then estimate the monthly running cost of the system you handed over and check that the client knows it. If either figure surprises you, you have found something worth fixing.

Raise on Renewal

Every renewal is a repricing opportunity, and most consultants skip it. A retainer comes up for renewal, the client is happy, and the path of least resistance is to carry on at the same terms. Meanwhile, the system has improved, your skills have deepened, the value delivered has grown and your costs have changed. Existing clients absorb increases far better than you might expect when the results are documented and the increase is explained.

The key is documentation. A renewal conversation that opens with the monthly reports, the evaluation scores over time, the improvements made and the measured impact on the client's work is a conversation about value. In that context, an adjustment to the fee is a natural part of the discussion rather than an unwelcome surprise. A renewal conversation with nothing to show is a conversation about cost, and in that conversation any increase feels like an imposition.

Signal it early. Mention, a month or two before the renewal date, that you will be reviewing the arrangement and suggesting any changes. When the renewal comes, present the review: what the system achieved, what changed, what you propose for the next period, including any adjustment to the scope and the fee. Give reasons. Perhaps the scope has grown, or the value has increased, or your rates have changed for new clients and you are bringing existing ones gradually into line. Clear reasons, calmly stated, are usually accepted.

Consider pairing an increase with something new. A renewal that adds a useful capability, a quarterly strategy session, extended coverage, an additional workflow, alongside a fee adjustment feels like an upgrade rather than a price rise. The client gets more, you get a fairer return, and the relationship grows rather than merely continuing.

Silence at renewal is a price decision too. It just happens to be one you did not make on purpose.

Be sensible about it. Large, sudden increases damage trust, and clients who feel squeezed start looking for alternatives. Modest, regular, well-explained adjustments are far more sustainable. And sometimes the right answer is not to increase at all: if the client is under pressure, or the value has not grown, holding the fee steady is a reasonable choice. The point is to decide deliberately rather than by default.

Renewals are also a moment to check the fit. Has the system become so stable that the client needs less care? Say so, and suggest reducing the arrangement or moving to a lighter one. That honesty is remembered. Has the client's business grown so that the system needs more? Suggest expanding it. A renewal is a natural point to reshape the relationship to match reality.

This week, list your recurring arrangements and their renewal dates. For each one coming up in the next quarter, prepare a short value review: results, improvements, scope, proposed terms. Then have the conversation, early and calmly. Most consultants who try this are surprised how routine it turns out to be.

Cash Beats Equity

Sooner or later, a start-up will offer you shares instead of a fee. They are short of cash, enthusiastic about the future and confident that the shares will be worth far more than your invoice. Sometimes they will be. Usually they will not. Take the money. You are running a business, not a venture portfolio with one position, and a micro-consulting practice depends on cash flow far more than on speculative upside.

The arithmetic is unkind to equity for small engagements. Most early-stage companies do not succeed in the way their founders hope, and even those that do may take many years to produce any return for small shareholders, by which time your stake may have been diluted considerably. A modest piece of a company that may or may not be worth something in some years' time is not a substitute for a fee that pays your bills this month. It is a lottery ticket, and lottery tickets are a poor basis for a business.

There are also practical complications. Equity arrangements need legal paperwork, sometimes tax advice, and careful terms about vesting and what happens if the company changes direction. For a two-week engagement, that administrative weight is out of all proportion to the work. And equity can create awkward incentives: you become an investor with a stake in the company's choices, which can complicate the independent advice you are there to give.

If a start-up genuinely cannot pay, there are better options than equity. Scope a smaller first engagement that fits their budget. Offer a lean option from your three-option proposal. Defer part of the fee to a defined milestone, such as their next funding round, with clear terms. Or simply decline politely and stay in touch, because start-ups that succeed remember the consultants who were straight with them, and come back when they have funds.

Shares are a promise about the future. Cash is a fact about the present. Small practices run on facts.

There are rare exceptions. If you know the founders well, believe strongly in the company and can afford to treat the engagement as an investment you might lose entirely, a small equity component alongside a reduced fee can be reasonable. But treat it as a deliberate investment decision, separate from your consulting income, and never let it replace the cash your practice needs to function.

The broader principle applies beyond start-ups. Be wary of any arrangement that replaces a clear fee with something uncertain: revenue shares on unproven products, payment in exposure, success fees on outcomes you do not control. Each has its place in particular circumstances, but none should become the norm for a practice built on small, fixed, reliable engagements.

This week, decide your policy on equity and other non-cash offers before the next one arrives. Write it down: cash fees as standard; deferred elements only with clear terms; equity only as a deliberate side investment. Having a policy makes the conversation easy, and saves you from deciding under the influence of a founder's infectious optimism.

Fire the Bad Accounts

The client who pays least and asks most is blocking the one who would pay most. Every practice accumulates a few accounts like this: the retainer priced too low years ago, the client who treats every interaction as a negotiation, the one whose scope creeps despite every protocol, the one who is always late to pay and always early to complain. They consume time, attention and energy out of all proportion to their value. Portfolio hygiene is a growth strategy, not a luxury.

The case is simple arithmetic. Your capacity is limited. Every hour spent on an account that drains you is an hour not spent on an account that rewards you, or on the marketing, product development and learning that would bring better accounts in. Small practices feel this acutely, because there is no team to absorb the cost. One bad account can occupy a meaningful share of a solo consultant's week and most of their worrying.

Review your accounts regularly, perhaps every quarter. For each one, consider the revenue, the time it takes, how pleasant and reasonable the client is to work with, whether they pay promptly, whether the work is interesting and whether it leads anywhere: referrals, case studies, new capabilities. Plot them roughly. Most accounts will be fine. A few will be excellent. One or two will be clearly costing you more than they give.

For those one or two, try to fix the relationship first. Reprice the arrangement at renewal, reset the scope, re-establish the protocols that slipped. Sometimes a frank conversation transforms an account. If it does not, let it go, professionally and courteously. Give proper notice, complete outstanding commitments, hand over everything as Part Seven recommended, and perhaps suggest another provider who might be a better fit. Leave on good terms; the world is small.

Saying no to the wrong client is how you make room to say yes to the right one.

The fear, always, is the lost revenue. In practice, the time freed by letting a bad account go is often filled quickly, and with better work, because you now have the capacity and energy to pursue it. The relief is also considerable. Consultants who let go of a draining client commonly report that they wish they had done it sooner.

Prevention is better than cure. The habits in this book, clear scope, deposits, change notes, evaluation-based acceptance, documented results, filter out many difficult clients before they become difficult accounts. A paid discovery or audit as a first engagement shows you what a client is like to work with before you commit to a longer relationship. Use that information. Not every client who buys an audit should be offered a retainer.

This week, list your current accounts and rate each one honestly on value and effort. Identify the one that costs you most for least return. Decide whether it can be fixed or should be ended, and take the first step. Then notice how much lighter the next week feels.

Case Study per Job

Write the case study while the numbers are warm and the client is delighted. Problem, approach, result, a line from the client: twenty minutes at the end of an engagement, and you have a piece of proof you can use for two years. Leave it a month and the numbers are hazy, the client has moved on to other priorities, and the case study never gets written. Every engagement you finish without one is evidence you have thrown away.

The structure is simple and it works. The problem, in the client's terms: what was going wrong, how often, at what cost. The approach: what you did, briefly, without jargon, emphasising the shape of the engagement so a reader can imagine buying the same thing. The result: the measured before and after from your close-out, stated plainly. And, with the client's permission, a short comment from them about what changed. A single page is enough. Shorter is often better.

Claude makes this almost effortless if you have kept good records. The diagnostic summary, the scope, the Friday demo notes, the evaluation results and the close-out summary contain everything needed. Give them to Claude with your case study template and ask for a draft in plain, specific language. Review it for accuracy, strip anything confidential, and send it to the client for approval. Most clients are happy to approve a case study that makes them look sensible and forward-thinking, which a good one does.

Permission and confidentiality matter. Agree at the start of the engagement, ideally in the contract, that you may write a case study, subject to the client's approval of the text. Some clients will want to be named; others will prefer anonymity, in which case describe them by sector and size. Never publish figures or details the client has not approved, and never include anything that could identify their customers or staff without explicit consent.

A finished engagement without a case study is a sale you made once instead of many times.

Use them everywhere. On your website, grouped by type of engagement, so a prospect looking for an audit can read about audits. In proposals, choosing the one or two most relevant to the prospect's sector and problem. In your teardown emails and talks. In conversations, as stories: a practice much like yours had the same problem; here is what we did and what happened. Specific, recent case studies are among the most persuasive things a small consultant can offer, because they replace a promise with a precedent.

Over time, your case studies form a library that also tells you something about your own practice. Which engagements produce the strongest results? Which sectors respond best? Which offers lead to retainers? Reading your own case studies together is a surprisingly useful strategy exercise, and one that most consultants never do because they never wrote them down.

This week, write a case study for your most recent finished engagement, using the four-part structure. If you lack the numbers, ask the client for an honest estimate and note it as such. Send it for approval. Then add write case study to the last day of your engagement template, so it happens every time, while the delight is fresh.

Referral by Design

Ask for referrals at the moment of maximum delight, and ask for something specific. Vague requests to keep you in mind produce exactly nothing, forever. Clients mean well when they say they will mention you to people, and then they get busy, and the moment passes. A specific request at the right moment produces introductions. Referrals do not happen by accident often enough to build a practice on. They happen by design.

The moment of maximum delight is usually easy to spot. The closing demo, when the client sees the finished system and the measured result. The first time the system handles a problem that used to ruin someone's afternoon. The message from the champion saying the team loves it. In that moment, the client's goodwill is at its peak and the value of your work is vivid. That is when to ask, not a month later when it has become normal.

Make the request specific. Not if you know anyone who might be interested, but who else do you know who runs a practice like yours and has the same kind of month-end headache? Or is there someone in your industry association who would find this result interesting? Or would you be willing to introduce me to the operations lead at your sister company? A specific question prompts the client to think of a specific person. A vague one prompts them to say yes and think of no one.

Make it easy for them to act. Offer a short, forwardable note describing what you did and for whom, which they can send with a line of their own. Offer to write the introduction email for them to edit. Offer your case study as an attachment. The less effort the referral takes, the more likely it is to happen. Claude can draft these notes quickly, tailored to each client and the person they have in mind.

Clients want to help you. They just need to be told how, and when, and to whom.

Thank every referral, whether or not it leads to work. A short, personal note, and an update if the introduction turns into an engagement. People like to know their help mattered, and those who are thanked tend to refer again. Some consultants offer a small gesture of thanks for referrals that become engagements; whether you do is a matter of taste and of your sector's norms. A sincere thank-you is never wrong.

Design your engagements to produce referral moments. The Friday demos, the measured close-out, the trained champion, the case study: each creates a point of delight and a natural opening. The micro-engagement format helps enormously here, because short engagements produce frequent moments of completion, and every completion is an opportunity to ask. A practice built on a steady flow of small, finished, successful engagements is a practice with many such moments each year.

This week, think about your current or most recent client. Identify the moment of delight, past or upcoming. Write a specific referral request and a short forwardable note. Then ask, at that moment, for one specific introduction. Track how many introductions this approach produces over the next few months compared with the vague requests you used to make.

The Teardown Email

Do the work before the meeting. A teardown email is a specific, unmistakably bespoke analysis of a prospect's actual problem, sent before any conversation, with no request beyond a reply. It shows rather than tells: here is what I noticed about your business, here is what could be improved, here is roughly how. Reply rates for this kind of outreach look nothing like ordinary cold email, because it does not read like cold email. It reads like someone has already started helping.

The research is where Claude transforms the economics. Choose a prospect in your vertical. Gather what is public: their website, their published processes, their job adverts, their customer reviews, their social media, their enquiry forms. Ask Claude to analyse it for opportunities you know how to address: an enquiry process that seems manual, customer complaints about slow responses, a job advert describing tasks that could be assisted, documentation that is hard to find. Then apply your judgement to pick the one or two that are real, specific and within your offer.

Write the teardown short. A few paragraphs: what you noticed, why it probably matters to them, what a small fix might look like and what result it could produce. Include something concrete, perhaps a quick prototype, a sample of a better response, a one-page sketch of a redesigned process. Close with a simple question: would this be useful to discuss? No attachments full of credentials, no lengthy introduction about yourself. The work is the introduction.

Be careful about tone. A teardown that reads as criticism will be ignored or resented. Frame it as opportunity rather than failure: I noticed your enquiry form asks for a lot of detail up front; here is a way that might convert more visitors and save your team time. Be accurate: only point out things you have actually observed, and acknowledge what you cannot see from outside. Prospects can tell instantly whether someone has really looked at their business or merely filled in a template.

Cold email asks for attention. A teardown pays for it in advance.

Volume is not the goal. A few genuinely bespoke teardowns a week, carefully researched and well targeted, will produce more conversations than hundreds of generic messages. Claude makes the research fast enough that a good teardown takes perhaps an hour, which is a sensible investment for a prospect who might become a long-term client. Keep a template for structure, but never let the content become generic.

Respect the rules of your jurisdiction and your prospects' preferences. Business outreach is subject to regulations in many places, and good practice is to send to an appropriate business contact, identify yourself clearly and make it easy to say no. A teardown that respects the prospect's time and choice is far more likely to be welcomed.

This week, pick three prospects in your niche. For each, spend an hour with Claude researching their public material, identify one specific opportunity, and write a short teardown with something concrete attached. Send them. Note the replies. Even the ones that say not now tend to be warm, and not now has a habit of becoming now a few months later.

Ship a Free Tool

A small, useful tool in your niche is the best business card ever invented. It qualifies prospects, demonstrates competence and works while you sleep. A calculator that estimates how much time a practice spends on a particular task. A checker that reviews a document against a common standard. A generator that produces a first draft of something your buyers need regularly. Each one is useful on its own, shows what you can build, and brings the right people to your door.

The economics have changed in favour of this. Building a polished single-purpose tool used to take weeks of development. With Claude, a focused tool built as a single-file artifact can be designed, built and published in a day or two. The constraint is no longer the building; it is choosing the right tool to build. And that choice comes straight from your vertical knowledge: what do your buyers need repeatedly, find tedious, and would be grateful to get for free?

Choose tools that connect to your paid offers. A tool that estimates the time a team spends on manual reporting connects naturally to a workflow fix engagement. A tool that scores a business's readiness for AI connects to the paid audit. A tool that generates a first draft of a policy connects to the documentation sprint. The free tool solves a small problem and reveals a larger one, which you happen to be able to solve. That is not a trick; it is simply a useful sequence.

Make the tool genuinely useful without requiring contact details. Gating every free tool behind a sign-up form reduces use and irritates the people you most want to impress. Let people use it freely, and offer an optional next step: a more detailed report by email, a short call to discuss the result, a link to a relevant case study. The prospects who take that step are the ones most likely to buy, and they arrive already convinced you know what you are doing.

A tool that helps someone today is remembered when they have a budget tomorrow.

Keep it focused, as the chapter on one artifact per question argued. A tool that answers one question well gets shared; a tool that tries to do everything gets abandoned. Give it a clear name that describes what it does, put it where your buyers will find it, and mention it in your teardowns, talks and posts. Watch how people use it and improve it occasionally. A small tool that stays current and accurate keeps working for you for a long time.

Be careful with what the tool claims. A calculator that produces estimates should say clearly that they are estimates and explain the assumptions. A checker should be clear about what it checks and what it does not. Overclaiming in a free tool undermines the very credibility it was meant to build.

This week, think of the one question your buyers ask most often that a simple tool could help answer. Build a first version as a single-file artifact with Claude. Test it with someone in your niche. If they find it useful, publish it and start mentioning it. If not, ask them what would be more useful, and build that instead.

Build in Public

Ship something visible every week and let the work do the prospecting. Buyers hire the person whose output they have already been watching for three months. Building in public means sharing your work as you do it: the tools you build, the problems you solve, the lessons you learn, the experiments that worked and the ones that did not. Over time, that steady stream of visible work builds a reputation that no amount of advertising can buy.

What to share depends on your niche and your clients' confidentiality. You cannot publish client work without permission, but you can share a great deal around it. A new free tool. A technique you have refined. A short write-up of a problem common in your sector and how you approach it. A synthetic example of a workflow you have fixed, rebuilt with sample data. A lesson from a pilot, anonymised. A skill you have released openly. Each piece shows how you think and what you can do.

Consistency matters more than brilliance. One useful post or small release every week, for months, is far more effective than an occasional burst of activity. The people who will eventually hire you are watching quietly; they need to see you appear regularly, doing good work, until you become the obvious person to call. Claude helps with the production: turning your notes into a readable post, building the small demonstrations, drafting the summaries. The judgement about what is worth sharing remains yours.

Share in the places your buyers actually are. For some niches, that is a professional network. For others, it is an industry forum, a newsletter, a community group or a specialist publication. Building in public in a place your buyers never visit is a hobby, not a pipeline. Find out where your buyers read, and show up there with useful work, consistently.

Visibility is not vanity when what is visible is useful. It is simply a very slow and very effective sales call.

Building in public also improves the work. Explaining what you did forces you to understand it clearly. Feedback from peers improves your methods. Questions from prospects reveal what your market actually cares about. And the archive of public work becomes a resource you can point prospects to: here is how I approach this problem; here is a tool I built for it; here is what happened when I tried it.

There are honest limits. Building in public takes time, and it can become a distraction from paid work. Set a modest, sustainable rhythm, perhaps an hour or two a week, and protect it without letting it grow. And remember that the aim is to be useful, not to perform. Posts written to impress other consultants rarely attract clients. Posts that solve a real problem for a buyer often do.

This week, decide on one thing you will share every week for the next three months, and where. Then share the first one. Keep a simple list of what you have shared. In three months, look back at the list and at the conversations it produced. The results are rarely dramatic in the first few weeks and are usually unmistakable by the end.

Talk at the Meetup

Twenty engaged people in a room beat two thousand impressions online. Local business groups, industry associations, chamber of commerce events and sector meetups are full of people with budgets and problems, gathered specifically to learn something useful. A short, practical talk at one of these events converts remarkably well, because everyone there has already chosen to spend time on the subject, and you are the person who has just shown them something they can use.

The best talks are practical, specific and short. Not the future of AI in business, which every attendee has heard several times, but how a practice like yours can cut a day off month-end with a tool that costs less than lunch, delivered with a live demonstration on realistic data. Show one or two things working. Give the audience something they can try that evening. Leave time for questions, because the questions are where the real conversations begin.

Building in the room, as Part Six described, is particularly powerful at a meetup. Ask the audience for a problem they face, and solve a small version of it live with Claude. It does not need to be elaborate. A drafted reply to a difficult customer email, a summary of a long policy document, a quick tool that does a calculation they currently do by hand. The audience sees the capability on their own kind of problem, in real time, and many of them will want to talk to you afterwards.

Prepare the follow-up before the talk. A short page with the main points, the prompts you demonstrated and a link to your free tool or relevant case studies. An easy way for people to book a short call. A small number of slots for diagnostic conversations in the following weeks. The talk creates interest; the follow-up converts it into conversations. Without the follow-up, the interest evaporates within days.

A room of twenty people with the same problem is the best audience a specialist will ever have.

Organisers of local groups are often looking for speakers, especially ones with something practical to say. Approach them with a clear, specific talk proposal, relevant to their members, with a promise of practical takeaways and no sales pitch. Then keep that promise: a talk that turns into an advertisement loses the room and the organiser's goodwill. The sale happens afterwards, in the conversations, because you were useful.

Talks compound. A good talk leads to invitations to give it elsewhere. Recordings or write-ups become part of your public work. Attendees become clients, who become case studies, who become examples in your next talk. A specialist who gives a useful talk in their niche every month or two will, within a year, be widely known in that niche, which is precisely the position this book recommends.

This week, find two or three groups where your buyers gather. Draft a practical twenty-minute talk with one live demonstration and one take-home technique. Approach an organiser. Then prepare the follow-up page and the booking link before the date arrives, so the interest you create has somewhere to go.

Own Your Niche Search

Be listed everywhere your specific buyer looks. Directories, partner pages, marketplaces, association lists, vendor ecosystems. Boring distribution beats brilliant content nobody finds. A buyer in your niche who decides to look for help with AI does not start by reading thought leadership. They search, ask their association, check the partner page of the software they already use, or look at a marketplace of approved providers. If you are not there, you are not considered.

Start by mapping where your buyers look. Ask your existing clients how they would search for someone like you if they had to start again. Look at the software your niche commonly uses and whether those vendors list implementation partners or consultants. Check whether the sector's professional associations maintain lists of approved suppliers. Find the marketplaces where businesses in your niche buy services. Each of these is a door through which buyers arrive, already qualified and already looking.

Then get listed, properly. A clear, specific profile that says exactly what you do and for whom: not AI consultant but AI workflow fixes and audits for small accountancy practices. Your named offers, briefly described. Two or three relevant case studies. Clear next steps. Many listings are free or inexpensive; some require an application or accreditation. The effort is modest and the listings work for years with occasional updates.

Your own website matters too, and it should be built for the searches your buyers actually make. A page for each named offer, written in your buyers' language, answering the questions they ask. Case studies grouped by sector and engagement type. Your free tool, easy to find. Claude can help you draft and refine these pages, but the specificity has to come from your knowledge of the niche. Generic pages attract generic visitors; specific pages attract buyers.

The best content in the world loses to a plain listing in the one place your buyer actually looked.

AI-driven search is changing how buyers find providers, too. Increasingly, people ask an assistant to recommend someone for a specific need. Those assistants draw on what is published and listed about you. Clear, specific, consistent descriptions of what you do, for whom, with evidence of results, across your website and listings, make it more likely you are found and described accurately. The principles are the same as for human search: be specific, be consistent, be present.

Maintain your listings. Outdated profiles, broken links and old case studies suggest a practice that is not paying attention, which is the opposite of what you want to convey. Set a reminder each quarter to review and update every listing. It takes an hour and keeps the doors open.

This week, list every place a buyer in your niche might look for help like yours. Check whether you are present in each. Pick the three most important where you are absent or poorly represented, and fix them. Then ask your next new client how they found you. Their answer will tell you which doors are working.

Publish the Waitlist

Capacity constraints are real and worth stating. A micro-consultant can only run so many engagements at once. When you are fully booked, the instinct is to hide it, either because it feels like turning away business or because it seems boastful. Instead, publish it. A visible waitlist, with the next available start date, reframes the conversation from whether to hire you to when you can start.

The psychology is straightforward. A consultant who can start tomorrow raises a small, unspoken question: why are they available? A consultant whose next start date is several weeks away signals that other people have chosen them, and that their time is valuable. The buyer's question shifts from should we hire this person? to should we book a slot before someone else does? That is a far better question for you, and it is entirely honest if your calendar really is full.

Make the waitlist practical. State the next available start date for each type of engagement on your website or in your replies. Offer a simple way to reserve a slot, perhaps with a small deposit that is credited against the fee. Keep in touch with people on the waitlist, sharing useful material and confirming their start date as it approaches. Some consultants offer a paid audit or discovery as a way to begin before the main engagement slot opens, which keeps momentum while the buyer waits.

The micro-engagement format makes this easier to manage. Because engagements are short and fixed, you can predict your capacity with reasonable confidence. You know that a two-week sprint occupies two weeks, that you can run so many at once, and when each slot frees up. A practice built on open-ended engagements can never publish a reliable waitlist, because nobody knows when anything ends.

Availability is a signal. Make sure it says what is true: that good work takes time and other people already know it.

Be honest. A fake waitlist, claiming to be booked when you are not, is a manipulation that buyers detect quickly and resent deeply. Publish a waitlist only when your capacity is genuinely limited, and keep the dates accurate. If a slot opens unexpectedly, offer it to the next person on the list. Integrity in small things builds trust in large ones.

A waitlist also gives you information. If it grows long, you may be underpriced, or ready to productise further, or ready to bring in help. If it stays short, your pipeline needs attention. Either way, the waitlist is a simple, visible measure of demand that helps you make decisions about your practice.

This week, look honestly at your capacity for the next three months. If you are close to full, publish your next available start dates and a way to reserve a slot. If you are not, note what it would take to reach the point where a waitlist made sense, and work towards it. A full calendar with a visible queue is one of the most comfortable positions a consultant can be in, and one of the most persuasive.

Warm Beats Cold

Your last five clients know everyone you want to meet. Systematic follow-up with past clients and dormant contacts outperforms any cold channel you will ever build. People who have worked with you, or met you, or seen your work, already trust you to some degree. People who have never heard of you trust you not at all. Starting from some trust is a vast advantage, and most consultants waste it by letting relationships go quiet after an engagement ends.

The fix is a simple, regular system. Keep a list of past clients, champions, referrers, meetup contacts and people who expressed interest but did not buy. Every month or two, get in touch with a few of them, not to sell but to be useful: a relevant article, a new tool, a note about a capability that has improved, a question about how the system you built is going. Each contact keeps the relationship warm. Some of them turn into conversations, and some of those into engagements.

Past clients are the warmest of all. They know your work, they have seen results and they probably have more problems you could solve, many of them already on the parked list from your scope creep protocol. A short note a few months after handover, how is the triage system working? I noticed you mentioned the returns process during the sprint; would it be useful to look at that now?, is often all it takes. Repeat business from past clients is usually the easiest, fastest and most profitable work a practice can win.

Claude can help you run this system without it becoming a chore. Keep your contacts and notes in one place. Periodically, ask Claude to suggest who to contact and draft a personalised note for each, based on your notes about the person, their business and your last conversation. Review and edit each one, because it must sound like you and be genuinely relevant. The model does the drafting; you supply the relationship.

Your network is not who you know. It is who you have kept in touch with.

Be genuinely useful, not merely present. A message that says just checking in is easy to ignore. A message that says I saw this change in your sector's regulations and thought of the policy documentation we did; here is a quick note on what it means for you is valuable, and it reminds the recipient why they valued working with you. The aim is for every contact to be welcome, so that people look forward to hearing from you.

Track what happens. Over time, you will see which kinds of contact lead to conversations, which past clients come back, which referrers send the best introductions. That knowledge helps you focus your effort where it works. Most consultants who do this find that a large share of their work comes from people they already knew, which is a reassuring discovery for anyone worried about finding the next client.

This week, list your past clients and warm contacts. Pick five. For each, write a short, genuinely useful note based on what you know about them, and send it. Then put a recurring reminder in your calendar to do the same every month. It is the most reliable pipeline you will ever build.

Write the Playbook

Publishing your method costs you almost nothing and makes you the obvious person to hire. It feels counterintuitive: if you explain exactly how you run an audit, a workflow fix or an agent pilot, will clients not simply do it themselves? A few might. Most will not, because knowing how something is done is very different from having the time, skill and experience to do it well. What publication does is demonstrate, beyond doubt, that you know what you are talking about.

A playbook can take many forms. A series of articles describing your approach to each engagement type. A downloadable guide for your niche. A set of openly published skills or templates. A book, even, of the kind you are reading. Each one shows your thinking in detail, and detailed thinking is far more persuasive than claims of expertise. A buyer who has read your playbook arrives at the first conversation already understanding your approach and largely convinced it is right.

The reason it rarely cannibalises your business is simple. The people who could execute your method from a written description are mostly not your buyers. Your buyers are busy people running businesses, who want the result without spending months learning to produce it. Reading your playbook shows them that the result is achievable and that you are the person who can achieve it. The minority who try to do it themselves often discover how much judgement is involved, and some of them call you afterwards.

Claude can help you write it, from the material you already have: your engagement templates, your case studies, your runbooks, your notes from talks. Ask it to draft chapters or articles from that material, then edit heavily, adding the stories, judgements and caveats that only you know. The finished playbook should sound like you, reflect what you actually do and be honest about what is hard. A playbook that makes everything sound easy will be read as marketing and discounted accordingly.

Give away the recipe. Most people would still rather someone else cooked.

Publication also sharpens your practice. Writing down how you do something forces you to clarify it, and clarity improves delivery. Readers ask questions and point out gaps, which improves the method. And a published method becomes a training resource if you ever bring in collaborators or partners, who can learn your approach from the same material your clients read.

This is the natural culmination of this part. Case studies prove individual results; referrals and warm contacts bring people to you; teardowns, free tools, public building, talks and listings make you visible. A published playbook ties it all together into a single, authoritative statement: this is how I work, this is why it works, and this is what you can expect. In a crowded market full of vague promises, a clear, specific, published method is a rare and valuable thing.

This week, write the first chapter of your playbook: how you run your most common engagement, step by step, with the reasoning behind each step. Publish it somewhere your buyers will see it. Then notice who mentions it in the next few conversations. You may find it does more selling than you do.

Sell Systems, Not Sessions

A session ends when you log off. A system keeps producing at three in the morning. That distinction is the foundation of where micro-consulting is heading. The consultant who sells sessions, workshops, advice, hours of attention, is selling something that stops the moment they stop. The consultant who sells systems, workflows that run, skills that load, agents that process, tools that answer questions, is selling something that keeps delivering value long after the engagement ends.

This book has been building towards that idea from the start. The workflow fix leaves behind a working workflow. The prompt kit leaves behind tested prompts. The skill library leaves behind capabilities. The agent pilot leaves behind a system processing real work. The documentation sprint leaves behind knowledge that both people and models can use. Each engagement is small, but each one produces something that outlives it. Over time, a client accumulates systems that you built, each still running, each a reminder of your value.

Designing for this changes how you approach every engagement. The question is not only what will we do together? but what will keep working after I leave? That question pushes you towards the habits this book has recommended: clear runbooks, trained champions, evaluation sets, guardrails in the system rather than in a document, prompts handed over, everything versioned and owned by the client. A system that depends on you to function is a session in disguise.

Pricing follows design. A session is priced by time, because time is what it consumes. A system is priced by value, because value is what it produces, and it produces it continuously. A modest engagement that leaves behind a system saving many hours every week is worth far more than a workshop of the same length, and clients understand this when it is shown to them clearly, with a baseline, a measurement and a running total.

Sessions are remembered. Systems are relied upon. Reliance is the stronger relationship.

There is a deeper shift underneath. As AI capabilities improve, the value of a consultant's live attention in any one session is falling, because much of what that attention used to provide can now be provided by the tools. The value of designing, building and maintaining systems that harness those tools is rising, because that requires judgement, context and care that the tools do not supply on their own. Selling systems puts you on the right side of that shift.

None of this means sessions are worthless. A good training session or a strategic workshop can be enormously valuable, and some clients need exactly that. But even a session can be designed to leave a system behind: a prompt kit from the training, a decision framework from the workshop, a skill encoding the method the team learned. The best sessions are the ones that become systems.

This week, review your offers and ask of each: what keeps working after I leave? If the answer is nothing, redesign the offer so that it leaves something behind. If the answer is a system, make sure your pricing, proposals and case studies say so clearly. You are not selling your time. You are selling machines that keep working, with your judgement built in.

Agents That Report Their Value

The next tier of engagement is a system that runs the workflow and reports its own value. Every month, without anyone asking, it produces a short account of what it did: how many cases it handled, how much time that saved, what quality scores it achieved, which problems it flagged, what changed. When the agent justifies its own invoice, renewal stops being a conversation and becomes a formality.

The building blocks are already in this book. An agent or workflow that handles real work, from the pilot chapter. A log of every action and its outcome, from the human-in-the-loop design. An evaluation set rerun regularly, from the acceptance chapter. A baseline from the start of the engagement, from the close-the-loop chapter. Put them together and you can generate a monthly report automatically: volume, time saved against baseline, quality score, exceptions, improvements made, recommendations.

Claude can produce that report from the logs and evaluation results with very little supervision once the template is in place. Your role becomes reviewing it, adding commentary where judgement is needed and sending it to the client. The report does three things. It shows the client the value they are receiving, in their terms, every month. It gives you an early warning when quality slips or volume changes. And it builds an ever-growing record of results that makes the case for renewal, expansion and referral.

Be scrupulously honest in these reports. Time saved should be calculated from a stated method, against the baseline agreed with the client. Quality should be measured against the agreed rubric. Problems and failures should be reported, not hidden. A report that only ever shows good news will eventually be distrusted. A report that shows the occasional problem alongside the overall value, and explains what was done about it, is believed, which is the whole point.

The best renewal argument is one the client has been reading every month for a year.

This changes the economics of retainers in your favour. A retainer justified by monthly evidence of value is far stickier than one justified by a vague sense that things are working. It also supports pricing: a system that demonstrably saves a great deal of time each month can carry a monthly fee that reflects a fair share of that value, and the client can see the arithmetic for themselves.

There is a frontier further out, where systems not only report value but take on more of their own improvement, proposing changes based on the cases they handle and the scores they receive, for a human to approve. That is beginning to be practical, and it fits the pattern of this book: autonomy expanded where evidence supports it, with a human holding the judgement. Build the reporting first. The improvement loop grows naturally from it.

This week, take a system you have delivered and design its monthly value report: the metrics, the baseline, the method, the format. Generate a first version from whatever logs and results exist. Send it to the client, even if it is rough. Watch their reaction. Clients rarely receive this kind of evidence from anyone, and the first one tends to make a lasting impression.

Own the Eval Layer

As models become more capable and more widely available, the scarce skill becomes knowing whether their output is good. Anyone can generate a plausible report, a plausible reply, a plausible piece of code. Far fewer people can tell, reliably and at scale, which of those plausible outputs are actually right for a particular business, and which are subtly wrong in ways that will cost money later. Whoever owns that measurement owns the trust, and trust is what gets paid.

The evaluation layer is the set of tools, cases, rubrics and processes that answer the question is this good? for a specific client's work. It includes the evaluation sets built during engagements, the rubrics agreed with the client, the verifier agents that check outputs, the logs of human approvals and corrections, and the monthly reports that track quality over time. Built well, it lets a client know, at any moment, how well their AI systems are performing and where they need attention.

For a micro-consultant, owning this layer is a durable position. Models change; the evaluation layer persists and gets more valuable as it grows. Every new case added, every rubric refined, every failure captured makes it a more accurate picture of what good looks like for that client. When a new model arrives, the evaluation layer is what tells the client whether to switch. When a system misbehaves, it is what reveals the problem. When the client wants to expand AI use, it is what tells them whether the expansion is working.

This also changes the nature of your relationship. A consultant who builds systems is valued for the build. A consultant who maintains the evaluation layer is valued continuously, because they are the client's trusted judge of quality. That is a very natural basis for an ongoing arrangement, and it is hard to replace, because the evaluation layer embodies years of accumulated understanding of what the client needs.

Generating answers is getting cheap. Knowing which answers to trust is not.

Building the evaluation layer starts small, in every engagement. Write the evaluation set before you build. Agree the rubric with the client. Capture every real failure as a new test case. Keep the cases, rubrics and results in a versioned repository the client owns. Run them regularly. Over a few engagements with the same client, this becomes a substantial asset, and you are the person who knows it best.

It is also a skill worth developing for its own sake. Designing good evaluations, choosing representative cases, writing rubrics that capture what matters, detecting when a score is misleading, is an expertise in growing demand. Consultants who become known for it will find that clients come to them not just to build systems but to judge them, including systems built by others.

This week, for one client or one system of your own, gather every evaluation case, rubric and quality record you have into one place. Note the gaps: kinds of work with no tests, failures that were never captured as cases. Fill one gap. You are building the asset that will matter most as everything else becomes easier to produce.

Upgrades Are Free R&D

Every model release can improve everything you have already shipped, if you have built for it. A system designed well, with clear instructions, clean context, structured outputs, bundled scripts and a strong evaluation set, can usually take advantage of a more capable model with little or no rework. Run the evaluation set against the new model, review the results, adjust where needed and switch. The capability gain lands in the client's system, and you did not have to fund the research that produced it.

That is a remarkable position to be in. Most businesses have to invest to improve their products. Here, a substantial part of the improvement arrives from outside, regularly, as the model providers release better models. Your job is to make sure your systems can receive those improvements smoothly, and to be the person who tells the client what changed and why it matters. That is a natural part of a retainer, and a compelling reason for a client to keep one.

Building for upgrades means avoiding tight coupling to the quirks of a particular model. Instructions that rely on a workaround for a specific weakness may become unnecessary, or even counterproductive, when the weakness is fixed. Prompts that are clear, well structured and based on general principles tend to transfer well. Keep model choices in configuration rather than scattered through code. Keep workarounds documented, so you know which ones to revisit when a new model arrives.

The evaluation set is what makes upgrades safe. Without it, switching models is a gamble: the new model might be better in general but worse on some specific case that matters to the client. With it, you can see exactly how the new model performs on the client's real work before switching. Sometimes the improvement is dramatic. Sometimes it is modest. Occasionally, on a particular task, the existing model is still the better choice. The evaluation tells you which.

Build so that progress you did not pay for still arrives at your client's door.

Upgrades are also an opportunity to revisit what is possible. A task that was too difficult for the previous model might now be within reach. A human checkpoint that was necessary might now be safely relaxed for some action types, if the evidence supports it. A workflow that needed several steps might now be done in one. Each of these is a potential improvement to propose to the client, and many of them are natural micro-engagements in their own right.

Be careful not to promise future improvements you cannot guarantee. Model progress has been rapid, but its exact course is unpredictable, and not every release improves every task. Tell clients that their systems are designed to benefit from improvements, and that you will evaluate each significant release, rather than promising specific gains on specific dates.

This week, check one of your systems for model coupling. Are the model choices in configuration? Are the workarounds documented? Is there an evaluation set ready to run against a new model? Fix whatever is missing. The next significant release will then be an opportunity rather than a disruption, and you will be the first to tell your client what it means for them.

Compounding Side Builds

Every build should reuse the last one's components. A consultant who starts each engagement from a blank page works hard forever. A consultant who builds deliberately on previous work finds that each engagement is faster than the last, because more of it is already done. Two years of that produces a library of components, skills, templates and tools that nobody can catch up to in a quarter, and it is the quiet engine behind every efficient practice.

Compounding requires intention. As you work, notice what is general and what is specific. The structure of an audit report is general; the client's findings are specific. A script that cleans a common export format is general; the client's data is specific. A skill for drafting case studies is general; the case study is specific. Extract the general parts into your own library, clean them up, document them and use them next time. Keep the specific parts with the client.

Side builds accelerate this. In quieter weeks, or a few hours each week, build things for yourself that make future engagements faster: a better prototype template, a new free tool for your niche, a skill that automates a part of delivery you find tedious, a set of synthetic datasets for your sector. Each side build should reuse the previous ones, so the library grows coherently rather than as a pile of unrelated experiments.

Claude makes side builds cheap enough to be worthwhile. A component that would once have taken a week can often be built in an afternoon. The constraint is not the building but the discipline to build things that compound, rather than things that are merely interesting. Before each side build, ask: will this make my next engagement faster or better? Will it reuse something I already have? Will something future reuse it? If the answers are yes, build it.

The first build is work. The tenth build, on top of the first nine, is leverage.

Organise the library so you can find things. Version it, as the chapter on canons recommended. Name things clearly. Keep a short index of what exists and what each piece is for. A library you cannot search is a library you will not use, and components you cannot find get rebuilt from scratch, which defeats the point.

The compounding is visible to clients, too. A consultant whose prototypes are polished from the first day, whose skills already understand the sector, whose templates already fit the engagement, delivers more in two weeks than a newcomer could in two months. Clients may not know why, but they notice the result, and they tell others. That reputation compounds alongside the library.

This week, look at your last three engagements and list the components you built for each. Mark which ones were general and could be reused. Extract one, clean it up and add it to your library with a short note. Then plan one side build for the coming month that builds on something you already have. Small, consistent additions are how a library becomes an advantage.

The Skill Library Moat

Anyone can buy the model. Nobody else has your forty encoded workflows, tuned on real client work. That library of skills, refined across many engagements in a particular niche, is the only genuinely defensible thing a micro-consultant owns. Models are available to everyone. Techniques are published freely. General knowledge is a search away. What is scarce is the accumulated, tested, specific capability that comes from doing the same kind of work many times and encoding what you learned.

Think about what a mature skill library contains. Skills for each engagement type you run: the audit, the workflow fix, the documentation sprint, the prompt kit, the pilot. Sector references with the jargon, regulations and common pitfalls of your niche. Templates for proposals, runbooks, case studies and reports. Verification skills with rubrics tuned to what your clients value. Scripts for the mechanical work your sector needs repeatedly. Each element is useful alone. Together, they let you deliver work of a quality and speed that a newcomer, even one with the same models, cannot match.

The moat is not secrecy. As earlier chapters argued, you should hand clients the skills built from their context, and you can publish much of your method. The moat is accumulation. A competitor could read your playbook and copy your approach, but they cannot instantly acquire years of tuning on real cases, the hundreds of small improvements prompted by real failures, the sector references refined across dozens of clients. That takes time, and time is the one thing a competitor cannot buy.

Protect the library by maintaining it. A skill library that is not kept current loses its value as models, tools and sectors change. Version it, test it against each new model, prune what no longer works, and add to it after every engagement. The library is a living asset, and like any asset it needs care. A neglected library becomes a liability: a set of outdated instructions producing subtly wrong results.

The model is the engine everyone can buy. Your skills are the car only you know how to build.

The library also changes the economics of your practice. With a strong library, a solo consultant can deliver at a scale that once required a team, because much of the expertise is encoded rather than carried in people's heads. It makes collaboration easier: a partner or associate can deliver to your standard by using your library. And it opens new possibilities: licensing parts of the library, offering it as a product, or using it as the foundation for systems that serve many clients at once.

Start building deliberately now, if you have not already. Every engagement should leave your library slightly better than it found it: a refined skill, a new sector note, an added test case, an improved template. Over a year, those small additions become substantial. Over several years, they become the moat.

This week, take stock of your skill library. List what you have, note what is missing for your core engagement types, and identify the one addition that would make the biggest difference to your next engagement. Build it, test it, version it. That is how a moat gets dug: one shovelful at a time, consistently, for years.

Fleet over Flagship

Ten small engagements earning steadily beat one heroic bet. The temptation in any consulting practice is to chase the flagship: the large transformation programme, the enterprise client, the contract that would fund a year at a stroke. Sometimes those are worth pursuing. But a practice built on a fleet of small engagements is more resilient, learns faster, generates more proof and, over time, often earns more than one built on a few large ones.

Resilience is the first advantage. A practice with one large client is one budget decision away from crisis. A practice with a dozen small clients, at different stages of the offer ladder, can lose one without serious harm. The fleet spreads risk across many relationships, sectors and engagement types. It also gives you options: if one kind of engagement stops selling, others continue, and you have time to adjust.

Learning is the second. Each small engagement is a complete cycle: diagnosis, scoping, delivery, measurement, handover. Ten small engagements a year give you ten complete cycles to learn from. One large engagement gives you one, and it takes so long that the lessons arrive too late to apply. Short cycles mean fast feedback, and fast feedback improves your method, your library and your judgement far more quickly than any amount of reading.

Proof is the third. Each small engagement produces a case study, a reference, a measured result. A fleet of small engagements produces a library of proof across many sectors and problems, which makes the next sale easier. One large engagement produces one case study, often confidential, often too specific to be useful to most prospects. Small work is surprisingly good marketing.

A fleet does not need any single ship to be extraordinary. It needs them all to keep sailing.

The fleet idea applies to products as well as clients. A practice can run a set of small free tools, each serving a slightly different need in the niche, each bringing in a stream of prospects. It can maintain a portfolio of small productised offers, each refined over many deliveries. The principle is the same: many modest assets, each contributing, none critical on its own.

There is a management cost. A fleet requires systems: standard engagement templates, a skill library, consistent delivery processes, organised client records. Without those, a dozen small engagements become a dozen sources of chaos. With them, each engagement runs on rails, and the fleet is manageable even for a solo practitioner. This is why the earlier parts of this book matter so much. They are the systems that make a fleet possible.

None of this rules out larger work. A large engagement that grows naturally from a series of successful small ones, with a client you know well, is a very different proposition from a large engagement chased cold. Let the flagships emerge from the fleet, rather than betting the practice on finding one.

This week, map your current practice as a fleet: how many clients, at which rung of the ladder, in which sectors. Note where you are over-concentrated. Pick one step that would spread the risk: a new small offer, a new sector, a new free tool. A fleet is built one modest vessel at a time.

The Two-Person Practice

Agentic delivery means headcount stops tracking capacity. Two people with a strong skill library, good systems and the habits in this book can now serve a client base that once required a much larger team. That is not a prediction about some distant future. It is visible already in practices that have reorganised around these tools, and it changes what a small consulting business can be.

Consider how the work divides. Much of what used to occupy junior staff, research, synthesis, drafting, building prototypes, writing documentation, running tests, producing reports, can now be done by Claude, directed by an experienced practitioner. What remains for the humans is the part that requires judgement and relationships: diagnosing problems, designing solutions, reviewing outputs, making decisions, building trust with clients. Two people who are good at those things, with agents doing the rest, have remarkable reach.

The skills of such a practice are different from a traditional agency's. Instead of managing people, the partners manage systems: skill libraries, delivery templates, evaluation layers, monitoring and reports. Instead of training juniors, they encode their judgement into skills and refine it continuously. Instead of hiring when demand grows, they improve their systems and productise their offers. Growth comes from leverage rather than headcount.

Two is a useful number, though not a magic one. A solo practitioner can do much of this, but has no one to cover holidays, review their work or share the load of selling and delivering. A pair can split the roles, perhaps one more focused on clients and one on systems, while each can step in for the other. They can review each other's work, which matters a great deal in a business built on trust. And two people can still make decisions over a cup of tea, without the overhead that larger organisations need.

Leverage used to come from people. Now it comes from systems that people design and judge.

There are honest risks. A small practice with large reach carries real responsibility: many clients depend on systems built and maintained by very few people. That requires discipline: rigorous evaluation, good monitoring, clear runbooks, trained champions in every client, and arrangements for what happens if one partner is unavailable. Small does not excuse fragile. If anything, it demands more care, because there is less slack.

There is also a temptation to stretch too far, taking on more clients than the systems can actually support, because the tools make it seem possible. Watch quality closely. The evaluation layer and monthly reports are your early warning. If quality starts slipping, slow down, strengthen the systems and only then take on more.

This week, imagine your practice at twice its current client load with no new hires. What would need to be true? Which systems would need to exist, which skills would need to be encoded, which processes would need to be standardised? Write the list. Then pick the first item and start building it. Capacity is no longer something you hire. It is something you design.

Teach It to Replace You

Encode every repeatable judgement you make into a skill, deliberately and continuously. The goal is not job security. It is capacity you can sell twice. Every task you do by hand that could be encoded is a task that limits how much you can deliver. Every task you encode frees your attention for the work only you can do, and lets the encoded version serve more clients than you ever could personally.

This sounds alarming to many consultants. If I encode what I know, what is left for me? The answer, which the final chapter makes plain, is the judgement that sits above any particular task: deciding what to build, for whom, why, and whether it is working. That judgement is not diminished by encoding the tasks beneath it. It is freed to operate at a larger scale. A consultant who has encoded their audit method can run more audits, but more importantly, can spend their time on the hard calls the audit method surfaces.

Start by noticing your repeated judgements. When you review an audit opportunity and decide whether it is worth pursuing, what are you looking at? When you scope a sprint and decide what to include, what rules are you applying? When you review a draft and decide it is good enough, what criteria are you using? Each of these is a judgement you make again and again. Write down how you make it, test the written version against real cases, and turn it into a skill or a rubric.

The encoded version will be imperfect at first. That is fine. Use it alongside your own judgement, compare the results, and refine it where it differs. Over time, it will handle the routine cases well, leaving you to handle the unusual ones. That division, routine cases to the system, unusual cases to you, is exactly right. It is also exactly the pattern you design for clients, applied to your own practice.

If you are the only one who can do it, you are the ceiling. Encode it and the ceiling moves.

There is an honesty test in this. If you find you cannot encode a judgement, because you cannot explain how you make it, that is worth knowing. Sometimes it means the judgement is genuinely tacit and requires experience that cannot easily be written down. Sometimes it means you are less consistent than you thought. Either way, the attempt to encode it teaches you something about your own expertise.

Teaching it to replace you also prepares your practice for growth. A partner or associate can work to your standard using your encoded judgements. Clients can receive skills that apply your method to their work without you present. Your practice becomes less dependent on your personal time and more on the systems you have built, which is the only way a small practice can grow without simply working longer hours.

This week, pick one judgement you make repeatedly in your work. Write down, as precisely as you can, how you make it. Turn it into a skill or a rubric, test it on five real cases, and compare its results with your own. Refine it. Then pick the next one. Each judgement encoded is a little more capacity that you can sell again.

Judgement Is the Last Job

Here is the whole book in one sentence: sell small, deliver fast, prove it, and let each yes earn the next, while keeping the judgement for yourself. Everything else, the hundred moves, the offers and sprints and skills and evaluation sets, is machinery for doing that well. Small engagements are easy to say yes to. Claude makes them fast to deliver. Measurement turns each one into evidence. Evidence turns into the next engagement. And through all of it, the thing the client is actually paying for is your judgement about what is worth doing.

Small, because the hardest part of consulting is the yes, and a small, fixed, specific engagement is the easiest yes a buyer can give. The paid audit, the two-week sprint, the prompt kit, the documentation sprint, the agent pilot, the training session: each is bounded, named and clear about what it delivers. A client who says yes to one has taken a small risk and, if you do your job, received a clear return. That is the beginning of a relationship rather than the end of a negotiation.

Fast, because the tools now allow it. Claude reads, drafts, builds, tests and verifies at a speed that collapses the effort behind a great deal of useful work. Prompt craft, curated context, Claude Code in the repository, skills and subagents, prototypes and artifacts: these are how a single practitioner delivers in two weeks what used to take a team two months. Price the outcome, not the hours, and that speed is yours to keep.

Proved, because unmeasured wins are forgotten. Baselines, evaluation sets, close-out numbers, monthly reports, case studies: these turn good work into evidence that the client can see, share and act on. Evidence earns renewal, referral and the next rung of the ladder. A practice that proves its value continuously never has to argue for it.

Everything below taste eventually automates. Keep automating your own work until all that remains is deciding what is worth building at all.

And judgement, because that is the part that does not delegate. What is the real problem behind the presenting one? Which of the opportunities in the audit is worth pursuing first? What does done mean for this client? When is a high evaluation score misleading? Which action should never be automated? Should this be built at all? Claude can inform every one of those decisions, often brilliantly, and you should ask it to. It cannot own them, because owning them means answering to the client for the consequences, and that responsibility has your name on it.

So keep automating your own work, task by task, deliberately, until what remains is the judgement. That is not a diminished role. It is the most valuable one in the business, and it is the one clients have always been paying for, even when it was buried under hours of research and drafting that no longer need to be done by hand. Start this week with the smallest engagement you can sell, deliver it quickly, measure it honestly and ask for the next. Then do it again. That is the playbook. It was never really about AI. It was about making it easy to say yes, and then making sure the yes was worth it.