How to Use AI for Copywriting: From Beginner to Advanced

To use AI for copywriting well, give the model four things before it writes, and keep them where it reads them every time: what you sell, who is reading, what you can claim, and how you sound. Weak AI copy is missing at least one of the four. Good AI copy is decided before the model writes a word, by material you prepare once and bring to every piece.

This guide builds that material in three levels. Level 1 is two documents you attach to a task: a voice profile made from your own writing, and a product facts file. Level 2 adds a workspace that loads them, audience research from real customer language, a one-page messaging framework, and a brief for every piece. Level 3 moves everything into one shared folder, turns the channel notes into skills the assistant opens only when needed, and writes the workflow down so a team can run it. Each level takes longer to set up, and makes each piece faster and better once it is in place.

Professional copywriting tools are built around exactly that material. Jasper keeps a Brand Voice and a Style Guide of mechanical rules. Copy.ai keeps a Brand Voice trained on your writing and an Infobase of company information you pull into a prompt. Writesonic trains a Writing Style from your files and pages. Agencies keep the same things in a shared folder. The tools differ; the assets do not.

You can stop at any level. One person with one product gets most of the value at level 2. Level 3 pays off when there are several channels, more than one product or brand, or more than one writer.

Level	You build	Setup	Per piece	Stop here if
1	A voice profile and a product facts file	2 to 3 hours	Attach both, describe the piece, edit	One product, one or two channels, you are the only writer
2	A workspace, audience research, a messaging framework, a brief template, an edit pass	Half a day, then an hour per new audience or campaign	Fill a brief, draft, run the edit pass	A few channels, one brand, one or two writers
3	One shared folder for all of it, a skill per channel, a written workflow	One to two days, then weekly upkeep	A kickoff line and a checklist	Many channels, several products or brands, a team

Level 1: a voice profile and a product facts file

What you build

Two documents. The first describes how you write, derived from your own writing rather than from adjectives. The second holds the facts about what you sell, so the model never has to guess them. Together they replace most of what you currently retype.

Build the voice profile

1. Collect samples. Gather five to eight pieces of writing that sound like the brand at its best and cover more than one format: a product page, an email you sent, a social post, a longer piece, a support reply you were happy with. Aim for two to three thousand words in total. Dedicated tools ask for the same thing; Copy.ai's guidance is three thousand words or more for an accurate voice, and Jasper builds its Brand Voice from a small set of uploaded examples. The samples matter more than anything you will write about them.

If you have no writing you would put your name to, record yourself explaining the product to one customer for three minutes, transcribe it, and clean it up. That transcript is a better starting sample than anything written while trying to sound like a company.

2. Have the model describe the voice. Paste the samples into a fresh chat and ask for a voice profile a writer could follow. It should cover sentence length and rhythm, how pieces open, how the reader is addressed, how claims and numbers are handled, what happens with humor, punctuation habits, and the words and constructions that would sound wrong. Ask it to quote a sample line for every rule it proposes. A rule without a quoted line is the model's guess.

3. Edit the profile. Delete rules you disagree with. Keep rules that caught something you did not know you did. Add the words you never use. Keep the samples in the file below the rules; they do most of the work when the model reads it later.

4. Test it. In a new chat, attach the profile and ask for a short product description, a short email, and a social post on any topic you know well. Put each next to a real sample. If a piece could not pass as yours, the fix is almost always more samples of that format or a rule with a quoted example, not more adjectives. Repeat once. The dedicated tools build this preview step in for the same reason. It is the difference between a voice that works and one that reads "about right."

VOICE PROFILE  (updated: [date])

Overview: [two or three sentences on how the brand talks, in plain words]

Rules a writer can follow (each with a line from our own writing):
- Sentences: [rule]  e.g. "[quoted sample line]"
- Openings: [rule]  e.g. "[quoted sample line]"
- Reader: [rule]  e.g. "[quoted sample line]"
- Claims and numbers: [rule]  e.g. "[quoted sample line]"
- Humor and warmth: [rule]  e.g. "[quoted sample line]"
- Punctuation and formatting: [rule]  e.g. "[quoted sample line]"

