The CO-STAR Prompt Framework: A Practical Guide (2026)

A practical walk-through of CO-STAR, structured so you can skim to the element you need. Sections, in order:

1. What CO-STAR is and when to use it · 2. C — Context · 3. O — Objective · 4. S — Style · 5. T — Tone · 6. A — Audience · 7. R — Response · 8. A full assembled CO-STAR prompt · 9. CO-STAR vs plain prompting (table) · 10. Common mistakes · 11. FAQs · 12. Sources & further reading.

Every element gets a copy-paste line, and the assembled example near the end shows all six working together.

CO-STAR is the framework for tone-sensitive writing. Where RTF gives you Role, Task, and Format, CO-STAR breaks the 'how it sounds' problem into three explicit dials — Style, Tone, and Audience — and adds a dedicated Context slot. That extra granularity is the whole point: it's the difference between copy that's technically correct and copy that lands with a specific reader.

Use it for customer emails, landing-page copy, social posts, support replies, executive summaries — anywhere the same facts could be written ten ways and only one is right for the moment. For a quick internal extraction or a code-format task, CO-STAR is overkill; reach for RTF instead.

The six elements map cleanly: Context and Objective replace the loose 'Task,' Style/Tone/Audience replace 'Role,' and Response replaces 'Format.' Same philosophy as RTF — supply what the model lacks — with more dials for voice.

Context is the background the model needs to answer well: what you're doing, why, and any constraints or facts it should treat as ground truth. This is the single highest-leverage slot, because most generic output comes from missing context.

``` Context: We are a 12-person B2B SaaS that just launched a free tier. Existing paid users are worried the free tier devalues what they pay for. We want to reassure them without sounding defensive. Budget for perks: none. ```

**Why it works:** grounding the model in your real situation stops it from defaulting to safe, hollow generalities. Put facts the model must respect here, and it will write around your actual constraints instead of inventing convenient ones.

Objective is the single outcome you want from this output — not the format, the goal. 'Reassure paid users and reduce churn risk from the free-tier launch' is an objective; 'write an email' is not.

``` Objective: Reassure existing paid customers that the free tier adds value for them too, and prevent any sense that they overpaid. One email. ```

**Why it works:** an explicit objective gives the model a target to optimize toward, so every sentence can be checked against it. When you review the draft, the objective doubles as your acceptance test. Keep it to one outcome; multiple objectives are a sign to split the work or chain it.

Style is the writing approach — the structural and rhetorical choices. Think journalistic, conversational, academic, punchy-and-scannable, story-led. Style is about how the prose is built; Tone (next) is about how it feels.

``` Style: Plain, direct, journalistic. Short sentences. No marketing jargon, no hedging. Lead with the point. ```

**Why it works:** naming a style anchors the model to a recognizable mode of writing instead of its default register. Reference styles ('like a Stripe changelog,' 'like a personal note') work well because the model has strong priors for them. Productize a reusable style with the Brand Voice Generator.

Tone is the emotional register: warm, confident, apologetic, celebratory, neutral, urgent. Two pieces of copy in the same style can have completely different tones, and tone is where customer-facing writing most often goes wrong.

``` Tone: Warm and confident, never defensive or apologetic. Treat paid users as valued insiders, not as a problem to manage. ```

**Why it works:** separating tone from style lets you fix one without disturbing the other — you can keep the punchy style and dial the tone from urgent to reassuring. Stating what the tone should NOT be ('never defensive') is often more effective than only stating what it should be.

Audience is who reads this, in enough detail that the model can calibrate vocabulary, assumed knowledge, and what to emphasize. 'Customers' is too broad; 'existing paid users on annual plans who chose us partly for premium positioning' is actionable.

``` Audience: Existing paid customers on annual plans. Technical enough to read a changelog. Sensitive to feeling like 'first-class' status erodes. ```

