AI Style Guides: How to Help AI Write Like You

A traditional style guide helps a group of people write consistently. It tells them what tone to strike, what words to use or avoid, and offers conventions for grammar, usage, mechanics, and other elements of writing style. The problem it solves is inconsistency.

An AI style guide solves the opposite problem. A model is perfectly consistent from the start—that’s why it sounds like nobody. The challenge is to push it toward the idiosyncrasies that make writing belong to a particular person. An AI style guide helps a model replicate a real writer’s judgment.

A useful guide doesn’t stop at vague descriptors like “clear,” “smart,” or “conversational.” It gets concrete. It explains the openings you favor, how your arguments tend to be structured, which sentence patterns you like and don’t like, which metaphors fit your voice, and what linguistic tendencies the model should avoid regardless of its training.

In that sense, an AI style guide is an operating manual. It takes what you know instinctively about your own writing and makes it legible for a machine to use.

A style guide is not a prompt. A prompt tells AI what to do: Draft an essay, revise a paragraph, or tighten an intro. A style guide is the reusable system underneath telling AI how to sound like you while doing it.

The most effective AI style guides are concrete and specific. At minimum, a good guide should cover voice, structure, sentence-level preferences, signature moves, anti-patterns, examples, and revision standards.

We’ve built two style guides at Every: one for Working Overtime, our column on how technology is changing work, and one for Source Code, where we share what we’ve learned about creating software products with AI. We’ll go through each section with examples from both.

Start by describing how the writing should feel at its best. You can name qualities like smart, plainspoken, skeptical, warm, dry, lyrical, or reportorial, but this section works best when it goes beyond flattering adjectives. The more useful descriptors answer questions like: How formal is the writing? How much emotional temperature does it have? And what tone feels completely wrong?

In practice:

The Working Overtime style guide describes voice with five rules that define the column’s tone:

Source Code takes a different approach, defining a spectrum of valid voices:

The Working Overtime approach works for a single-author column with a consistent voice. The Source Code approach works for a multi-author publication where different pieces call for different registers.

What often distinguishes a piece of writing is the way its ideas are organized. What makes a strong opening? How quickly does the piece get to its point? Does it move from anecdote to argument, example to concept, tension to explanation? AI infers these structural decisions poorly. So make them explicit.

In practice:

Working Overtime defines a core structural arc that every essay follows:

Source Code provides an arsenal of seven named structural templates: the Discovery Arc, the Technical Deep-Dive, the Workshop Report, the Multi-Case-Study, the Gateway Guide, the Two-Part Series, the Q&A format. Each has a step-by-step progression and a reference example from the published archive. For instance, here’s the Discovery Arc:

The Working Overtime approach fits a column with a consistent shape. The Source Code approach fits a publication that needs structural variety. Both are better than “start with a hook and end with a takeaway.”

Spell out the line-by-line habits that shape the prose: short versus long sentences, clean declaratives versus winding accumulations, punctuation preferences, rhythm, diction, tolerance for abstraction, and any recurring structural moves to follow or avoid.

In practice:

Source Code’s guide instructs the model to use concrete language, and provides it paired examples:

Working Overtime specifies that at moments of emotional significance, the writing should locate the experience in the body:

Both give the model a testable target for how sentences should sound. One focuses on concrete nouns and verbs, the other on embodied specificity. Your guide should address whatever dimensions matter most for your writing.

Name the things this voice does especially well. Maybe it starts concrete and zooms out. Maybe it uses humor to break up abstraction. Maybe it pivots from anecdote into argument or alternates bluntness with reflection.

In practice:

Working Overtime names three signature moves, each with a brief description:

Source Code names its equivalent moves at the column level—the “One Big Idea” rule (each piece must coin, claim, or crystallize one memorable concept), the “Personal Stakes as Foundation” principle, and the “Explain Like I’m Five” or “ELI5” rule (every technical term must be explained so a smart newcomer could follow). For example, here’s what the Source Code style guide says about the One Big Idea rule:

This is often the highest-value section in the whole document. Don’t just tell the model what good writing looks like. Tell it what bad writing looks like, too.