Words and constructions we never use:
[ ]

Samples (in full):
[ ]

Build the product facts file

One file per product, or one per product line if you sell many similar items. It is the equivalent of the knowledge layer in the dedicated tools, and it exists because the model will invent whatever you leave out.

1. Describe the product plainly. What it is, what it does, who buys it and why. Then the specifications a buyer would ask about: size, materials, price, delivery, where and how it is made, warranty and returns.

2. Turn features into benefits, in your customers' terms. For each feature, write what it means for the person using it. This is the line most AI drafts get wrong on their own, because the model does not know which feature matters to your buyer.

3. Record what it is not. The assumptions people make that are false. This single section prevents the most common invented claim, a feature you do not have.

4. Record proof you can use. Reviews you have written permission to quote, with source and date. Numbers you measured, with when and how. Certifications and awards. If there is none yet, write "none yet." The model will otherwise fill the space with "trusted by thousands," which is untrue and, for fabricated or generated reviews, something the FTC can fine a business for.

5. Record what you do not claim. Results you have not measured, health or financial outcomes, anything about a named competitor, superlatives with no fact behind them.

PRODUCT FACTS: [name]  (updated: [date])

What it is, what it does, who buys it:
[ ]

Specifications: [size · materials · price · delivery · made where and how · warranty and returns]

