How I use a single Claude project to run content production for B2B clients

How I use a single Claude project to run content production for B2B clients

Most content marketers use Claude the same way every time. Open a new chat. Paste the brand guidelines. Re-explain the product. Describe the audience again. Type out the same formatting rules they typed last week. Then ask for a draft.

It works. Sort of. You get something back. But it reads like it was written by someone who just met the company five minutes ago. Every new chat starts from zero context.

Now multiply that across four clients, each with their own voice, their own product positioning, their own audience. You are spending more time setting up the conversation than actually using AI productively.

I stopped working this way about eight months ago.

Since mid-2025, I have been running every client's content operation through a dedicated Claude project.

The project contains the brand voice guide, writing standards, product documentation, competitor analysis, and custom skill files that handle specific tasks like content briefs and featured images.

When I open a new chat inside the project, Claude already knows the client. It follows the writing rules without being reminded.

And when I ask it to build a content brief, it does not just start writing. It asks me the right questions first. Do I have an SME transcript? Is there a specific product angle the client wants? Any competitor gaps to address? This is a question loop you can add to the skill.md file.

This "ask before executing" step is the difference between AI-assisted content and AI-generated content. The system handles the structure. I handle the thinking.

This article walks through the exact setup. What documents go into the project, how skill files work, and where the human layer fits in. If you produce content for B2B companies and you are still re-explaining context in every chat, this will change how you work.

Why a project, not just chats

If you have not used Claude Projects before, here is the short version. A project is a container. You upload documents to it, add custom instructions, and every conversation you start inside that project has access to everything you uploaded. Claude reads them when they are relevant to what you are asking.

Regular Claude chats do remember things across conversations now. But that memory is scattered. Claude picks up bits and pieces over time. You do not control what it retains. You cannot hand it a 15-page brand voice guide and know it will reference page 12 when writing a CTA next Tuesday.

A project gives you structured, deliberate context. You decide exactly what Claude has access to.

Say I upload a client's product documentation, their brand voice guide, and three sales call transcripts. I start a chat and build out a competitor analysis. A week later, I open a new chat in the same project to write a comparison blog post. Claude still has the product docs. But it can also pull from the competitor research I built in that earlier conversation. The context carries across every chat in the project.

For an ongoing content operation producing 8-12 articles a month, that persistent context is the foundation. But it is not the whole system.

Most people stop here. They upload documents, start chatting, and call it done. That gives Claude knowledge. It knows the product. It knows the audience. It can reference the brand voice.

What it does not have is a process. It does not know how you structure a content brief. It does not know that before generating anything, it should ask whether you have an SME interview transcript for this topic. It does not know your image style, your color palette, or that every featured image needs a unique visual concept instead of the same layout repeated.

That is what skills solve. Documents are the knowledge base. Skills are the operating procedures. The next two sections cover both.

The foundation: documents that define how you work

The first thing that goes into any client project is the reference material. These are standalone documents that Claude has access to in every chat. You upload them once and they become the knowledge base the entire project runs on.

Three documents form the foundation: the brand voice guide, the writing guidelines, and the client's product documentation. The voice guide tells Claude how to sound. The writing guidelines tell it how to write. The product docs tell it what to write about.

Brand voice guide

I build a brand voice guide for every client before a single piece of content gets written. It codifies how the brand sounds, who it speaks to, and what it stands for.

Most brand voice guides I see from clients are one-pagers with three adjectives and a tagline. "We are bold, innovative, and customer-first." That tells a writer almost nothing. It tells Claude even less.

A voice guide that actually works has real depth. The ones I build cover: brand essence and positioning, core values with descriptions of what each value looks like in practice, a detailed audience breakdown with specific pain points per segment, voice attributes with concrete guidance (not "be accessible" but "write for smart people who are new to this specific topic"), communication style rules, content do's and don'ts, key messaging phrases, and visual preferences.

The difference between a useful guide and a useless one comes down to specificity. "Marketing managers" as an audience tells Claude nothing.

"Marketing leads at growth-stage B2B SaaS companies who are getting traffic but no pipeline from content" tells it exactly whose problems to address. "Be authentic" gives Claude nothing to work with. "Share real numbers, real client results, and real mistakes. No polished corporate narrative" gives it a clear target.

Building a guide this detailed takes a few hours. It pays for itself within the first week because you stop re-explaining the same voice and positioning decisions in every conversation.

Writing guidelines

The brand voice guide changes per client. The writing guidelines stay the same across every project. They control how the content reads at the sentence level.

Mine cover sentence structure rules (25-word max, short paragraphs, one idea per paragraph), banned phrases and word substitutions (a list of filler phrases Claude should never use, and a table of complex words mapped to simpler replacements), formatting rules (heading hierarchy, list structure, adverb avoidance), CTA guidelines, SEO rules, and a common mistakes checklist.

