22 skills, one brand voice: inside the LinkedIn system we built for our founder

This is a case study in brand voice AI, and it is about the least glamorous part of the problem. Everyone can get a language model to write a LinkedIn post. Almost nobody can get it to write a post that sounds like a specific person, three times a week, for months, without the feed slowly turning into the same confident grey paste every other automated account produces. The system described here is the one running behind Shreyas Dave’s personal LinkedIn account — twenty-two skills, five output formats, and a set of gates that decide what is allowed to ship. It is ours, so we can describe it down to the file.

The situation: one person, three platforms

Before any of this existed there was one person, an opinion about automation worth publishing, and the same bottleneck every founder-led account has: the writing only happens when the founder is free, and the founder is the least free person in the business. LinkedIn wanted three carousels and a couple of text posts a week. A long-form playbook was supposed to go out every fortnight. There was a YouTube channel with its own appetite. Each of those is a reasonable ask on its own, and together they are a full-time job that nobody had budgeted for.

What made it worse is that the work was not evenly hard. Deciding what to say took ten minutes; the opinion was usually already there, formed during a client build that morning. Turning the opinion into a post that opened well, held together, carried no unchecked claims and looked like the last one took hours. So the expensive part was the part with the least thinking in it, which is the signature of a task that should be systemised rather than endured. We have written about that test at length in what to automate in your content, and this project is what happens when you apply it to your own week instead of a client’s.

The obvious response was to hire or outsource the writing, and it fails for a specific reason rather than a snobbish one. The value of a founder’s account is that the reader believes a particular person is talking. A ghostwriter can produce competent posts quickly, and competent is exactly the register that kills a founder account, because the thing being sold is a point of view and points of view are not competent, they are particular. The problem was never production capacity. It was that the only person who could produce in that voice had no time, and the voice existed nowhere except inside his head.

Why “use AI to write your posts” fails

The first attempt was the one everybody makes. Open a chat window, describe the topic, ask for a LinkedIn post, edit the result. It works for about a week and then quietly stops working, and the way it stops is worth understanding because it is the reason the rest of this system exists.

A model with no specific instructions writes to the average of everything it has read, and the average LinkedIn post is a very particular genre: a short punchy opener, a list of three, a rhetorical question, a closing line that sounds like advice. Ask for that post ten times and you get ten variations on one shape. Nothing is wrong with any single one of them. The damage is cumulative, and it lands on the reader as a feeling rather than a thought — that they have read this before, from someone else, and there is nothing here that only this account could have said.

The second failure is factual and it is sharper. An automation account talks about tools, models, limits and pricing, which is the fastest-rotting category of fact there is. A model that was trained months ago will state last quarter’s version of the world with total confidence, and a post that names an outdated limit in front of an audience of engineers costs more credibility than three good posts earn. There is no amount of prompt politeness that fixes this. It needs a step that checks.

The third is the one that ends most attempts: editing a bad draft is slower than writing from scratch. If the model produces something eighty per cent right in the wrong voice, the founder spends forty minutes rewriting it and concludes that the whole idea was a waste of time. That conclusion is correct about the setup and wrong about the possibility. The fix is not a better prompt on the day. It is a system that already knows the answer to every question the prompt would otherwise have to carry — which is the argument in why automated content stops working, written after watching this happen to enough people that it stopped looking like bad luck.

What we built: twenty-two skills with fixed jobs

The workspace runs in Claude Code, and the unit it is built out of is a skill: a plain Markdown file with a name, a description of exactly when it should load, and then the rules themselves — the same shape as the instruction files Claude Code reads before it does anything. There are twenty-two of them. Each one owns one job and is not allowed to do another skill’s.

Written out, the twenty-two fall into groups. Five run the carousel pipeline: brand identity, topic generation, the post writer, the carousel creator, the PDF generator. Three run the long-form playbook chain — a topic researcher, a content writer, a designer. Five more cover a second platform, which has its own hooks, its own limits and its own hashtag rules. The rest are cross-cutting: the fact checker, the distribution playbook, the hook writer, the authority and conversion system, an adoption track for teaching teams to use AI, a prompt-engineering skill that governs every prompt the content shows, a cover-logo engine, a build-blueprint format and a one-page-post format. Together they come to over ten thousand lines of instruction. The two largest — the post writer and the carousel creator — are over a thousand lines each.

