How to write LinkedIn posts with Claude
By Ryan Melling, founder of WordPush
· 5 min read
Claude writes competent LinkedIn posts that read as machine-written. Why that happens, the prompts that fix it, and what you have to supply yourself.
Claude writes clean, structurally sound LinkedIn posts, and by default they read as machine-written. That is not a model failure — it is the predictable result of a thin prompt — but it matters, because the readers you want are the ones most likely to notice.
This is about closing that gap: what causes the generated-text signature, the prompt patterns that actually help, and the one ingredient no model can supply.
Why AI posts sound like AI posts
It is worth naming the tells precisely, because “sounds like AI” is too vague to act on.
The three-part list. Models love a triad. Three reasons, three lessons, three things nobody tells you. Once you notice it you cannot stop noticing it.
The reversal. “It’s not about the tool. It’s about the system.” A neat rhetorical move that has been used so heavily on LinkedIn it now reads as a watermark.
Even rhythm. Every paragraph roughly the same length, each one landing a beat. Human writing is lumpier — a long messy sentence, then four words.
The tidy ending. A closing line that resolves everything, usually generalising from the specific story to a universal principle. Real posts more often just stop.
Em dashes, everywhere. The most-cited tell, and the easiest to fix.
None of these is bad writing. The problem is that all of them together is a signature, and the signature is now common enough that it carries information: this person did not think very hard about this. That is the actual cost. Not the prose quality, the inference readers draw.
The real problem is the prompt, not the model
Here is the thing that changes results most, and it is not a template.
A thin prompt has nothing to work with, so the model fills the space with its own habits. “Write a LinkedIn post about leadership” contains no information. Every word in the output has to come from the model’s priors, which is exactly what produces the generic version.
A rich prompt has so much specific material that there is no room for the habits. Compare:
Write a LinkedIn post about hiring.
against
Last week I rejected a candidate who was technically the strongest in the process, because in the systems-design interview he talked over the interviewer twice and dismissed her follow-up. I went back and forth on it — he’d have shipped a lot. I don’t regret it but I’m not certain. Write this as a LinkedIn post for other founders who hire engineers. Around 150 words. No em dashes, no three-part lists, don’t end with a lesson.
The second produces something worth reading, because almost everything in it came from you. The model is doing shaping, not invention. That is what it is good at.
The prompt patterns that actually help
Four things, in rough order of effect.
1. Supply the situation, not the topic. A topic is a category. A situation is a thing that happened, with a specific detail in it. Models cannot invent your Tuesday.
2. Give it two or three of your own posts. Not as style instructions — as examples. “Match the voice in these” does more than any adjective you could choose. It is also the step almost nobody bothers with, and it is the one that most reliably removes the signature.
3. Ban the tells explicitly, with replacements. Vague requests to “sound natural” do very little. Specific bans work:
No em dashes — use full stops or commas. No three-part lists. Don’t open with a one-word sentence. Don’t end with a question.
4. Iterate out loud. The first draft is a starting position, not a deliverable. “That opener is too clever.” “Cut the last paragraph, it’s explaining the joke.” “Say the actual number instead of ‘significant’.” This is where a conversation beats a form, and it is the main reason to draft in an assistant at all.
The thing you have to supply
Specifics. One real number, one named situation, one opinion you would defend.
This is the whole game, and no amount of prompt engineering substitutes for it. A model can structure your thinking, tighten your sentences, find a better opening line. It cannot know that the client churned in month three, or that the feature took six weeks instead of two, or that you changed your mind about something you argued for publicly last year.
Posts that perform carry information the reader could not have got elsewhere. Posts that do not are rearrangements of things everyone already knows — which is precisely what a model produces when you give it nothing else to work with.
Where this leaves the voice problem
Even done well, there is a ceiling. A post Claude wrote sounds like Claude writing in your general direction, not like you. You can close most of that distance with examples and explicit bans, and you have to redo that work in every new conversation.
The structural alternative is to move the voice out of the prompt. If the drafting is done by a tool with a persistent model of how you write — built deliberately rather than inferred from a couple of pasted examples — then the assistant’s job becomes deciding what to say, and the voice comes from somewhere that does not reset.
That is how WordPush is built: its write_post tool generates in a voice constructed from an interview you do at signup, so the output is consistent across every post rather than depending on how good your prompt was that day. Claude still does the thinking, the judgement and the conversation. It just stops being the author.
You can connect it in about three minutes — see the Claude setup guide — and the full set of what it exposes is on the tool reference.
Publishing from the same conversation
Once Claude can publish, the workflow shortens considerably: the thing you were discussing becomes a post without a context switch, which is the main reason it gets written at all.
One setting worth getting right — keep publishing on ask-first. Scheduling is recoverable, publishing is not. Is it safe to connect LinkedIn to an AI assistant goes through the permissions properly.
The short version
Claude is good at shaping and bad at knowing things about your week. Give it the situation rather than the topic, show it your own posts rather than describing them, ban the tells by name, and iterate out loud. Then add the specific detail only you have.
That is the difference between a post that reads as generated and one that reads as written — and it is mostly work you do before the model starts, not after.
Related: how to use AI to write LinkedIn posts, how to write a LinkedIn hook, and what to post on LinkedIn for the harder problem underneath all of this.