Some of these are personal preferences. I swap "however" for "but" and avoid em dashes across my clients because I find the simpler versions read more naturally in B2B content. You might prefer them. The point is not my specific rules. The point is having your rules documented so Claude follows your style from the first draft instead of defaulting to its own.

Before I added this document, every draft needed the same round of edits. Break up long sentences for readability. Remove filler phrases. Fix the heading hierarchy. Replace the generic CTA with a benefit-driven one. Now Claude handles all of that on the first pass. My editing time goes toward the things that actually require a human: sharpening the argument, adding specific examples, and making sure the content says something a competitor's blog cannot.

Client and product documentation

The last piece is everything Claude needs to understand the client's product and market. Product docs, ICP profiles, feature-benefit pairings, sales call transcripts, competitor positioning notes, case studies with real metrics.

The goal is simple. Claude should understand the product well enough to explain how a specific feature solves a specific pain point for a specific audience segment. That requires more than a homepage summary. It requires the internal documentation that sales and product teams work from daily.

The more context in the project, the less you re-explain in every chat. And the less you re-explain, the faster the system works when you are producing content at scale across multiple clients.

Good, now I have the accurate picture. Here's the rewritten skills section:

Skills: teaching Claude repeatable processes

Documents give Claude knowledge. Skills give it process. Most people only do the first half.

What a skill is and when to build one

A skill is a set of instructions that lives in Claude's backend. Once you add it, Claude can use it across any project and any chat. You do not re-upload it. You do not paste it in. It is just there, ready to trigger whenever you ask for something that matches what the skill was built for.

The simplest way to think about it: a skill is a standard operating procedure for a specific task. It defines what steps to follow, what rules to apply, what questions to ask, and what the output should look like.

The rule of thumb for when to build one: if you are explaining the same process to Claude more than twice, it should be a skill. Content briefs, featured images, competitor analyses, article outlines. Any task where the structure stays the same but the inputs change is a candidate.

The real leverage is in how you design them. A skill that just says "write a content brief" is not much better than typing that into a chat. A skill that defines a research sequence, forces a question loop before execution, and includes a quality checklist produces consistent output every time.

Let’s look at two examples.

The content brief skill: how I built mine

The brief is the most important document in any content workflow. A vague brief produces a generic article. A sharp brief produces content that ranks and converts. So this was the first skill I built, and the one I have refined the most.

Here is what it does.

It runs a research sequence before writing anything. The skill tells Claude to read the client's product documentation first. Then search the target keyword, analyze the top 10 results, document what they cover, what format they use, who published them. Then identify content gaps: angles the top results miss, pain points they skip, ways the client's product solves the problem differently. Then check whether the client already has a live page for this keyword.

Each step builds on the previous one. Claude cannot write a useful brief without knowing what already ranks. And it cannot find a differentiated angle without understanding the client's product. The skill enforces that sequence every time.

It asks me questions before generating anything. This is the most important design decision in the skill. Before it produces a single line of the brief, it pauses and asks: Do I have an SME interview transcript for this topic? Is there a specific product feature the client wants to highlight? Are there competitor weaknesses to address? Any recent case studies or data points to include?

This is where my expertise enters the process. I feed in the transcript from my call with the client's head of product. I share the angle I want to take based on what I know about their pipeline goals. I flag a competitor gap I spotted during my own research.

Claude does not make these decisions. I do. The skill just makes sure it asks before it assumes.

Pro tip: Build a question loop into any skill where the output depends on the context you hold in your head. The questions force you to transfer that context into the conversation before Claude starts executing. It is the difference between "write me a brief" (Claude guesses) and "write me a brief using this transcript, this angle, and this competitor insight" (Claude executes with real inputs).

Then it generates a structured brief. The output covers the target audience and their pain points, search intent, the client's unique angle, a full article outline with H2s and H3s, SERP analysis, content gaps, product tie-ins, internal links, CTA strategy, and a quality checklist the writer uses before submitting.

I still review and adjust every brief. Sometimes I rework the angle. Sometimes I add a section the research missed. Sometimes it is 90% there and I just tighten the structure. But I am spending my time on strategic decisions instead of spending 15-20 minutes explaining the brief format, the audience, and the product context from scratch every single time.

The featured image skill

Every blog post needs a featured image. If you are publishing 8-12 articles a month, that is a lot of images that need to be on-brand and visually distinct from each other.

I built a skill that defines my brand color palette, composition rules, style preferences, and a library of visual concept categories Claude rotates through for variety. I also fed it screenshot examples from blogs whose visual style I liked. When I give it a blog topic, it picks a unique visual metaphor and builds an SVG image on the spot.