That number is the point rather than a boast. Ten thousand lines is what it takes to write down decisions that were previously being made by a person, silently, one at a time. Almost none of it is clever. It is things like: exactly six hashtags on LinkedIn and never six on the other platform, never an emoji unless asked, no politics ever, never analyse a post until it is at least a week old, never build the file before the words are approved. Each of those was a decision somebody used to hold in their head and occasionally get wrong.

The split into named files matters more than the total. A single enormous prompt has the same information in it and cannot be maintained, because when the openings start going flat there is nowhere to go and fix openings. With twenty-two files, a bad hook is a hook-writer problem, a drifting voice is an identity problem, and a stale statistic is a fact-checker problem. Every failure has an address, which is the same property that makes written process documentation useful in a business that has never automated anything.

Skill 1 is the whole system: writing a person down

One skill is read before every other one, every time, without exception: the brand identity. It is around six hundred lines and it is the reason the rest of the system produces anything usable. Its header is not a description so much as a set of triggers — write a LinkedIn post, generate a post, create a carousel, generate topic ideas, does this sound like me — followed by three flat prohibitions: do not generate content without consulting this skill, do not assume tone or topic without referencing it, and do not write generic AI-sounding posts, because every line has to pass the “sounds like Shreyas” test.

What makes it work is the level of detail. It does not say “write in a witty, conversational tone”, because that sentence carries no information — it describes about forty per cent of everything published on the platform. It defines what witty means for this specific person: not jokes, not sarcasm, not punchlines, but quiet observations that make a reader nod rather than laugh, with real examples pulled from his own posts. It sets sentence structure — short sentences, one idea each, paragraphs of one to three lines. It bans the registers he never wants to be in: motivational, corporate, aggressive, political, humble-braggy, jargon-heavy, over-explained.

It also carries the things a stranger could not guess. His real projects, so that credibility examples are true rather than invented. The audience he is writing for and the pain point he actually solves. A named framework he owns and repeats — SOLVE, for spot the robot work, outline the steps, link the tools, verify it survives real inputs, expand once it is trusted — because a repeated named method is what turns a run of posts into a body of work someone can cite.

This is the part most people skip, and skipping it is why their output reads as automated. A brand voice document is only useful at the level of specificity where you could hand it to a competent stranger and they could produce a passable imitation. Anything vaguer is a mood board, and the reason vagueness feels sufficient while you are writing it is the curse of knowledge, described by Colin Camerer, George Loewenstein and Martin Weber: once you know how you sound, you cannot tell how much of it you left out. The same principle drives how we build a client’s knowledge architecture: the value is not in owning the information, it is in having written it down precisely enough that something other than the original person can act on it.

The pipelines: what runs, in what order

Skills do not fire at random. Each output format has a fixed chain, and the chains never mix. A carousel runs topic generator, then post writer, then carousel creator, then PDF generator — with the identity skill loaded underneath all four and the distribution playbook loaded alongside it. A long-form playbook runs a research skill first, produces a chapter overview, stops dead until that overview is approved, then runs the content writer, and only then the designer. Skipping a step is not a shortcut here; it is the thing the order exists to prevent.

Two rules govern every chain and both are refusals. The first: nothing auto-posts. The workspace can write, design, export and queue, and the act of publishing is always a human one. The second: no file is built before the words are approved. The system shares the full draft in plain text, waits, and only writes HTML after an explicit yes. That rule exists because a beautifully designed carousel is emotionally expensive to reject — once the pictures are made, a mediocre argument tends to ship. Making approval come first keeps the decision cheap while it is still easy to make.

