The CO-STAR Framework: A Complete Guide to Structured Prompting

Most AI prompts fail for the same reason: they tell the model what to do but not how to do it, who it is for, or what good looks like. You type "write a marketing email" and get something that reads like it was written by a committee of no one in particular for an audience of everyone in general. If you have read any guide on how to write better AI prompts, you know that specificity matters -- CO-STAR gives you a repeatable structure for being specific.

The CO-STAR framework fixes this. Six components, each filling a gap that the AI would otherwise guess at. It was designed for content and communication tasks where tone, audience, and format matter as much as the information itself.

This guide covers what CO-STAR is, how each component works, real before-and-after examples, copy-paste templates, and honest guidance on when to use something else. If you are new to prompt engineering, CO-STAR is one of the best frameworks to learn first.

What Is the CO-STAR Framework?

CO-STAR is a six-component prompt structure that organizes everything an AI model needs to produce high-quality, targeted output. Each letter in the acronym maps to a specific dimension of the prompt.

CO-STAR was developed by Sheila Teo, who used it to win Singapore's GovTech GPT-4 Prompt Engineering competition. The framework gained traction because it addresses the two most common failures in AI-generated content: wrong voice and wrong audience. By making Style, Tone, and Audience explicit -- three dimensions most prompts leave entirely to chance -- CO-STAR produces output that sounds like it was written for someone specific, not just about something.

The framework is deliberately content-oriented. If you are writing marketing copy, emails, social media posts, documentation, or any text where how it reads matters as much as what it says, CO-STAR gives you the controls that matter most. For process-heavy or analytical tasks, other frameworks like RISEN or STOKE may be a better fit -- more on that later.

The Six Components, Explained

C -- Context

Context is the background the AI cannot infer from the task alone. It answers: what is the situation, what has happened so far, and what constraints exist?

What to include:

• Your company, product, or project (what you do, where you are in the market)
• Relevant history (previous campaigns, product stage, recent events)
• Business constraints (budget, timeline, competitive landscape)
• Any data or facts the output should reference

Common mistake: Providing too little context and expecting the AI to know your business. "We are a SaaS startup" is not context. "We are a B2B SaaS startup selling API monitoring to mid-market engineering teams, 18 months post-launch with 400 paying customers and a 4.6 G2 rating" is context.

Example snippet:

Context: We run a developer education platform with 12,000 active users.
Most are junior-to-mid developers learning their second programming language.
We just launched a Python course and need to promote it to our existing
JavaScript-focused user base. Conversion rate on past course launches
averaged 8%.

O -- Objective

The Objective defines what the AI should produce. Not the topic -- the specific deliverable and its intended effect.

What to include:

• The exact output you want (email, blog section, ad copy, product description)
• What the output should accomplish (drive signups, explain a concept, persuade a decision-maker)
• Success criteria if applicable (click-through rate, comprehension, action taken)

Common mistake: Confusing the topic with the objective. "Write about our new feature" is a topic. "Write an announcement email that drives existing users to try the new feature within 48 hours of launch" is an objective.

Example snippet:

Objective: Write a LinkedIn post that positions our CEO as a thought leader
on AI governance, generating engagement (comments and shares) from
VP-level and C-suite connections in the enterprise software space.

S -- Style

Style defines how the writing should read -- the structural and stylistic characteristics of the output. Think of it as the "sounds like" instruction.

What to include:

• Reference writers, brands, or publications ("like Stripe's documentation", "in the style of Paul Graham's essays")
• Structural preferences (short paragraphs, bullet points, narrative flow)
• Writing techniques (data-driven, anecdotal, technical, conversational)

Common mistake: Confusing Style with Tone. Style is how it is written (structure, vocabulary level, sentence length). Tone is how it feels (warm, authoritative, urgent). A Stripe product email and a charity fundraising letter can both use short paragraphs (same style) but feel completely different (different tone).

Example snippet:

Style: Concise and data-driven. Short paragraphs (2-3 sentences max).
Lead with specifics, not generalizations. Similar to how Intercom
writes their product blog -- technical enough to be credible, accessible
enough for non-engineers.

T -- Tone

Tone is the emotional quality of the writing. It shapes how the reader feels when they read the output.

What to include:

• Emotional register (confident, empathetic, urgent, calm, enthusiastic)
• Energy level (high energy for launches, measured for sensitive topics)
• Boundaries (what the tone should not be: "not salesy", "not condescending", "not overly casual")

Common mistake: Using a single adjective. "Professional" is the most overused and least useful tone instruction. Professional can mean cold-corporate or warm-expert or formal-academic. Be specific: "Professional but approachable -- the tone of a senior colleague explaining something, not a corporate memo."