Features and what each means for the buyer:
- [feature] → [benefit in the customer's terms]
- [feature] → [benefit]

What it is not:
[ ]

Proof we can use (with permission, source, date):
[ ] or "none yet"

What we do not claim:
[ ]

6. Test it. Attach only this file and ask for a short product description. Read it against the file. Anything in the draft that is not in the file is the model filling a gap. If it is true, add the fact. If it is false, add a line under "what it is not."

How you use it per piece

Attach both files, then describe the piece in plain sentences: what it is, where it will run, who is reading it, the one thing it should get across, and what the reader should do next. Add that it must use only the facts in the product file and follow the voice profile. Long material belongs before the request, not after it. When the draft comes back, read for invented facts first and voice second.

What done looks like

The test pieces pass as yours. A product description written from the facts file contains nothing that is not in it. Corrections per draft drop from a dozen to two or three.

Where it stops

You attach the files every time, and one day you attach last month's version. The voice profile covers your general voice but not the differences between a LinkedIn post and a product page. Audience is a sentence you improvise per piece. And nothing checks the draft except you. Level 2 addresses each of those.

Level 2: a workspace, audience research, a messaging framework, and a brief

What you build

A workspace that holds your files and applies standing rules to every chat. An audience research file built from what customers actually say. A one-page messaging framework, which is the document that says what you claim and why anyone should believe it. Channel notes for each place you publish. A brief you fill in five minutes per piece. And an edit pass that catches the mistakes the model makes most.

Set up the workspace

ChatGPT and Claude both call this a Project; Gemini calls it a Gem. Each holds files and a set of instructions, and every chat started inside it uses both. (Projects in ChatGPT, Projects in Claude, Gems in Gemini.)

Put the voice profile and the product facts file in as files. Put the working rules in as instructions, and keep them short: instructions are read at the start of every chat, and a long block gets followed unevenly.

Before drafting, restate the brief in two sentences and list the facts, proof, and reader group you will use. Ask for anything missing.
Use only facts and proof from the product facts file and the messaging framework. Never add a number, a quote, a feature, or a result.
Follow the voice profile. If a rule and a sample disagree, follow the sample.
Give two versions that differ in one thing, and say what the difference is.
Show character counts for any format with a limit.

One workspace per brand. Mixing two brands in one workspace is how the wrong voice ends up in the wrong email.

Research the audience from real language

This is the step most people skip, and it is where professional copy gets its specificity. Copy that names the reader's problem in the reader's own words reads as written for them. Copy that uses your paraphrase reads as marketing. The research file is where their words live.

1. Collect the language. Your own reviews, support emails, and sales-call notes. Reviews of competing products on marketplaces and review sites, filtered to the ratings that carry the most detail. Questions people ask in forums and communities about the problem you solve. A few hundred lines is enough to start. Strip names, email addresses, and anything else that identifies a person from support emails and call notes before pasting; you need the language, not the person.

2. Have the model sort it into four lists. Each list has a specific job in your copy, and that is why these four and not others.

• Problems, in their words. What they were dealing with before they found a solution. Openings and headlines name these.
• What they hoped would change. The outcome they were after. Benefit lines come from these, in their phrasing rather than yours.
• What worried or stopped them. Doubts, bad past experiences, reasons they hesitated. These are the objections every piece has to answer.
• Phrases to reuse. Their exact vocabulary for the product, the problem, and the result, kept verbatim so it does not get smoothed into marketing language.

Ask for each list most frequent first, with the source line quoted under every item. The order shows you how often something really comes up, and the quotes let you check that nothing was invented.

3. Sort readers into three groups. Cold readers have never heard of you and need to learn one thing before anything else makes sense. Warm readers know you and have not bought; they need to see what is different and get an answer to what is holding them back. Ready readers have bought or are about to; they need the offer stated plainly and the friction removed. For each group, record what they already believe, the one thing they need to learn from you, the next step you ask for, the phrases they use, and the objections you must answer.

AUDIENCE RESEARCH  (updated: [date])

Sources: [where the language came from, with dates; names and contact details removed]

Problems, in their words (openings and headlines name these), most common first:
1. "[quote]" — [source]
2. ...

What they hoped would change (benefit lines come from these):
1. "[quote]" — [source]

What worried or stopped them (objections the copy must answer):
1. "[quote]" — [source]

Phrases to reuse, verbatim:
- "[phrase]"

READER GROUPS
Cold readers (never heard of us): what they believe · the one thing to learn · next step · their phrases · objections
Warm readers (know us, haven't bought): what still stops them · what answers it · next step · their phrases
Ready readers (bought or about to): what removes friction · next step

Write the messaging framework

You now have two documents: the product facts file, which says what is true, and the audience research file, which says what customers say. The messaging framework is the third document, and it says what you will claim. It is one page, it is its own file, and every piece of copy from here on takes its argument from it instead of inventing one.

1. The value proposition. One or two sentences: what it is, for whom, and the single most important reason it is worth choosing. Write it from the product facts and the audience research together, so it names the reader's problem and your real difference.

2. Three pillars. The three reasons the value proposition is true. For each, one sentence of benefit and one or two proof points from the product facts file. A pillar without proof is an assertion and stays out until you have the proof.

3. Objections and answers. The top objections from the research, each with the honest answer and the proof behind it, or "no answer yet" if you do not have one.

4. Which pillar leads for each reader group. Cold readers, who have never heard of you, usually get the pillar that names their problem. Warm readers, who know you and have not bought, usually get the pillar that answers their biggest objection. Ready readers, who have bought or are about to, get the offer and the pillar that removes the last doubt. Write down which, and the next step for each.

MESSAGING FRAMEWORK: [product]  (updated: [date])

Value proposition (what it is, for whom, the one reason to choose it):
[ ]

Pillar 1: [the claim]   Benefit: [what it means for the buyer]   Proof: [from the product facts file, with date]
Pillar 2: [ ]   Benefit: [ ]   Proof: [ ]
Pillar 3: [ ]   Benefit: [ ]   Proof: [ ]

Objections and answers:
- "[objection, in their words]" → [honest answer]   Proof: [ ] or "no answer yet"

Which pillar leads:
- Cold readers (never heard of us): Pillar [ ] · next step: [ ]
- Warm readers (know us, haven't bought): Pillar [ ] · next step: [ ]
- Ready readers (bought or about to): [the offer] + Pillar [ ] · next step: [ ]

Have the model draft it from the two files, then edit it hard. It is the document you will be defending, so every line needs a fact behind it. Test it in a new chat by asking the model to explain what the product is and why someone should choose it using only the framework. If the explanation is wrong, the framework is.

Write channel notes

Your voice is the same everywhere; how it shows up is not. A LinkedIn post, a launch email, and a product page do not share a structure, a length, or an opening. The brief you are about to write names the channel, so the notes for each channel have to exist first.

For each place you publish, write a short section: two or three of your own pieces that worked there, the structure you use there, the two or three rules that differ from the voice profile, and the constraint to check before publishing. Link to the platform's own guidance for lengths and limits instead of copying numbers that will be wrong in six months.

CHANNEL NOTES  (updated: [date])

LinkedIn post
- Samples that worked: [two or three, in full]
- Structure: [first line states the point · one idea · one proof point · one ask]
- Rules that differ from the voice profile: [ ]
- Check before publishing: [link to LinkedIn's current guidance on length and the "see more" cut]

Launch email
- Samples: [ ]   Structure: [subject · preview line · one promise · proof · one call to action]   Rules: [ ]   Check: [ ]

Product page
- Samples: [ ]   Structure: [ ]   Rules: [ ]   Check: [ ]

Add it to the workspace as a file. The brief names the channel, and the model reads the matching section.

Brief every piece

Agencies brief every deliverable, and the brief is where quality is decided. Yours is a template you fill in five minutes.

BRIEF: [piece]  (date)

Objective: [what this piece has to achieve, in one line]
Channel and format: [e.g. launch email · LinkedIn post · product page section]   Constraints: [length, fields, limits to check]
Reader group: [cold: never heard of us / warm: know us, haven't bought / ready: bought or about to]   What they already know: [ ]
Key message: [which pillar leads, in one sentence]
Proof to use: [from the messaging framework or the product facts file]
Call to action: [the one thing the reader should do]
Tone note: [only if this piece differs from the voice profile, and why]
Must include: [ ]   Must not include: [ ]

Paste the brief into a chat in the workspace and let the instructions do the rest: the model restates it, lists what it will use, and asks for gaps before drafting. Fix the gaps there. A wrong reader group or a missing proof point is cheap to fix in a brief and expensive to fix in a draft.

Run the edit pass

The draft is the middle of the job. Four passes, in this order, catch most of what goes wrong.

1. Variants. Two versions that differ in one thing: the opening line, or which pillar leads. Judge the difference, not the draft.

2. Tighten. Ask for a shorter version, around two-thirds the length, with nothing from the brief lost. Keep whichever reads better. It is usually the shorter one, and the cut shows you which lines were carrying nothing.

3. Claims and facts. Ask the model to compare the draft to the product facts file and the messaging framework and quote every line that states or implies something not in them. This check is the reason the files exist, and it is the pass you never skip.

4. Voice and reader. Ask it to quote any line that breaks the voice profile, any line that could describe a competitor's product unchanged, and any sentence the reader group named in the brief would not understand. Then read it yourself, as that reader, once.

Check the draft against the product facts file, the messaging framework, and the voice profile. Quote every line that states or implies a fact, number, or result not in the files. Quote every line a competitor could use unchanged. Quote every line that breaks a voice rule, and name the rule. Propose a replacement for those lines only. Change nothing else.

What done looks like

You can open the workspace, fill a brief, and have a draft that uses the right pillar, the right proof, and the reader's own words, with no invented facts, in about ten minutes. When something goes out wrong, you can point to the file that should have prevented it and fix the file.

Where it stops

Everything in the workspace loads for every task. The channel notes for LinkedIn are in context while you write a product page, and as the files grow they compete. There is no history: you cannot see what changed in the framework last month or who changed it. The routine lives in your head, so a second writer does not inherit it. Style rules, claims rules, and proof are scattered across files that nobody is responsible for. Level 3 exists for those problems.

Level 3: one shared folder, a skill per channel, and a written workflow

What changes

Nothing you built gets thrown away. Level 3 does three things to it.

First, the files move out of the workspace and into one folder that you, or a team, keep in a shared drive or in git. That gives them a home that does not depend on one tool, and a history of changes.

Second, the channel notes become one file per channel, each with a line at the top saying when to use it, so the assistant opens only the channel guide the job needs. That is what a skill is.

Third, the routine is written down, with a folder per campaign, so a second writer can run it and so what you learn from one campaign changes the next.

Setup is a day or two. Using it is one kickoff line and a checklist.

The shared folder

Think of it as five drawers and a front page. Every file you already have goes into a drawer, three new ones join them, and each drawer is opened at a different moment.

Drawer	Files	When it is opened
Front page	start-here.md: the rules for every piece, where to look by job, the terms every file uses, which file wins when two disagree	First, every time
Brand	voice-profile.md · messaging-framework.md · style-guide.md (new: how the product name is written, number and price formats, approved terms, punctuation, banned words)	Every piece
Facts	product-<name>.md, one per product · pricing-and-policies.md · proof-library.md (new: every quote and number with its source, date, and the permission you hold) · claims.md (new: what you say freely, what needs a qualifier, what you never say, who can approve an exception)	Any piece that states a fact or a proof point
Audience	research.md · groups.md	When briefing
Channels	One folder per channel, each with a SKILL.md: that channel's notes, with a line at the top saying when to use it	Only for that channel's job
Campaigns	One folder per campaign: brief.md · drafts · final.md · results.md. Plus learnings.md: what worked and what did not, dated	During and after a campaign

The three new files each fix a specific problem. The style guide separates rules that are compliance, such as how a price is written, from rules that are judgment, such as how the brand sounds. A model follows a short compliance list reliably. Mixing the two into one file makes both worse. The proof library exists so proof is copied from one place, with its permission recorded, and never from memory. The claims file exists so the person responsible for what the business may say controls one file, and so every draft is checked against it.

One folder per brand. Keep it in git if someone on the team is comfortable with it; if not, a shared drive works, with a change line at the top of each file: date, who, what. Date every file. When a campaign ends, its folder stays as a record and its brief is marked finished, so nothing treats it as current.

The front page

The front page is the file the assistant reads before anything else, every time. It does not describe the folder to a person. It routes: the rules that apply to every piece, where to look depending on the job, the terms every file uses, and which file wins when two disagree. Keep it under a page.

# [Brand] copy hub. Read this first, every time.

## Rules for every piece
- Before drafting, restate the brief and list the facts, proof, and reader group you will use, naming the file each came from. Ask for anything missing.
- Facts and proof come only from the facts drawer. Never add a number, a quote, a feature, or a result.
- Check every draft against facts/claims.md before handing it back.
- Follow brand/voice-profile.md. Where a rule and a sample disagree, follow the sample. Apply brand/style-guide.md exactly.
- Give two versions that differ in one thing. Show character counts where a format has a limit.

## Where to look, by job
- Every piece: brand/voice-profile.md and brand/style-guide.md.
- Deciding what to say and which proof to use: brand/messaging-framework.md.
- Any fact, price, policy, or proof point: facts/product-<name>.md, facts/pricing-and-policies.md, facts/proof-library.md, then facts/claims.md.
- Who is reading: audience/groups.md. For their exact words: audience/research.md.
- Writing for a particular channel or format: channels/<channel>/SKILL.md. Each one says what else to read for that job.
- A campaign in progress: campaigns/<date-name>/brief.md.
- What has worked before: campaigns/learnings.md.

## Terms used in every file
- Cold readers have never heard of us. Warm readers know us and have not bought. Ready readers have bought or are about to.
- Proof is a quote, number, award, or certification listed in facts/proof-library.md with its source, date, and permission. Nothing else counts as proof.
- A pillar is one of the three reasons in brand/messaging-framework.md that the value proposition is true. Each has its own proof.

## If files disagree, or something is missing
- facts/claims.md wins over every other file. After it: facts/proof-library.md, then the product file, then brand/messaging-framework.md, then the channel file, then brand/voice-profile.md.
- If a fact, proof point, or reader group you need is not in any file, ask. Do not fill the gap.
- The date at the top of a file is its version. If two files give different versions of the same fact, use the newer one and say which you used.

The terms block matters more than it looks. Every file in the hub uses those words, and defining them once is what lets a channel file say "warm readers" without explaining itself. The precedence list is what stops the assistant from settling a conflict between two files by guessing.

How the assistant reads the folder

The folder is the master copy. An assistant gets at it in one of two ways, and it is worth deciding which before you build the rest.

Agent tools that work on files, such as Claude Code, open the folder directly. Point them at it and tell them to read the front page first. Many of these tools also read one particular file automatically at the start of a session, and discover skills from a set folder. If yours does, follow its documentation for the file name and location, and you will not have to point it there again. Claude's skills documentation describes how that works for Claude.

Chat assistants such as Claude, ChatGPT, and Gemini reach the folder in one of two ways, depending on the app and the plan. Some can read a folder you connect, through a desktop app with file access or a cloud drive you have linked. If yours can, connect the folder and tell the assistant to read the front page first; the files it points to are read when needed. Where that is not available, the Project, custom GPT, or Gem holds copies. Paste the front page in as the instructions and upload the drawer files as knowledge. If you want a channel's guide to apply only to that channel's work, give it its own Project, custom GPT, or Gem with the channel file as the instructions. When a file in the folder changes, re-upload it. Either way, the folder is the master copy.

The channels drawer: one file per channel

Take each section of the channel notes and make it its own file, with a name and a one-line description of when to use it at the top. The description matters most: it is what a request is matched against, so write it with the words you would use when asking for that job. The body is the channel notes plus a checklist the assistant copies and ticks before handing back.

---
name: linkedin-post
description: Writes LinkedIn posts in our voice. Use when the deliverable is a LinkedIn post, a LinkedIn version of another piece, or a founder update on LinkedIn.
---

# LinkedIn post

## Read first
The front page. brand/voice-profile.md and brand/style-guide.md. The reader group named in the brief, in audience/groups.md. The product file the post draws on. Proof only from facts/proof-library.md.

## Constraints
Check LinkedIn's current guidance for length and where the "see more" cut falls. The first line has to work on its own.

## How we write here
Samples are in samples.md. Rules drawn from them:
- The first line states the idea or the result. No setup.
- One idea per post, one proof point, with its date.
- Paragraphs of one or two sentences. No bullet lists in the body.
- End with a question or one ask, not both.
- Never: "excited to announce", "game-changer", "thrilled", hashtags in the body.

## Before handing back, copy this list and tick it
- [ ] First line makes sense on its own
- [ ] Every fact and proof point comes from a hub file
- [ ] The post speaks to the reader group in the brief
- [ ] One next step, matching the brief
- [ ] Nothing from the never-say list in facts/claims.md
- [ ] Two versions, differing in the first line only

Keep the body to about a page, with the samples in a second file. Nothing that goes stale, such as a character limit, goes in the body; link to the source. Build the file for your busiest channel first, use it for a week, then write the next.

The workflow

Every campaign runs the same five steps, whether it is one email or a launch. Here it is for a launch with two pieces: an email to warm readers, who know you and have not bought, and a post for cold readers, who have never heard of you.

1. Brief. Make a folder for the campaign and write one brief in it. The brief states the objective, and for each piece: its channel, its reader group, the pillar that leads, the proof, and the call to action. For the email, the pillar that answers warm readers' biggest objection. For the post, the pillar that names cold readers' problem. Before going further, check that the audience research covers both groups; if it does not cover cold readers yet, spend the hour collecting their language now, because that is where the post's specificity will come from.

2. Draft. Start a fresh chat for the email. Give it one line naming the piece, the reader group, and what success looks like, tell it to read the front page and the launch-email file, and ask for the brief-back before any draft.

Write the launch email for [campaign], for warm readers who know us and haven't bought, so that they try [the new thing] this week.
Read the front page first, then channels/launch-email/SKILL.md, and open whatever those two point to.
Before drafting, restate the brief in two sentences, list the facts and proof you will use with the file each came from, name the reader group and the next step, and ask for anything missing.

Read the brief-back. A wrong fact or a wrong reader group gets fixed here, while there is no draft to fix.

3. Edit. The same four passes as before: two variants, tighten, the claims check, the voice and reader check. The channel file's checklist comes back ticked. Read the piece once as a warm reader, then save the final to the campaign folder. For the post, start a new chat, give it the approved email and the LinkedIn file, name cold readers as the group, and run the same passes.

4. Ship. Read the final twice, as the owner rather than the writer: once against the claims file, once for voice. Two minutes each. Then publish, and put the final versions and where they ran in the campaign folder.

5. Learn. When results arrive, write them in the campaign folder and add a line to learnings.md. An opening that keeps winning becomes that pillar's lead line in the messaging framework. An objection that keeps appearing gets an answer in the framework and a line in the audience research. A correction you have made twice becomes a rule in the channel file or the style guide. Bump the dates. This step takes ten minutes and is the difference between a system that improves and one that drifts.

Test it once before you rely on it

Take three pieces you actually produced recently. Run each with a bare request in a fresh chat and save the output. Run each again through the workflow and save that. Compare the pairs line by line: invented facts, wrong group, missing proof, voice. Where the workflow version still fails, that is the file to fix. Change the minimum, rerun in a fresh chat, and compare again. If you use more than one assistant, test on each.

Keeping it true

The folder needs a short weekly pass: mark finished campaigns, bump dates, fold in learnings. Skip it for a quarter and the files go stale. A stale claims file is worse than none, because the assistant uses it with confidence. If the weekly pass is not going to happen, stay at level 2. It works, and it is more forgiving.

Choosing a level

Count three things: the channels you publish on, the products or brands you write for, and the people who write. One of each is level 1 until you notice yourself attaching the same files every morning; then level 2 takes an afternoon. Three or more channels, or two brands, or a second writer is when level 3 starts to pay for its upkeep.

Whatever the level, three things never move into a file. Proof has to be earned, and the model must not invent it. Claims you cannot show stay out, whatever the paragraph seems to want. And the last read before something goes out is a person's. The system makes the first draft good; it does not make the last look optional.

Where to go from here

The AI Copywriting module in the Academy covers what this guide leaves out: how these models produce text, how to structure prompts for harder pieces, and how to check quality before something goes out. Open Module 2: AI Copywriting.

If you want levels 1 and 2 without maintaining files, Copy Studio keeps a saved product, its facts, and a voice, and turns them into formats. It runs on the free credits every account gets each month. Try Copy Studio.

Frequently asked questions

Which level should I start at?

Level 1, even if you expect to end up at 3. The voice profile and the product facts file are the same files at every level. You are only changing where they live, what sits beside them, and how they load.

How many samples does the voice profile need?

Five to eight pieces across more than one format, two to three thousand words in total, is enough for a profile that passes the test in step 4. If a format keeps coming out wrong, add two samples of that format before adding rules.

Do I need to research the audience if I know my customers?

Yes. What you know and what they say are different documents. The research file exists so the copy uses their phrases, not your paraphrase of them. It also ranks objections by how often they actually appear, rather than by which one worries you most.

What is a skill, and does it only work in Claude?

A skill is a channel guide saved as its own file, with a one-line description at the top saying when to use it, so the assistant opens it only when the job matches. Opening it automatically is a Claude feature. The file itself works anywhere. A custom GPT or a Gem per channel holds the same guide as its instructions; you pick the right one yourself instead of having it load on demand.

What if I have no proof yet?

Write "none yet" in the product file and leave the pillar's proof line empty in the framework. Copy built on real facts and a clear next step reads better than copy padded with credibility you do not have, and it does not create a problem you have to clean up later. Add proof to the library as you earn it.

Can I use a well-known brand's voice?

You can put a few of their sentences among your samples if you like the rhythm, labeled as borrowed. Asking for "write like [brand]" on its own produces an imitation, and it reads as one.