Around the chains sits scheduling. Eleven jobs run on a server rather than a laptop, on n8n’s own schedule triggers, and they cover the mechanical week: pull the account’s own analytics on Monday, generate topics, draft the week’s captions and slides, build the files, email them for approval, wait on a human-in-the-loop step for the reply, and — a week later, never sooner — fetch how each post actually did and fold that back into what gets suggested next. The delay is deliberate. Judging a post at twenty-four hours measures the first hour of distribution and nothing about whether it was any good.

The first fifty words get their own skill

LinkedIn shows roughly two lines before it truncates a post behind a link. Whatever is in those first forty to fifty words is what the ranking system reads and what the reader uses to decide. That is a small enough surface, and a high-stakes enough one, that it was given a dedicated skill rather than being left as a paragraph inside the post writer.

The skill holds five hook formats and a rule about which to reach for. Its most useful instruction is a piece of anti-advice: never size a hook by counting characters. Character counts are the standard trick and they are wrong, because what truncates a post is pixel width on a phone, and a line of narrow letters fits where a line of wide ones does not. The rule is to reason in mobile lines instead. It is a small thing that reveals the general shape of this kind of work — most of the value is in noticing that the obvious method quietly does not work.

The other non-negotiable is that every hook must open a gap. If the first two lines summarise the post, there is no reason to expand it, and a well-written summary is the most common way a good post dies. The skill also runs backwards: paste in a post that flopped and it rewrites the opening rather than the argument, on the assumption that the argument was usually fine and nobody ever saw it.

The fact checker nothing is allowed to skip

One skill sits across all of the chains rather than inside any of them. Before anything carrying a claim is exported — a carousel, a playbook, a one-page post — the fact checker runs, and it asks two separate questions about every claim. Is it true, and is it still true? The second question is the one that catches things, because in this subject area the facts that hurt you are not the false ones, they are the ones that were right last quarter.

It maintains a watchlist of the categories that rot fastest: model names and their pricing, software prices and free tiers, API versions and endpoints, platform limits, feature availability, and anything phrased as newest or latest. Each claim gets one of a small set of verdicts — it passes, it is stale and gets updated, it is wrong and gets replaced, it is illustrative and must be labelled as such, or it gets cut. Anything that survives and could move is stamped with the month it was verified, so a reader in six months can see the age of the claim rather than assuming it is current.

The rule underneath the whole gate is the one we hold ourselves to everywhere: never invent a statistic. If a number cannot be sourced honestly it becomes a direction — most, few, a large share — or the slide changes to one that does not need it. That is not a moral position so much as an arithmetic one. An unsourced number buys a small amount of persuasion once, and costs the account permanently the first time somebody looks it up. It is also the same standard Google describes as people-first content, which is a convenient alignment rather than the reason.

What comes out of the other end

There are five output formats, and the reason there is more than one is that a good idea does not always want the same shape. A swipeable carousel suits an argument with steps. A long-form playbook suits a subject somebody would keep. A short text post suits an observation. A dense single frame suits an idea that has to be seen all at once — the format people screenshot and save, which is where a surprising amount of reach on the platform now comes from.

Every format follows the same discipline the rest of the site does: the design is a locked template and the content is a data file. Nobody edits the HTML or the CSS of a template — a rule written down as a rule, because that is the exact point at which a visual system starts to drift. One post uses a slightly warmer background, the next one nudges a margin, and forty posts later the account looks like three different accounts. Fixing the template and varying only the words is what makes a feed recognisable from the thumbnail.

Export is a script rather than a person with a screenshot tool. The file is rendered at exactly the dimensions the platform wants and captured at double resolution, so text stays sharp on a phone. That sounds like a small detail and it is the difference between a document post that looks designed and one that looks photographed. It is also the step most likely to be done inconsistently by hand, which makes it the step most worth writing down — the same logic that decides what we automate in a client’s content automation build.

The weaker-model framework

The most transferable idea in this project is also the most counter-intuitive, and it is the one that answers the question of what all this actually costs to run.

Designing a system like this needs a strong model. There is real reasoning involved: working out what the failure modes are, deciding which rules are load-bearing, noticing that character counts do not size a hook. Running it every week needs almost none. Once the decisions are made, producing Tuesday’s carousel is following instructions — and following clear instructions is something a much cheaper, faster model does perfectly well.