**Why it works:** the audience definition tells the model what the reader already knows (so it doesn't over-explain) and what they care about (so it leads with the right thing). Build reusable audience definitions with the Customer Persona Generator.

Response is the output specification: format, length, structure, and what to exclude. This is CO-STAR's version of RTF's Format slot.

``` Response: One email under 150 words. Subject line plus body. No bullet lists, no emojis. End with a single, low-pressure invitation to reply. ```

**Why it works:** without a Response spec the model picks a length and shape for you. Stating exact limits and exclusions makes the output paste-ready. For machine-readable output, pair this with native structured-output modes (OpenAI, Claude). Email-shaped output is also one click away in the Customer Email Templates tool.

Here are all six elements stacked into one prompt you can paste and adapt:

``` Context: We are a 12-person B2B SaaS that just launched a free tier. Existing paid users worry it devalues what they pay for. No budget for perks. Objective: Reassure paid customers the free tier adds value for them too, and prevent any sense they overpaid. One email. Style: Plain, direct, journalistic. Short sentences. No jargon. Lead with the point. Tone: Warm and confident, never defensive or apologetic. Audience: Existing paid customers on annual plans; technical; sensitive to feeling their premium status erodes. Response: One email under 150 words. Subject line plus body. No bullets, no emojis. End with a single low-pressure invitation to reply. ```

Stacked like this, each element constrains a different failure mode, and you can tune one line without rewriting the prompt. That editability is why CO-STAR is worth the extra length for repeatable, high-stakes copy.

---

You don't always need all six. If the audience is obvious from context, fold it in and drop the separate line. CO-STAR is a checklist, not a contract — use the slots that earn their place.

Use CO-STAR when: voice matters — customer emails, landing copy, social posts, support replies, exec summaries — and you need to control style, tone, and audience independently of the task.
Use RTF instead when: the task is a single mechanical deliverable (extraction, summary, code-format output) where tone is irrelevant. Don't pay the CO-STAR overhead for a job RTF handles.

CO-STAR's real payoff shows up on the second draft. Because each concern lives in its own slot, you can fix exactly what's wrong and leave the rest untouched — instead of rewriting a monolithic prompt and hoping you didn't disturb something that already worked.

Output too cold? Touch only Tone. Change 'Neutral and professional' to 'Warm and confident' and rerun. Style, audience, and the facts in Context stay fixed, so only the emotional register moves.

Output too long or wrongly shaped? Touch only Response. Tighten 'one email under 150 words' to 'under 90 words, no subject line.' Voice is unaffected.

Output over-explaining? Touch only Audience. Tell it the reader is technical and already knows the product, and the model stops defining basics. This is the same isolate-and-fix discipline that makes prompt chaining debuggable — each slot is an independent lever.

Keep a saved CO-STAR template for each recurring deliverable (launch email, support reply, changelog) and you'll mostly edit Context and Objective per use while Style, Tone, and Audience stay locked. That's how teams keep voice consistent across many people — the Brand Voice Generator does the same job for the three voice slots.

Conflating Style and Tone. Style is how the prose is built (journalistic, story-led); Tone is how it feels (warm, urgent). Keeping them separate is the framework's main advantage — don't merge them back into one vague 'make it friendly.'

Thin Context. A one-word context ('SaaS') wastes the slot. The richer the context, the less generic the output — this is where most of the quality lives.

Multiple Objectives. If your Objective line has an 'and ... and ...,' the output will be diluted. One outcome per prompt; chain the rest (see prompt chaining).

Vague Audience. 'Everyone' is not an audience. Define who reads it and what they already know, or the model over-explains to some and under-explains to others.

CO-STAR is a community framework; the techniques it bundles are documented in established sources (current as of June 2026):

DAIR.ai Prompt Engineering Guide: https://www.promptingguide.ai/

Learn Prompting: https://learnprompting.org/

OpenAI prompting guide: https://platform.openai.com/docs/guides/prompt-engineering

Claude prompt-engineering overview: https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview

Google Gemini prompting strategies: https://ai.google.dev/gemini-api/docs/prompting-strategies

Related on this site: Complete Guide to Prompt Engineering, 12 Prompt Patterns That Convert, and the simpler RTF framework.