An article writing prompt that works: what I give the model,layer by layer

When someone shows me an article writing prompt, it often looks like this: "Act as an SEO web copywriter. Write a 1,500-word article on [topic], with H2s, an FAQ and a conclusion." What comes out is clean, neatly structured, and identical to what anyone else gets with the same request. Then it needs rewriting almost from scratch.

This blog is written with my content machine, and the one at Moonworkers, my company, publishes two articles a day. I don't use a long free-form prompt in either. The model gets a set of files to read, a validated brief and some examples, and an automated check then verifies whatever can be measured. Here is how I put that prompt together, layer by layer, with a template you can copy.

01Why the "SEO copywriter" prompt produces interchangeable articles

A role and a topic tell the model almost nothing. It doesn't know who is signing the piece, who it is talking to, what you have actually done, or which sources have been read. So it fills the gaps with whatever is most likely. Google's documentation puts it plainly: generative models don't retrieve facts, they predict a likely sequence of words, which is where the inaccuracies come from (Google Search Central). A likely text is an average text.

Anthropic suggests a very simple test: show your prompt to a colleague who doesn't know the task and ask them to follow it. If they are lost, the model will be too (Anthropic, Claude documentation). A colleague told to "write an SEO article about prompts" would ask you ten questions. The model doesn't ask. It guesses.

The second problem is more insidious. What it doesn't know, the model makes up convincingly: a client anecdote, a round number, a quote. On a blog with my name on it, a false anecdote is worse than no anecdote at all.

02What my model reads before it writes

Before the first line, the model reads a set of reference files. They are always the same, and they make far more difference between two articles than the wording of the request.

The fixed reference files

• The voice: who is speaking, to whom, in what tone. For me: first person, modest, concrete, sentences you would say out loud in a meeting.
• The closed list of usable facts: what I have done, on which kinds of project, what went wrong. Nothing outside that list. A separate list holds figures still "to be confirmed", which are never used.
• The structure of an article: frontmatter, headings, paragraph length, where the links go.
• The rules: confidentiality (no client is ever named), modesty, sources.

The validated brief

Next comes the article's brief, in summary form: keyword, reader, promise, angle, word budget, outline, real questions, sources read along with what each one supports, internal links. That brief has been validated by a command that answers "BRIEF REJECTED" for as long as something is missing: on this blog, at least 4 real questions with their origin, 4 sources read including 2 institutional ones, and 3 internal links. I go into more detail in my article on the content machine and human review.

Order matters. Anthropic's documentation advises putting long documents at the top of the prompt and the request at the end, which improved response quality by up to 30% in their tests on complex inputs (Anthropic, Claude documentation). I don't measure that gain on my own articles, but I have adopted the order.

03The writing prompt, layer by layer

In their "Prompting 101" talk, Anthropic's Applied AI team describe the structure they recommend when a task is sent in a single message: the task and the role first, then the content, detailed step-by-step instructions, examples, and at the end a reminder of what matters most. They add some tone context: stay factual, don't guess when you don't know (Anthropic, Prompting 101, YouTube video). My machine follows roughly that pattern.

1. The reference files, tagged

I separate each block with a tag. Claude's documentation recommends XML tags whenever a prompt mixes instructions, context, examples and inputs, so the model doesn't confuse one with another (Anthropic, Claude documentation).

2. The summarised brief

The brief comes straight after, always in the same format, so the model keeps it in view while it writes.

3. Yes and no examples

This is the layer that has helped me most. One sentence that sounds right, and one that sounds wrong:

• Yes: "On an integration between an ERP and an online shop, the specification changed at almost every meeting. I kept it moving version by version, so that everyone was talking about the same document."
• No: "With twenty years of experience, I help businesses succeed in their digital shift thanks to a unique approach."

Anthropic notes that examples are one of the most reliable ways to steer format, tone and structure, and suggests three to five, varied enough that the model doesn't pick up an unintended habit.

4. The request, short, with its reasons

The request comes last, and it is short. I explain the reason behind the instructions that remain: Anthropic's documentation shows that an instruction with its motivation generalises better than a "NEVER" in capitals. Here is the skeleton, to adapt. Each block goes between two tags, in this order:

• <voice>: who is speaking, to whom, in what tone, in ten lines at most;
• <allowed_facts>: the closed list of what the author has done, and of what went wrong;
• <structure>: the file format, the headings, paragraph length;
• <rules>: confidentiality, modesty, one figure means one source in the same paragraph;
• <brief>: keyword, reader, promise, angle, budget, outline, questions, sources read and what they support, internal links;
• <examples>: a <yes> sentence that sounds like the author, a <no> sentence that sounds like a brochure.

Then the request itself, in a few lines:

⟶ KEY POINTWrite the article described in the brief, in the first person, within the word budget. Use only the facts in <allowed_facts> and the sources in the brief: the article is signed by a real person, and an invented anecdote would harm them. If a section calls for experience that is not on the list, write it in general terms.

Notice what isn't there: no "SEO copywriter" role, no list of banned words, no number of H2s. Those rules exist, but they live somewhere else.

04What I take out of the prompt and hand to a check

A rule repeated in a prompt gets forgotten. A rule written in a configuration file, and checked by a tool, blocks. That is the principle behind my whole machine: the tool carries what can be verified, the writing keeps what needs judgement.

After the writing, a command reads the article against its brief and returns a red, amber or green verdict. Among other things, it checks:

1. the word budget and the number of headings;
2. a list of generated-writing tics, including the em dash and stock closing phrases, which are red;
3. the presence of the first person and of grounding in real practice;
4. client names and billed amounts, blocked everywhere, title and FAQ included;
5. that no percentage is left without its source in the same paragraph;
6. that every external link is in the register of sources read, and that every internal link exists.

Taking them out of the prompt has two effects. The prompt gets shorter, and the model concentrates on what can't be measured: the angle, accuracy, tone. And a rule that doesn't work gets fixed in a single place. On one assignment, a proofreader's feedback became written rules in the configuration, rather than corrections made by hand, article after article.

Google points the same way. It asks you to fact-check all generated content before publishing it, including the title, the meta description and image alt text (Google Search Central). And its spam policies target producing many pages of no value to the reader, however they are created (Google Search Central, spam policies). The prompt is only part of the answer.

05The limits of the method

It costs time before the first article. Writing the voice, the list of facts and the configuration takes far longer than any prompt. For one article a month I wouldn't do it: a good brief filled in by hand and a careful review are enough.

It doesn't create substance. If the list of facts is thin, the articles will be too, just better written. When a topic calls for experience I don't have, the article is put "on hold" instead of being written. Google's self-assessment questions make the same point: does the content provide original analysis, first-hand knowledge from having actually used the product or service (Google Search Central, helpful content)? No prompt manufactures that.

And it doesn't replace review. My articles go live with a "to review" status, and I read them on the site. The check catches what can be measured; it can't see that a paragraph is accurate but dull, or that an example misses the point. The bottleneck moves too: on one project it wasn't the writing but the publishing, which I describe in the article on automating publication.

06Where to start with your next article

You don't need to build a machine to begin. For your next article:

1. write ten lines on the voice (who signs, for whom, in what tone) and keep them in a file;
2. list what you have actually done on the topic, and forbid the model to go beyond it;
3. read three or four sources yourself and note what each one supports;
4. add one yes sentence and one no sentence;
5. review the result against a written checklist, and turn every recurring correction into a rule.

If you want to see how I set up this kind of content in Claude day to day, I cover it in Claude for marketing. The projects where I have put this in place are in the portfolio, and the way I work is described on the services page. If your content production looks like the prompt at the top of this page, we can talk about it.