Context Engineering

Earlier you pasted writing examples every time. That works, but it doesn't scale. A voice profile is a written specification of how you sound, produced by having the model analyze your own writing, and then reusable forever in one paste.

The move: give it five to ten samples of your real writing, ask it to reverse-engineer the pattern, and demand specifics. Not "conversational and warm," but average sentence length, how you open, whether you use contractions, your recurring metaphors, the words you never use, how you handle bad news, whether you ask questions or make statements.

Then audit it. The first draft of the profile will contain things that aren't true about you. Cut them. What's left is an asset you'll paste into every content prompt from here on, and one you can hand to a team member so their posts sound like the same organization.

Below are samples of my real writing. Reverse-engineer my voice.

[paste 5-10 samples, separated by ---]

Produce a VOICE PROFILE that another writer could use to imitate me convincingly. Be concrete and specific. No adjectives that could describe anyone.

Cover:
- Typical sentence length and rhythm; do I vary it?
- How I open, and how I close
- Vocabulary level; contractions; slang; profanity
- Recurring images, metaphors, or reference points
- Words and constructions I never use
- How I handle disagreement, bad news, and selling
- What makes my writing recognizably mine in one sentence

Where the samples are inconsistent, say so rather than averaging them into mush.

Every major assistant now has some version of a persistent workspace: Projects, Custom GPTs, Gems, custom instructions. Different names, same idea: context that loads automatically for every conversation inside it.

This is where most of your leverage lives, and most people never set it up. A well-built project contains your voice profile, your offer details, who your audience is, your compliance rules and your standing constraints. Then every chat inside it starts where your good chats used to end.

Build one project per job, not one for everything: a content project, a customer-conversation project, a business-analysis project. Mixed-purpose projects get bloated and the instructions start fighting each other.

Set standing rules in the instructions, not per chat: "Never invent statistics. If you need a fact I haven't given you, ask. Never write income claims or health claims. Match the voice profile." Now that's true in every conversation without you remembering to say it.

Help me write the setup instructions for a persistent AI project.

Its job: [e.g. all my marketing content]

Interview me first. Ask what you'd need to know to make every future conversation in this project start well. Ask one question at a time, maximum 8 questions.

Then output a single block of PROJECT INSTRUCTIONS I can paste in, including standing rules about accuracy, voice, and what you must never do without asking me.

Keep it under 500 words. Long instructions get diluted.

The fastest way to eliminate hallucination on your own subject matter is to stop asking the model to recall and start asking it to work from documents you supply. Upload your product sheets, your FAQ, your compliance guidelines, your best case notes. Now "what should I say when someone asks about X" is a reading task, not a memory task, and reading tasks are where these tools are excellent.

Three rules keep it useful:

• Date everything. Put a "last updated" line at the top of every document. Old pricing in your knowledge base becomes confidently stated old pricing in your emails.
• One topic per file. Easier to update, easier to retire.
• Instruct it to stay inside the sources. "Answer only from the uploaded documents. If the answer isn't there, say so and tell me which document should cover it."

That last instruction converts the model's biggest weakness into a feature: it becomes a gap-finder for your own materials.

Answer only from the documents I've uploaded.

Rules:
- If the answer is fully in the sources, answer it and name which document it came from.
- If the answer is partly there, answer the part that is and clearly flag what's missing.
- If it isn't there at all, say "Not in the sources" and tell me which document should cover it.
- Never fill a gap from your general knowledge. A gap is information I need, not a problem for you to smooth over.

QUESTION: [question]

By now you have prompts that work. Most people lose them in chat history and rebuild them from memory every few weeks, slightly worse each time. Ten minutes of filing turns them into a permanent asset.

Keep it dead simple: a single document or note, one prompt per section, with three lines above each: what it's for, when to use it, and what to swap (marked with brackets). Fancy prompt-management software is a way to feel productive without being productive.

Start with the six that carry most of the load for any business: content drafting, content critique, prospect research, follow-up writing, meeting or call summary, and weekly numbers review. You'll build all six by the end of this program.

The library is also your first sellable product and your first team asset. When you teach someone later in the program, this is what you hand them on day one.

Turn the prompt we just built into a reusable library entry.

Output exactly this structure:

TITLE: [short, verb-first]
USE WHEN: [the trigger situation, one line]
SWAP: [list every bracketed variable and what goes in it]
PROMPT:
[the full prompt, with variables in BRACKETS]
WATCH FOR: [the most likely way this prompt produces bad output, and how I'd notice]

Keep the prompt itself general enough to reuse but specific enough to still work. Don't strip out the constraints. Those are the part that makes it good.

This module was the heaviest so far and none of it produced anything anyone can see. You have a voice profile, a project, a knowledge base and a prompt library: four assets, all of them plumbing. That's the point in a course where people quietly stop.

So convert the setup into a payoff before you continue. Use what you just built to make one real thing and put it in front of actual people. A post. An email to your list. A page on your site. It does not need to be your best work; it needs to exist outside your drafts folder.

Two reasons this matters more than it looks. The first is motivational: a visible result early is what carries people through the rest of the program. The second is diagnostic: publishing is the only test that tells you whether your voice profile actually works. Output that looked fine in a chat window reads differently under your own name.

Use everything in this project to produce one piece I can publish today.

WHAT I WANT TO PUBLISH: [a post / an email / a short page]
WHERE IT GOES: [platform]
WHAT I ACTUALLY WANT TO SAY: [3-5 sentences, rough, your own words]

Use my voice profile and my knowledge base. Do not invent facts, statistics, or claims I haven't given you.

Give me the finished piece. No options, no preamble, no "here's a draft." I'm publishing this in the next thirty minutes.

Then, separately, list the three places you were least sure you'd matched my voice, so I know where to look before I hit post.