The Claude Prompt I Run at the End of Every Client Project (and You Should Too)

Think about the last big thing you finished for a client.

Maybe it was a website. Maybe a member portal, or an onboarding system, or a Zapier automation with eleven steps that took you a full day to stop breaking. Maybe it was a reporting document you built from nothing that came out so well the client now sends it to their own clients.

Whatever it was, you solved something. And then you sent the invoice, closed the folder, and moved on to the next thing.

Six months later a different client describes a problem that sounds oddly familiar, and you have a vague memory of having cracked this before - but not enough of a memory to be useful. So you work it out again, from scratch, at your own expense.

That's the thing I want to fix in this post, and it takes about ten minutes at the end of a project.

First - have you set up your AI brain?

All of this files things into your knowledge base, which means you need to have one. If your business still lives in your head and eleven Google Docs called "FINAL final v3," start here instead: The Co-Founder Setup: How My Business Actually Runs on Claude. It walks you through building the filing system and connecting Claude to it. Twenty minutes, then come back.

Most client work runs on the same foundations

On the surface, every project is different. Different client, different industry, different brand, different opinions about the colour blue.

Underneath, an enormous amount of it is the same job wearing different clothes.

A member portal is a login, an approval step, a dashboard and some gated content - whether it's a fitness membership, a course platform or a client area for an accountant. A client onboarding automation is a form, a folder, a welcome sequence and a task list, whether the client is a coach or a construction firm. A monthly report is the same handful of decisions about what matters and how to show it.

You might spend three days getting one of those structures right. The flow from signing up to being approved to landing somewhere that makes sense. The automation that finally stops firing twice. The document layout that made the information land.

That work is yours. It's the most valuable thing you produce, and most people throw it away the moment the project ends.

So at the end of every client project, I have a conversation with Claude where we go through what we made and templatise anything I don't already have. Not the project. The pieces.

There are three prompts in that conversation.

To be clear: this is not reusing a client's work

Worth saying plainly, because it's the first thing people assume.

You built that thing for that client. They paid for it. It's theirs, and it stays theirs. You're not duplicating their project to hand a copy to the next person who asks - and you shouldn't want to, because it'd be a worse fit for the next client anyway.

What you're keeping is your own working-out.

A joiner who fits a kitchen doesn't keep the kitchen. They keep the jig they made to cut the angle - because the jig is theirs, they made it, and the next kitchen is faster because of it. That's exactly what this is. The client keeps the finished thing. You keep the technique.

So we're not saving their homepage - we're saving the animated background you spent an evening getting smooth. Not their automation - the branching logic you finally got right. Not their onboarding pack - the structure of it, with every word about their business taken out.

The bits that were hard, with everything that belongs to them stripped off.

Where it all goes

In my vault I've got a folder called Client Project Templates & Resources. Everything lands there, sorted by what kind of thing it is:

Client Project Templates & Resources/
├── Components/    → single pieces. a website feature, a form, a page layout,
│                    a section of a deck
├── Systems/       → multi-part builds. member portals, approval flows,
│                    onboarding journeys, booking processes
├── Automations/   → Zapier & Make scenarios, scripts, integrations - the
│                    ones that were fiddly, with the gotchas written down
├── Documents/     → proposals, onboarding packs, SOPs, reporting formats,
│                    anything where the structure was the clever part
└── INDEX.md       → one line per resource, so I can actually scan it

Rename them to suit your work. The INDEX file does more heavy lifting than you'd expect, though - a resource bank you can't see at a glance isn't a resource bank, it's a folder you forget exists.

Prompt 1 - get Claude to audit the project

The first prompt doesn't make anything. It looks at what you just finished, compares it to what's already in your vault, and tells you what's new.

That comparison is the important bit. You don't need a fourth version of a contact form or a fifth welcome email sequence. You want the things you've never made before.

Look at the project we've just finished, then look at my client project
templates & resources folder at [PATH TO YOUR FOLDER].

Tell me what we made in this project that isn't already in there.