In practice:

Working Overtime maintains a “red flag” table with specific patterns and their solutions:

It also lists performance-killing patterns proven by data:

Source Code addresses skeptics directly, naming the readers’ objections and showing how the essay should handle them:

Both approaches are more useful than “avoid sounding generic.”

Examples make the guide much stronger. Show a paragraph that gets the tone right. Show a line that sounds AI-ish and explain why it fails. A rule paired with an example is almost always more useful than a rule alone.

In practice:

Working Overtime gives examples for openings, endings, and voice:

Source Code has examples organized by opening pattern (the Bold Claim, the Charged Anecdote, the Confessional, the Scene-Setting, the Manifesto Declaration), each with sample lines from published pieces. It also provides negative examples through its ELI5 section:

Include a checklist for evaluating whether a draft is working. What are signs that the prose has become too smooth, too generic, too abstract, or too pleased with itself?

In practice:

Working Overtime’s pre-publication checklist tests for the column’s values:

Source Code’s 10 principles function as their own sort of revision checklist—commandments that double as editorial standards:

The best checklist is one built from the specific ways your model-generated writing goes wrong. If your AI drafts always produce tidy summary endings, “Does the ending preserve energy?” belongs on the checklist. If they tend to bury the lede, add “Are stakes clear by paragraph one?” to the list.

The right approach depends on where you are with AI writing. Trying to build a comprehensive system in one sitting will burn you out. Starting with a vague voice description when you’re already drafting daily will leave you no better off.

You’re just beginning to use AI for writing, or you don’t have many samples of your own work yet.

At this stage, you just need to provide enough guidance to get the model out of its default voice. A starter guide has:

• Three to five bullets describing how the writing should feel (get concrete—go beyond “smart and conversational”)
• A short description of your preferred structural shape (how do your pieces open? how quickly do you get to the point?)
• A blacklist of five to 10 patterns you hate in AI-generated prose
• Two or three examples of writing you like, with a sentence or two about what you like about them

You can write this in 20 minutes, and it will meaningfully improve your next AI draft. If you don’t have strong samples of your own work, seed the guide with writing you admire—articles whose tone you want to emulate, openings you wish you had written, writers whose sentence rhythms feel right. Give the model a target, even if you’re still growing into it.

Where to put it: Keep it in its own note or document. Paste it into the chat window when you need it. Fine for this stage.

You’re drafting regularly with AI and have a growing body of work.

At this stage, you’ve noticed the model’s recurring mistakes. You know which corrections you’re making over and over. A working guide adds:

• Sentence-level preferences with positive and negative examples
• Named signature moves (what does your writing do especially well?)
• A revision checklist built from real problems you’ve encountered
• Structural templates for the kinds of writing you do most
• Expanded anti-patterns with before/after examples

Both the Working Overtime and Source Code guides are working guides. Both took months to reach their current form. We used them daily, revised them each time the model made a repeated mistake, and expanded them each time we learned something new about what counts as “good” content for those columns.

Where to put it: Store it in a Claude Project or custom GPT. The model reads the guide for context at the start of every conversation in that project or GPT, so you don’t have to manually include it.

AI is a core part of your writing workflow, and you want the system to improve with each use.

At this stage, the style guide becomes one part of a larger infrastructure. You build automated checks that scan drafts for specific patterns. You create workflows that run the guide against every piece before it ships. Each editorial correction feeds back into the guide, so that the same mistake doesn’t happen twice.

You don’t need to start here. Just know that a style guide can grow from a document you paste in a chat window into dynamic guardrails that keep your writing consistent across the full spectrum of the writing process.

Where to put it: Build it into a skill, plugin, or agent system. The guide is part of an automated pipeline—checked against every draft, enforced through workflows, and updated by a feedback loop.

Don’t sit down and write the entire guide from scratch. Instead, let the AI help build the guide for you. Ask it to interview you.

Many people are better at reacting than self-describing. You may not be able to explain your voice from a blank page, but you can answer questions like: Which of these two openings sounds more like you? What do you hate about this paragraph? Why does this sentence feel too polished? Which published piece feels most representative of your voice?