This skill went through three versions. The first baked the blog title into the image as headline text. Wrong, because the blog page already displays the title. The second used floating UI card layouts, but every image looked like a variation of the same template. The current version forces a unique visual concept per topic: chain links for link building, a constellation network for AI visibility, a mining scene for keyword research. Each thumbnail looks different on the blog grid while staying on-brand.

Skills improve as you use them. That iteration is part of the value. Your first version will not be perfect. Build it, test it, refine it.

Where AI stops and I start

I want to be direct about something. This system does not produce finished content. It produces strong starting points that still need a human who understands the client's business.

Anyone selling "AI writes your blog posts" is selling mirage content at scale. More output, same mediocrity. That is not what this is.

What the system handles

The system is good at structural, repeatable work. The kind of work that eats your time but does not require your judgment.

It builds structured briefs from uploaded product docs, SME transcripts, and SERP research. It drafts sections that follow the brand voice and formatting rules from the first pass because those rules are already in the project. It generates on-brand featured images without a designer. It maintains consistency across 10, 20, 50 articles for the same client because the guidelines do not drift the way human memory does.

And because the skills are designed with question loops, it flags when it does not have enough context. It asks instead of guessing. That alone prevents half the bad first drafts I used to get when prompting from scratch.

What still requires a human

Strategy. That is the short answer. The longer version:

I decide the content angle and keyword strategy. Not Claude. I know which keywords map to the client's pipeline goals. I know which competitor just launched a feature that opens a positioning gap. I know that the client's CEO mentioned a new use case on last week's call that is not in any document yet. That context lives in my head, not in a project.

I conduct or review the SME interviews. These are the conversations with product leads, customer success managers, and sales reps that surface the specific details generic content cannot replicate. "Our customers were spending 6 hours a week on manual reporting before switching" is the kind of detail that comes from a real conversation, not from Claude analyzing a product page.

I edit for depth. Every claim needs backup. Every section needs to add something new. Every intro needs to speak to the reader's actual problem, not a textbook version of it. When a draft says "this tool improves efficiency," I push it to say how, for whom, and by how much. That editorial judgment is not automatable.

And I run the final quality gate. One question: would the client's ideal customer learn something from this article that they cannot find on a competitor's blog? If the answer is no, it goes back for another pass. No amount of formatting or SEO optimization saves an article that does not clear that bar.

Why this balance matters for B2B content

B2B buyers are not casual readers. They have been in their industry for years, sometimes decades. They can tell within two paragraphs whether an article was written by someone who understands their world or by someone who googled the topic for an hour.

The system handles the 60% of the work that is structural and repeatable: formatting, consistency, organization, first drafts that follow the rules. I handle the 40% that requires judgment: strategy, positioning, the specific examples and contrarian takes that make a reader think "this person actually knows what they are talking about."

The result is not AI content. It is a higher volume of human-quality content because the system removes the friction that used to slow me down. I am not editing for sentence length and heading hierarchy anymore. I am editing for substance.

How to set this up for your own operation

If you want to build this yourself, here is the order that works.

Start with the documents. Brand voice guide and writing guidelines first. Do not rush them. Every shortcut here shows up as inconsistency later. If you are doing this for client work, build a separate project per client. Same writing guidelines across all projects. Unique voice guide, product docs, and competitor notes per client.

Upload the client's internal docs. Product pages, ICP profiles, feature-benefit pairings, sales call transcripts, case studies, sales decks, objection-handling notes. Everything the sales and product teams work from daily.

Then build one skill. Pick the task you repeat most often. For most content operations, that is brief creation. Test it on a real keyword. See where the output falls short. Tighten the instructions. Test again. Get one working well before you build a second.

The system compounds. A project with a solid voice guide, writing guidelines, product docs, and two or three refined skills produces better output in month three than it did in month one. Not because Claude got smarter. Because your system got tighter.

You need a Claude Pro or Team plan. Projects are available on both.

This is how I run content for B2B brands

This system is how I produce content that ranks on Google, shows up in AI-generated answers, and drives qualified pipeline for B2B companies. One project per client. Documents for knowledge. Skills for process. Human judgment for everything that matters.

It is not a magic button. It is a system that removes the repetitive friction from content production so I can spend my time on strategy, positioning, and the specific details that make content convert.

If you want this level of systems thinking behind your content operation, not just blog posts but a strategy mapped to revenue, let's talk.

Book a free strategy call to see how this approach can drive pipeline for your business.

Usama Khan

Usama is an AI SEO strategist for B2B brands. He helps businesses rank on Google and get recommended by LLMs like ChatGPT. He also watches too much cricket.

LinkedInX