I'm looking for anything I could reuse for a completely different client:
features & layouts, multi-step systems like logins or approval flows,
automations & the logic behind them, document structures, integrations that
were fiddly to get working, and anything you had to solve rather than just
produce.

Ignore anything that only makes sense for this client - their copy, their
branding, their specific content, their numbers.

Give it to me as a table: What it is | Where it lives | How reusable
(high/medium/low) | What it would take to make it client-agnostic.

Don't build anything yet. I want to choose from the list first.

That last line matters. Without it Claude gets helpful and starts producing, and you end up with fourteen templates you didn't ask for.

If the project isn't a folder on your computer - it's a Zapier automation, a Google Doc, a process that lives in someone else's tool - this still works. Point Claude at wherever it does live, or paste in a description of what you built, screenshots of the steps, or the document itself. It's reading what you made; it doesn't much care what format it arrives in.

What comes back is usually a mix. A few obvious wins, a couple of things you'd forgotten you'd solved, and some you'll look at and think no, that was a one-off. That's fine. It's a menu, not an instruction.

Then add your own - the bit only you know

Claude can see what's technically new. It can't see what you liked, or what took you three hours on a Tuesday that nobody will ever know about.

So before you go further, add yours:

Add these to the list, I want them templatised too:

- [the thing you were pleased with]
- [the thing that took far longer than it should have]
- [the structure you'd hate to work out again]

A real example. I built the Tech Queen Academy site with Claude, and it's got a background of stars that slowly zoom towards you. I love it. It isn't complicated, but getting it to feel right - the speed, the depth, how many - took proper fiddling.

Nothing about that belongs to TQA. It's a nice piece of motion. So it goes in Components, and next time I want that feeling on a different site, I'm not starting from a blank file.

Which brings us to the part that decides whether any of this is worth doing at all.

Saving a file is not the same as making a template

If I save that star background exactly as it is, I've saved a star background.

Next time I want the same effect but with butterflies drifting upwards, I open it, read code I wrote months ago, and start hacking at it. Barely better than starting again.

A real template pulls the choices out to the top where you can see them. Colour, size, speed, how many, which direction - as settings in one obvious place rather than numbers buried through the file.

And for anything that moves or renders something, there's a second, bigger split: separate the engine from the thing it's moving. The logic that drifts objects towards you at different depths doesn't care whether those objects are stars, butterflies or leaves. Build it so the movement lives in one place and what's on screen lives in another, and swapping stars for butterflies is one change instead of a rewrite.

The same principle applies to everything else in the bank, not just visual things:

• An automation - the trigger, the steps and the field mapping are the template. The client's account, their folder IDs and their email copy are the variables. Write them as a list at the top of the notes, not scattered through the steps.
• A document - the structure, the section order and the questions it answers are the template. Their name, their numbers and their examples come out and become clearly marked placeholders.
• A system - the flow is the template. Who approves what, in what order, and what happens when someone says no. The tool you happened to build it in is a detail.

Ask yourself one question: what will I want to be different next time? Everything in that answer becomes a setting. Everything else can stay as it is.

Prompt 2 - turn the chosen ones into resources

Now you name what you want and let it work.

Templatise these: [name them, or give me the numbers from the list].

For each one:

Pull it out as a standalone resource in my client project templates & resources
folder, in its own folder, named for what it does rather than who it was for.
File it under Components, Systems, Automations or Documents.

Strip the client out - their copy, their images, their colours, their content,
their numbers, their names. Replace anything I'll need to change with a clearly
marked placeholder.

Make the things I'm most likely to want different into settings at the top,
not values buried through the middle - colours, sizes, timings, counts, wording,
anything I'd change per client. If it renders or animates something specific,
separate the engine from the thing it's rendering so I can swap what's on screen
without touching how it works.

Strip every credential & connection - API keys, tokens, passwords, .env values,
connected accounts, account IDs. Leave the names of what it needs to connect to,
never the values.

Write a README in each folder: what it is, what it needs in order to run, how to
use it on a new project, what to change first, & anything that broke while we
were making it so I don't hit it again.

Then update INDEX.md with a one-line entry for each new resource, & give me a
summary of what you added.

Three of those lines are doing more than they look:

"Named for what it does, not who it was for." sarah-jones-onboarding tells you nothing in six months. client-onboarding-form-to-folder-to-welcome-sequence tells you exactly when to reach for it. Your future self searches by problem, never by client.

"A clearly marked placeholder." Visible, like [CLIENT NAME] or [BRAND COLOUR]. Not deleted, not swapped for something neutral - because when you reuse it you want to search for [ and have every decision light up in front of you.

"Anything that broke while we were making it." Every project has a moment where something goes wrong and you lose two hours. Write those two hours down once and you never spend them again. It's the most valuable line in the README and it's the one everyone leaves out.

A note on what you strip

For anything that connects to another tool - payments, calendars, email platforms, anything you had to log into - the connection needs credentials. In code they're API keys and they sit in a file called .env. In an automation it's the connected account. Either way, they're the client's, and they should never travel into a resource you intend to use for someone else.

Not everything that looks like a key is secret, so you're not paranoid about the wrong things: a Stripe key starting pk_, or a Supabase "anon" or "publishable" key, is designed to be public. Anything labelled secret, private or service_role, and any email password, is the opposite. Ask before you file it if you're unsure.

And for documents specifically, the thing to strip isn't a password - it's their information. Their revenue, their client list, their pricing, their staff names. It's easy to save a beautiful proposal template with the client's actual numbers still sitting in the examples.

Prompt 3 - the one that makes it worth having

The bank is useless if you forget it's there. So the third prompt runs at the start of something, not the end.

Before we start on this, look through my client project templates & resources
folder at [PATH].

Have we solved anything like this before? Tell me what I've already got that
applies here, what would need adapting, and what genuinely has to be made new.

Then start from those rather than from scratch.

Use it two ways.

When you're scoping a new project, so you know what you're really quoting for before you open your mouth about a price.

When you're dumping notes in after a client call. This is where it gets good. You paste in the notes from a meeting, and instead of starting cold, Claude comes back with you built something like this in March - here's what you did and here's what you'd need to change.

That's the difference between a folder of old files and an actual memory. Your knowledge base stops being a place you store things and starts being something that hands work back to you at the moment you need it.

When to do it

At the end of the project, before you move on. Not "when I get a spare afternoon," because you won't.

Right now the context is all still there - what broke, what you changed, the thing you'd do differently next time. In a fortnight it's gone, and you'll be looking at your own work wondering why you did it that way.

Same principle as writing up meeting notes straight after the call instead of on Friday when you can't remember what was agreed. Do it while it's warm. Ten minutes.

And run it on small things too, not just the big builds. A document layout that worked. A three-step automation. A way of structuring a monthly update that the client actually reads. Small resources are the ones you reuse most.

What you end up with

Not an archive of old client work. A toolkit, and a memory.

It compounds in a way almost nothing else in this business does. Every project you finish makes the next one lighter, because you're only ever solving what's genuinely new to this client instead of re-solving what you already worked out in March.

It's also what makes fixed-price work profitable. You're charging for an outcome. The outcome gets quicker to deliver, and the gap belongs to you - not because you're working faster, because you stopped repeating yourself.

There's a bigger version of this too. Someone who does client work has a calendar full of hours. Someone who builds a business has assets - templates, systems, documented ways of doing things - that make next month easier than this month. This is the cheapest asset you will ever build, and most of it is already sitting in the project you finished last week.

Start with the last thing you finished

You don't need a new project to begin.

Open the last thing you delivered, run Prompt 1, and see what comes back. You'll be surprised what's in there that you'd half-forgotten solving. Pick two, run Prompt 2, and you've got the start of a resource bank today.

If you haven't set up your knowledge base yet, that's the prerequisite - start here, then come back to this.

And if what you actually want is to stop selling hours and start selling projects at a fixed price, that's the thing I teach. My free training walks through the four shifts that get you there.

Watch the free training →