Here’s how to set up a good interview.

Give the model a small set of examples—three to five is a good starting point—that reflect the kind of writing you want. They could be published essays, favorite newsletter posts, successful intros, and strong paragraphs from past drafts—pieces that capture the range of how you write.

If you don’t have many examples of your own yet, seed it with writing you admire. You’re giving the model a target, even if you’re still growing into it yourself.

Once the examples are in place, have the AI ask you questions designed to surface your preferences about tone, structure, sentence rhythm, opening strategies, metaphors, recurring habits, things you hate in AI-generated prose, and the differences between what feels generic and what feels like you.

This works much better than simply describing your style. The interview helps you elaborate and get specific.

The most useful answers come when the conversation is attached to actual text. Ask the AI to show you sample lines, paraphrases, or summaries for you to react to. You get a chance to say things like: “This is too symmetrical,” “This sounds too corporate,” “I would never end a paragraph this neatly,” or “This phrase is too pleased with itself.”

Once the AI has enough material, ask it to synthesize the conversation into a draft guide covering voice and tone, structure, sentence-level preferences, signature moves, anti-patterns, and examples, along with a revision checklist that reminds the AI about the characteristics it should protect and avoid.

Use the guide for a week. Draft with it, revise with it, notice where you keep making the same corrections. Find out which parts are working and which are still too vague. At the end of that week, update the guide with what you’ve learned. If the model keeps making the same mistakes, sharpen the instructions. If a section noticeably improves the output, keep it.

Be more specific than feels natural

Most people’s first instinct is to describe their style in broad, flattering terms: clear, thoughtful, sharp, conversational, and smart. Those descriptions aren’t wrong, but they also aren’t specific enough to change the model’s behavior. Instead, describe actual choices: how the writing tends to open, what kinds of transitions feel dead, how much abstraction it can tolerate, what sentence moves keep showing up, and what should get cut on sight.

Name what the model should stop doing

Many people describe a lot of what they like and little of what they hate. In practice, the blacklist is one of the most useful sections in the whole guide. The Working Overtime blacklist started with three items. It now has dozens, organized by severity, each one added as a result of a specific mistake on a draft.

Use examples whenever possible

A paragraph that nails the tone, a sentence that captures the right rhythm, or an opening that demonstrates the ideal movement will teach the model more than a paragraph of abstract explanation. Negative examples matter too: Showing what misses the mark—and why—can clarify as much as showing what succeeds.

Optimize for the writing you do

It’s tempting to make the guide broad enough to cover every possible kind of writing. Usually that makes it weaker. Source Code maintains separate style guidance for engineering-heavy, practice-focused, and philosophy-driven pieces because each calls for different structural and tonal choices. A guide grounded in real tasks produces better results than one designed to cover everything.

Don’t make it too rigid

Treat the style guide like a rulebook the model must follow mechanically, and you flatten the writing in a different way. The goal is to preserve what matters while leaving room for variation and surprise. Source Code’s guide makes this explicit: “Choose the approach that serves the story.”

Don’t expect it to eliminate judgment

Even a great style guide does not remove the need for editorial judgment. A guide can improve drafts and reduce repeated correction. It cannot replace taste. The goal is to make the collaboration more fruitful—not to automate writing so thoroughly that no one has to think.

If you want to create a guide quickly, start with this template and fill it in as specifically as you can. You don’t need to get every section perfect on the first pass.

If you want to kickstart the process, you can begin with a prompt like this and adapt it to your needs:

You can customize this prompt to suit your goals. If you want help with a particular kind of writing—newsletters, essays, product writing, reported pieces—say that up front. If you want the guide to reflect an aspirational voice rather than your current one, say that too.

An AI style guide helps the model write like you. Creating one forces you to get explicit about your own taste—what you love, what you reject, what kinds of choices make the work feel like you. The guide helps the AI produce more usable drafts and better revisions. And it has another, perhaps more important benefit: It helps you better understand your own writing.