Teach the AI with examples a person actually wrote

You ask an AI for the same kind of thing again and again, a client email, a weekly report, a landing page, and it keeps coming back average. Describing what you want harder doesn't help, because a model asked cold reaches for the middle of everything it has read. Showing it real examples of the output done well fixes that, and that half is well known.

The half that gets skipped costs more. It's the half people skip. One writer had a model build a profile of their voice partly from a folder of documents that read as their own. Checked later, the folder was advice a model had written to them and copy a model had drafted for them, carrying the machine's tells at many times the writer's own rate. The profile had learned some of the machine's habits and called them the writer's.

So the answer has two halves. Give the model real examples and the best guide you can find, then check that every example is human before a single rule is learned from it.

How it works

1. Name the output you want more of, plainly and narrowly, such as a kind of email, a weekly report or a landing page. Narrower is better, because the standard for one isn't the standard for another, even from the same hand.

2. Gather what good looks like. Collect two or three real examples of it done well, your own if they exist and the best in your field if they don't, plus the best guide or article on doing that work. Asked cold, a model produces what good looks like to everyone, which is average. Shown the best thinking you can find alongside real examples of the target, it stops guessing.

3. Check the examples. Fluent, on topic and about the right thing isn't the same as human and good. A machine's draft carries tells, and they're cataloged. There are em dashes at an odd rate, sentence fragments for effect, bold labels stacked in front of every point, advice in the second person with nobody behind it and significance inflation, which calls ordinary things pivotal where a plain sentence would do. Wikipedia editors keep a working list of signs of AI writing, assembled by people who have to make that call on real articles. An example that fails gets set aside with the reason named.

4. Build the rules with the model, not for it. Have it read the surviving examples and the guide, then say what it would do to produce this at that standard and what it would never do, and ask you about anything the sources disagree on. Save the result as standing instructions pointing at the surviving examples. Start them with their command and every ask for that output reads the rules first.

5. Correct by the sentence. When a result reads wrong, mark the sentence rather than asking for a rewrite. The marked sentence becomes one more rule, and the standard tightens every time you correct it. A rewrite request throws away the one piece of information the exchange produced.

Why it holds

The fix lives upstream of the prompt. A prompt tells the model what you want. Examples show it what the thing is, and a guide tells it why the good ones are good. Given only the first, a model reaches for the center of everything it has ever read. Given all three, it has a standard to hit and a way to tell when it missed.

The check on the examples holds for a plainer reason. Bad context doesn't fail loudly. The output looks right, reads smoothly and is wrong underneath, and the more fluent a machine's draft is, the more easily it passes as source material. The only defense is to look at the examples before they're used, with the tells in hand.

Find your corpus

You already have more of the material than you think, in the emails you were proud of, the report someone called sharp and the three articles you send everyone.

That pile is your corpus. The first job is to work out which parts of it a person actually wrote.

Paste the block below into your AI. It asks three questions, reads your examples and your guide, tells you which examples it set aside and why, builds the rules with you and produces one piece to the standard, so you can mark the first wrong sentence. It commits nothing, and it lists every file it wrote so you can read them before you commit.

What you get and what you don't

You get a saved standard the AI reads whenever you start it, and one piece written to it. You don't get a finished standard. The standard is only as good as the examples that survived the check, and it tightens only as fast as you mark the sentences that read wrong.

Gather two or three examples and one guide before your next ask. Check who wrote the examples.

Paste this into your AI agent or a new chat. The post above says what it does. Some prompts set something up in your project that keeps working after, and others run once, right where you paste them. None of them pushes anything to a remote.

You are building a standard for one kind of output I want more of. The goal: instead of guessing at average when I ask for this output, you hold real examples of it done well and a guide to doing it well, you have checked the examples are human and good, and you produce to that standard every time.

Before you read, list, look at or change anything, ask me these three things and wait for my answers. Your first reply is only the questions:
1. The output I want more of, named plainly: a kind of email, a report, a page, a post.
2. Two or three real examples of it done well, mine if they exist or the best in my field if not, and the best guide or article on doing it well. Files, links or pasted text.
3. Which tool I work in: Claude Code, Codex, Cursor, or the Claude chat app, and if it can read and write my files, which project folder this lives in.

If I ask what you are about to do before I answer, explain it in plain words and wait.

Then, using my answers:
- Read every example and the guide in full. For each example, judge whether a person wrote it and whether it is good, and say so: an example that a machine drafted carries tells, em dashes at an odd rate, sentence fragments for effect, bold labels stacked in front of every point, second-person advice with no person behind it, and an example like that is set aside with the reason, because a rule learned from a machine's draft produces a confident copy of a copy. If every example fails, stop and tell me; do not write rules from nothing.
- From what survives, write the rules you would follow to produce this output at that standard, and the things you would never do. Every rule comes from a surviving example, the guide or my answer; add none of your own. Where the examples and the guide disagree, ask me one question at a time and record my answer as a rule.
- If you can write my files, save any surviving example I pasted as a file beside the instructions, so every pointer leads to something. Save the rules, the never-dos, and pointers to the surviving examples as standing instructions, where my tool keeps them. In Claude Code that is a skill named after the output, at .claude/skills/<name>/SKILL.md relative to the project root, which I run by typing /<name>; open that file with a short frontmatter block giving name and a one-line description of when to use it. In Codex or Cursor, a file where I can paste it, and tell me where. In the Claude chat app, with no access to my files, hand me the text to paste into the instructions of a project that also holds the surviving examples, since you cannot edit those yourself, and hand each piece back in the conversation. Every future ask for this output reads them first.
- Run it once now, following the saved instructions by hand if the new command is not available in this session yet, and say so if you did: ask me what I want, produce it, save it to a folder named after the output if you can write my files or hand it back in the conversation if you can't, and under it list which rules it applied and which example it leaned on. Where the brief leaves out something a rule needs, ask rather than fill it in, and never take a fact for the new piece from one of the examples. If I say it reads wrong, ask me which sentence, and turn the answer into one more rule rather than rewriting from scratch.
- Do not commit anything. List every file you created or changed, so I can read them and commit them myself.
- Do not push to any remote. Do not install software. Do not rewrite the examples.

Finish by telling me how to start it: in Claude Code the command to type, in Codex or Cursor where the saved file is and what to paste with it, in the Claude chat app the words to open with, and that a sentence I mark as wrong becomes a rule, so the standard tightens every time I correct it.