So the strong model was given one more job: write the runbook that lets a weak one take over.

The runbooks are deliberately blunt. Where the main skills explain their reasoning at length, these are numbered steps with a lookup table for every decision and a copy-paste block for every piece of markup. They assume the reader remembers nothing and has no judgement to exercise, because that assumption is what makes them safe to hand to a smaller model — and, as it turns out, to a person on their first day. Every one of them ships with a worked example: the finished output, its source, and a walkthrough of how the second became the first.

Two things fall out of this that matter well beyond one LinkedIn account. The first is cost. Expensive reasoning is spent once, at design time, and the recurring weekly work runs on something cheap — which is the difference between a system a small business can afford to run and a demo it abandons after the first bill. The second is that the runbook is a genuine handover document. It is written to be followed by something with no memory of the conversation that produced it, which is exactly the property that lets a client’s team keep running a system after the people who built it have gone. We choose tools on the same basis, for the same reason, as set out in how to choose content tools.

The honest cost

No system is free to run, and a write-up that implies otherwise is an advertisement. Here is what this one asks for.

The build was not a project with an end date. It started as a voice document and a post writer, and almost every skill since exists because something went wrong in a way that could be named: a flat opening, a stale figure, a design that drifted, a deck that read like a template. The identity document has been rewritten more than any other file in the workspace, because a voice is easier to recognise than to describe and each attempt gets closer. Anyone expecting to install this in a weekend is expecting the wrong thing; the timelines we quote for a client build are in the FAQ, and they are measured in weeks for the same reason.

The weekly cost is real but small, and it is concentrated in the two places it should be. Someone has to decide what is worth saying, which cannot be delegated and takes about as long as thinking about it does. And someone has to read every draft before it ships, which is the approval gate and the reason the account still sounds like a person. The parts that used to take hours — shaping, opening, checking, designing, exporting — are the parts that got cheap.

There is also maintenance nobody warns you about. An access token expires on a fixed cycle and has to be refreshed by hand. A model gets renamed by Anthropic and a script that names the old one starts failing. A platform changes what it truncates. None of it is difficult and all of it is unglamorous, and a content system that nobody has budgeted an hour a month for is a content system that quietly stops working in the second quarter.

What changed

The honest answer has two halves, and we are going to say which is which rather than blur them together.

What can be described precisely is the shape of the work. Posting no longer depends on the founder having a free afternoon, because the expensive half of producing a post is now a pipeline rather than a mood. Three carousels a week, a fortnightly long-form playbook and a daily presence on a second platform are all being produced by one person who also runs client builds — which was not possible before and is the entire point. The voice is written down, so it survives a busy fortnight, and it is the same voice in a carousel as in a text post as in a playbook, because all three read the same document first.

What we are not going to do is put a follower number or an engagement percentage on this page. We could pull one, and it would be unverifiable by you and heavily confounded by everything else that happened in the same period. A number nobody can reproduce is worth less than a sentence that is true, which is the rule the whole case studies page is built on. If you want to judge the output, the account is public and the posts are all there, and the same stack is shown running end to end in our video library.

What transfers to a business

This was built for one person, and four things in it are not personal at all.

Write the voice down before automating anything. This is the step everyone skips and it determines whether the rest is worth building. For a company it is harder than for an individual, because several people write under one name and they do not agree as much as they think — which is itself worth discovering before a model is asked to average them.

Give every rule an address. A monolithic prompt cannot be improved; a set of named documents can — which is the whole argument behind the frameworks in our Knowledge Hub. When something is wrong, you want to know which file to open, and you want the fix to affect that thing and nothing else.

Put the gates where a human would get tired. A fact check before export, an approval before design, a delay before judging performance. Each of those is a discipline that people genuinely hold for about six weeks. Encoding them means the standard holds in a bad week too, which is the only week it matters.