Example snippet:

Tone: Confident but not arrogant. We know our product is good, but we
let results speak instead of making grand claims. Respectful of the
reader's time and intelligence. No hype words (revolutionary, game-changing,
cutting-edge).

A -- Audience

Audience defines who will consume the output. This single component changes more about the output than any other -- vocabulary, depth, assumptions, examples, and framing all shift based on who is reading.

What to include:

• Job title, role, or demographic
• Technical level and domain familiarity
• What they care about (their goals, pain points, decision criteria)
• What they already know (so the AI does not over-explain)

Common mistake: Skipping audience entirely and getting output aimed at a generic "everyone." If you are writing for senior engineers, say so -- the AI will stop explaining what an API is. If you are writing for C-suite executives, say so -- the AI will lead with business impact, not technical details.

Example snippet:

Audience: Marketing managers at mid-market B2B companies (50-500 employees).
They manage 2-5 campaigns simultaneously, are comfortable with analytics
dashboards but not SQL or code. They report to a VP of Marketing who
cares about pipeline contribution, not vanity metrics.

R -- Response

Response specifies the format, length, and structure of the output. It is the most concrete component and the easiest to get right.

What to include:

• Format (email, blog post, bullet list, table, JSON, markdown)
• Length constraints (word count, character limit, number of items)
• Structural requirements (include a subject line, use H2 headers, end with a CTA)
• Any platform-specific constraints (Twitter's 280 characters, LinkedIn's 3,000)

Common mistake: Not specifying format and getting a 500-word essay when you needed a 3-bullet summary. The Response component is where you prevent the AI from over-delivering or under-delivering.

Example snippet:

Response: Email format. Subject line (under 60 characters) + preview text
(under 90 characters) + body (under 200 words). Use one H2 subhead to
break the body. End with a single CTA button. No images or attachments.

CO-STAR in Action: Before and After

Task 1: Product Launch Email

Unstructured prompt:

Write an email announcing our new analytics dashboard feature.

CO-STAR version:

Context: We are a B2B project management tool with 3,000 paying teams.
Last quarter, our top feature request was better reporting. We built
a real-time analytics dashboard that shows project velocity, team
utilization, and deadline risk scores. It launches next Tuesday.

Objective: Write an announcement email that drives at least 20% of
recipients to log in and try the dashboard within the first week.

Style: Clean and benefit-driven. Short paragraphs. Lead with what
the user can do, not what we built. Similar to Linear's product emails.

Tone: Excited but controlled. We are proud of this feature but we
are not shouting. Let the capability speak for itself.

Audience: Team leads and project managers who use our tool daily.
They are non-technical but data-literate. They have been asking
for this feature -- they do not need to be convinced it matters,
they need to know it is here and how to access it.

Response: Subject line + preview text + email body under 250 words.
One primary CTA button ("Open Your Dashboard"). One secondary text
link to the help docs.

What improved: The unstructured prompt would produce a generic feature announcement. The CO-STAR version gives the AI the audience's existing awareness (they asked for this), the right tone (excited but not hype), the specific goal (drive logins, not just inform), and exact format constraints. The output will read like it was written by someone who knows the product and the users.

Task 2: Social Media Content

Unstructured prompt:

Write a LinkedIn post about remote work productivity.

CO-STAR version:

Context: I am the VP of Engineering at a 200-person remote-first
company. We have been fully remote for 4 years. Our latest internal
survey shows 91% of engineers prefer async communication over
scheduled meetings, and teams using async-first workflows shipped
23% more features last quarter.

Objective: Write a LinkedIn post that sparks discussion about async
communication as a productivity multiplier, positioning me as
someone with real data on remote work -- not just opinions.

Style: First-person, narrative. Open with a specific observation
or data point, not a generic statement. Use line breaks between
ideas (LinkedIn format). No bullet lists.

Tone: Thoughtful and opinionated. I have a clear point of view
backed by data, but I am genuinely curious about other approaches.
Not preachy.

Audience: Engineering leaders and CTOs in my network. They manage
remote or hybrid teams and are skeptical of "remote work is amazing"
content. They respond to data and specific practices, not platitudes.

Response: LinkedIn post, 150-200 words. End with a question to
drive comments. No hashtags in the body -- add 3 relevant hashtags
at the very end, separated by a line break.

What improved: The generic prompt produces forgettable LinkedIn content. The CO-STAR version grounds the post in real data (91%, 23%), targets a specific audience (skeptical engineering leaders), and defines the author's voice (opinionated but curious). The output will read like a post from someone with actual experience, not an AI writing about remote work in the abstract.

CO-STAR Templates You Can Copy

These templates are ready to use. Replace the bracketed placeholders with your specifics.