Separate design-time reasoning from run-time execution. Build with the best thing you have; run on the cheapest thing that can follow instructions. Writing the runbook that makes that possible produces the handover documentation as a side effect — and a system your team cannot run without us is a system we should not have sold you. That is what a LinkedIn content system is when we build one for a client, and the reasoning generalises straight across to content multiplication on every other platform.

Frequently asked questions

Does AI write the posts, or does Shreyas?

Both, in a fixed order. The opinion, the story and the decision about whether something is worth saying are his and never delegated. The system’s job starts after that: it holds the voice rules, drafts against them, sharpens the opening, checks the claims and builds the file. Nothing publishes without him reading it, and the workspace is forbidden from posting to LinkedIn by itself.

How do you stop AI-written posts from sounding like AI?

By writing the voice down in enough detail that a model has something specific to obey. The identity skill is around six hundred lines: the one-line voice summary, a definition of what witty means for this person, the sentence-length rules, the hard bans, and real lines from his own posts as reference. Generic instructions like write in a friendly tone produce generic output because they contain no information. A voice document is only useful at the level of detail where you could hand it to a stranger and they could imitate the person.

Why 22 skills instead of one long prompt?

Because one long prompt cannot be improved in one place. When a hook lands badly you want to change the hook rules and nothing else, and when the voice drifts you want to change the voice document and leave the hook rules alone. Splitting the system into named files with fixed jobs means every fix has an address. It also keeps each piece small enough to read in full, which is what stops a rule being quietly forgotten.

What is the weaker-model framework?

A second set of instructions, written by the strong model, that lets a cheaper model run the same pipeline. The design work is where reasoning is genuinely needed; the daily production work is mostly following a decision you already made. So the expensive model is used once to build the system and to write a numbered runbook for it, and the cheap model executes that runbook. The runbook is deliberately blunt: lookup tables, copy-paste blocks, and a worked example rather than judgement calls.

How long did this take to build?

Months, and it is still being edited. The first version was a single voice document and a post writer, and almost every skill after that exists because something went wrong: a flat opening line, a stale figure, a design that drifted, a deck that read like a template. That is the honest shape of this work. A content system is not designed once and installed; it is a set of rules that accumulate every time the output is wrong in a way you can name.

Could a business run this without a developer?

The daily half, yes. Writing a post, generating a carousel and exporting the file are conversations in plain English with a runbook beside them, which is exactly what the weaker-model framework exists to make possible. The parts that genuinely need someone technical are the initial build, the scheduled jobs and anything touching an API token. That split is why we hand over documentation rather than a tool: the goal is that the team runs it after we leave.

Does this transfer to a company account, or only a personal one?

It transfers, with one change. A personal account has one voice to capture; a company account usually has several people writing under one name, which makes the voice document harder to write and more valuable once written. Everything else — the topic supply, the hook rules, the fact-check gate, the export step, the approval step — is the same machinery. The failure mode is also the same: teams try to automate the writing before they have written down what good looks like.

Where to start

If you take one thing from this, take the order. The instinct is to start with the tool, because the tool is the part that feels like progress and can be bought this afternoon. Every part of this system that works was written before it was automated, and the automation was the easy half. Open a document, write down how you actually sound — the words you use, the ones you refuse to, what a good opening looks like to you, what you would never publish — and be embarrassingly specific about it. That document is worth more than any workflow built on top of it, and you can write the first version in an hour.

Then automate one stage: whichever one you notice yourself avoiding. If you would rather the whole thing existed already, that is the work we do as a content automation AI agency — the voice document, the pipeline, the gates and the runbook, handed over as files your team owns. We build it in Claude Code where the work is writing and rules, and in n8n — or Zapier and Make.com where a team already lives in one of those — wherever the work is wiring between services.

Keep reading

• How to Post on LinkedIn Consistently — the supply problem underneath all of this, without the machinery.
• What to Automate in Your Content — the test that decides which stage gets a skill and which stays human.
• Content repurposing — the same one-source-many-formats idea, built for a client rather than for us.
• The rest of the case studies — the other systems we have built, written up the same way.