Marketing and Content

Context: [Company/product description]. [Market position or stage].
[Relevant recent event, campaign, or data point].

Objective: Write [deliverable type] that [specific measurable outcome].

Style: [Reference brand or publication]. [Structural preferences].

Tone: [2-3 adjectives with clarification]. [What the tone should NOT be].

Audience: [Job title/role] at [company type/size]. They care about
[priorities]. They are skeptical of [what to avoid].

Response: [Format]. [Length]. [Structure: headers, CTA, sections].

Technical and Developer Tasks

Context: [Technology stack or system]. [Current state: version, changes].
[Technical constraints or dependencies].

Objective: [Documentation deliverable] that enables [target user] to
[accomplish specific task] within [time frame].

Style: Code-first. [Primary language]. [Reference docs style: Stripe,
Vercel, AWS]. Minimal prose between code blocks.

Tone: Precise and neutral. No marketing language.

Audience: [Developer experience level]. They know [assumed knowledge].
Do not explain [concepts they already understand].

Response: Markdown. Sections: [list sections]. Code examples in
[languages]. [Word count limits].

Business Analysis

Context: [Company situation]. [Market conditions or internal challenge].
[Data available]. [Decision time horizon].

Objective: Produce [analysis type] that [enables specific decision].
[What question should the analysis answer].

Style: Executive summary format. Lead with conclusions, support with
evidence. [Reference: McKinsey, Bain, or internal style].

Tone: Analytical and objective. Flag uncertainty explicitly.

Audience: [Decision-maker role]. They understand [domain level]. They
need [action items vs. strategic input].

Response: [Format: memo, slide outline, report]. [Length]. Sections:
[Executive Summary, Findings, Recommendations, Next Steps].

Education and Training

Context: [Educational setting]. [Subject and learner journey stage].
[Prerequisites]. [Delivery method].

Objective: Create [lesson plan, tutorial, assessment] that [specific
learning outcome]. [Measurable success criteria].

Style: [Approach: hands-on, Socratic, project-based]. [Progressive
difficulty]. [Use of analogies and examples].

Tone: Encouraging but honest. Do not talk down or over-simplify.

Audience: [Learner profile: experience level, motivation]. They know
[prerequisites]. They struggle with [common difficulties].

Response: [Format]. [Length or duration]. [Structure: sections, exercises,
summary]. [Include: objectives, practice problems, answer key].

CO-STAR vs Other Frameworks

Different frameworks optimize for different things. Here is how CO-STAR compares to the other widely used options. For a deeper dive, see our prompt engineering frameworks compared guide.

When to pick which:

• CO-STAR -- When the output needs to sound a specific way for a specific audience. Marketing emails, social posts, client-facing documents, brand copy.
• RISEN -- When the task has a clear sequence of steps and the AI needs to follow a specific process. Code reviews, audits, multi-stage analysis.
• RACE -- When you need a structured prompt fast. Daily tasks, quick edits, situations where speed matters more than fine-tuning.
• STOKE -- When domain expertise and examples are the key differentiators. Technical writing, specialized analysis, tasks where the AI's default knowledge is insufficient.

When NOT to Use CO-STAR

CO-STAR is a content-oriented framework. It adds significant value when tone, audience, and format shape quality. But it is not the right tool for every prompting task.

Simple factual queries. "What is the capital of France?" does not benefit from six components. If the answer is a fact, just ask.

Multi-step reasoning tasks. CO-STAR has no mechanism for defining a sequence of operations. If your task involves "first analyze X, then compare Y, then recommend Z," use RISEN or add explicit steps to your prompt. Chain of thought prompting is another option for reasoning-heavy tasks.

Code generation with clear specs. "Write a Python function that takes a list of integers and returns the median" is specific enough on its own. Adding Style and Tone to a coding task adds noise without value. The Response component (format and structure) can help for complex code, but the full framework is overkill.

Brainstorming and ideation. When you want the AI to think broadly and generate unexpected ideas, too much structure constrains the output. A loose prompt with minimal constraints often produces more creative results than a fully structured CO-STAR prompt.

Tasks where Knowledge is the bottleneck. If the AI needs specialized domain knowledge to do the task well -- regulatory requirements, internal company data, technical specifications -- CO-STAR's Context field may not be enough. STOKE's dedicated Knowledge component or simply providing reference documents directly will serve you better.

Tips for Getting the Most Out of CO-STAR

Understand the Style vs Tone Distinction

This is where most people get confused, and it is the most important nuance in CO-STAR.

Style is structural: sentence length, paragraph structure, use of data, vocabulary level, reference voice. It answers "what does this writing look like on the page?"

Tone is emotional: confidence level, warmth, urgency, formality. It answers "how does this writing feel to the reader?"

A useful test: two pieces of writing can have the same Style (short paragraphs, data-driven, direct) but completely different Tones (one urgent and alarming, one calm and reassuring). If you can swap the Tone without changing the structure, you have separated them correctly.

Combine CO-STAR with Few-Shot Examples

CO-STAR does not include a built-in Examples component, which is its biggest structural gap compared to STOKE or CREATE. You can fix this by adding examples after the Response section.

Response: Blog post, 800 words, 3 sections with H2 headers.

Examples of our writing voice:
Good: "Three API calls. That is all it takes to go from raw prompt
to optimized output."
Bad: "Our revolutionary platform leverages cutting-edge AI to
transform your prompting experience!"

Two or three examples of good (and bad) output will do more for consistency than paragraphs of style instructions. For a deep dive on this technique, see our few-shot prompting guide.

Model-Specific Notes

CO-STAR works across all major models, but each responds to its components slightly differently. See our ChatGPT vs Claude vs Gemini comparison for a broader look at model differences.

GPT-4o follows CO-STAR structure faithfully and is particularly responsive to the Style component. If you reference a specific writer or brand voice, GPT-4o will make a strong effort to match it. Watch for over-indexing on the Role/Style -- it can produce outputs that feel like a caricature rather than an adaptation.

Claude excels at the Tone and Audience components. It naturally adjusts vocabulary, depth, and framing based on audience descriptions. Claude also handles nuanced tone instructions well -- "confident but not arrogant" produces genuinely different output than "confident."

Gemini benefits most from explicit Response constraints. Without specific length and format instructions, Gemini tends to be verbose. Always include word counts and structural requirements. The Style component works well when paired with concrete examples rather than abstract descriptions.

Start with Objective, Fill in the Rest

Even though Context comes first in the acronym, start by writing your Objective. Knowing what the output needs to accomplish clarifies what Context is relevant, what Style and Tone are appropriate, and who the Audience actually is. Write the O first, then fill in C, S, T, A, and R around it.

Reuse Your Components

Your Audience, Style, and Tone components rarely change between tasks for the same brand or project. Build a library of tested components you can drop into new prompts. A marketing team might have one Audience block for enterprise buyers, another for developers, and another for end users -- all reusable across dozens of CO-STAR prompts.

This is exactly what Promplify does automatically: it detects your task type and applies the right CO-STAR structure with appropriate defaults for each component, so you do not have to write the framework from scratch every time.

---

FAQ

What does CO-STAR stand for in prompt engineering?

CO-STAR stands for Context, Objective, Style, Tone, Audience, and Response. These are six components that structure your prompt so the AI has explicit guidance on background information, what to produce, how to write it, what emotional register to use, who will read it, and what format to deliver it in. Together they eliminate the guesswork that leads to generic AI output.

Who created the CO-STAR framework?

Sheila Teo developed the CO-STAR framework and used it to win Singapore's GovTech GPT-4 Prompt Engineering competition. The framework gained widespread adoption because it directly addresses the most common failures in AI-generated content: mismatched tone, wrong audience assumptions, and unspecified format. It has since become one of the most recommended prompt engineering frameworks for content-oriented tasks.

Is CO-STAR good for ChatGPT?

Yes. CO-STAR works across all major models including GPT-4o, Claude, and Gemini. The structured format helps any model produce better output because it replaces assumptions with explicit instructions. GPT-4o is particularly responsive to CO-STAR's Style component, closely following reference voices and structural preferences. The framework is model-agnostic by design -- it structures the information the AI needs, regardless of which model processes it.

What is the difference between CO-STAR and RISEN?

CO-STAR (Context, Objective, Style, Tone, Audience, Response) emphasizes audience targeting and tone control with six components. RISEN (Role, Instructions, Steps, End Goal, Narrowing) focuses on step-by-step task execution with five components. Use CO-STAR for content creation, marketing, and communication tasks where how the output sounds matters. Use RISEN for analytical tasks, technical workflows, and multi-step processes where following a specific sequence matters. For more detail, see our prompt engineering frameworks compared guide.

What is COSTAR-A?

COSTAR-A is an academic extension of the CO-STAR framework that adds an "Assessment" component as a seventh element. The Assessment section defines criteria for evaluating the quality of the AI's output -- essentially building a rubric into the prompt itself. This is useful in educational settings, research, and any context where output quality needs to be measured against specific standards rather than judged subjectively.

---

Ready to Try CO-STAR?

Promplify applies the CO-STAR framework automatically -- paste your prompt, select CO-STAR, and get an optimized version in seconds. No signup required.

Try CO-STAR in Promplify -->