TL;DR: CO-STAR stands for Context, Objective, Style, Tone, Audience, Response. It comes from GovTech Singapore's Data Science and AI Division, published in their Prompt Engineering Playbook in August 2023, and was popularised by Sheila Teo's December 2023 competition write-up. It is strongest for content work and weakest for reasoning.
What is the CO-STAR framework?
The CO-STAR framework is a six-slot template for structuring a prompt: Context, Objective, Style, Tone, Audience, Response. You write each slot as a labelled section, the model reads all six, and the output arrives already shaped for the person who has to read it.
It turns up on more prompt-framework lists than any other structure we have seen, and it earned that reach honestly. Most frameworks give you one slot for the output and leave everything else to inference. CO-STAR gives you three: Style, Tone and Audience are separate decisions, made separately, and that separation is the entire reason the framework produces copy that does not read like generic AI filler.
It is also the framework whose origin is most frequently misreported, which is where this page starts.
Who actually created the CO-STAR framework?
GovTech Singapore's Data Science and AI Division created it. Not an individual, and not as a byproduct of a competition win.
The primary artefact is GovTech's own Prompt Engineering Playbook (Beta v3), a 134-page public PDF whose cover page reads "Last updated 30 Aug 2023" and "Produced By GovTech Data Science & AI Division". Pages 26 to 40 are a section headed "The CO-STAR approach to writing your prompts", with a page per letter and a closing page titled "Mix and Match Your CO-STAR" (Singapore Government Developer Portal, PDF, accessed 27 August 2026).
The framework reached a global audience through a second source. In December 2023, data scientist Sheila Teo published "How I Won Singapore's GPT-4 Prompt Engineering Competition" on Towards Data Science, describing "Singapore's first ever GPT-4 Prompt Engineering competition, which brought together over 400 prompt-ly brilliant participants, organised by the Government Technology Agency of Singapore (GovTech)". Her first technique is CO-STAR, and she introduces it in her own words as "a brainchild of GovTech Singapore's Data Science & AI team" (Towards Data Science, 29 December 2023, accessed 27 August 2026).
GovTech has since restated the same attribution on its own site: "At GovTech, our officers follow the CO-STAR Framework, featured in our Prompt Engineering Playbook, to craft better prompts" (tech.gov.sg TechNews, 3 April 2025, accessed 27 August 2026). The same page notes that GovTech's prompt engineering award, Prompt Royale, was "first introduced in 2023".
There is one more piece of provenance worth knowing, because it explains the odd name. The playbook's closing line on the section is: "Remember that the AI is merely your co-star, and you are still the star of the show!" The hyphen is a pun, not a typo. AWS and others render the acronym as COSTAR with identical definitions and no attribution (AWS Machine Learning Blog, accessed 27 August 2026). Same framework, flattened name.
What does each letter mean, as originally defined?
Both primary sources agree on five of the six letters and diverge on one. Here is each letter with the original wording, and the divergence flagged where it exists.
| Letter | GovTech playbook, Aug 2023 | Sheila Teo, Dec 2023 |
|---|---|---|
| C Context | "Provide the necessary background information that will help the AI understand the topic you want to discuss." | "Provide background information on the task" |
| O Objective | "Clearly state your goal or objective that you want the AI to perform." | "Define what the task is that you want the LLM to perform" |
| S Style | Mimic a person's style of writing or speaking, or "a particular expert in a profession (e.g. a career coach)" | "Specify the writing style you want the LLM to use" |
| T Tone | "Do you want the response to be casual? Professional? Or humorous?" | "Set the attitude of the response" |
| A Audience | "Are you writing to a general audience or a specific group of people?" | "Identify who the response is intended for" |
| R Response | Headed "R – Response (Length & Format)", and mostly about length | "Provide the response format" |
That last row is a real contradiction between two primary sources, not a paraphrase drift. GovTech's section header explicitly names length as part of R and opens with "Do you want a short answer or a detailed explanation?" Teo's definition covers format only: "Provide the response format", with a list or JSON as the examples. GovTech's own 2025 TechNews summary sides with Teo on the definition ("Define the format of the response") and then contradicts itself in the worked example, which specifies "about 350 words long, broken up into paragraphs of 100 words each".
The practical resolution is to fill both. Models drift on length more often than they drift on format, so a Response slot that names only the format is leaving the more common failure unaddressed. If you want the longer version of that argument, we wrote it up separately in how to decide what output format you actually need.
What does a CO-STAR prompt actually look like?
Six labelled sections in capitals, in order, one per line or one per paragraph. That is the whole syntax. The original article uses this exact shape:
CONTEXT
I want to advertise my company's new product. My company's name is Alpha
and the product is called Beta, which is a new ultra-fast hairdryer.
OBJECTIVE
Create a Facebook post for me, which aims to get people to click on the
product link to purchase it.
STYLE
Follow the writing style of successful companies that advertise similar
products, such as Dyson.
TONE
Persuasive
AUDIENCE
My company's audience profile on Facebook is typically the older generation.
Tailor your post to target what this audience typically looks out for in
hair products.
RESPONSE
The Facebook post, kept concise yet impactful.
That example is reproduced from Sheila Teo's article, where it is the demonstration case. Note how little of it is about the product and how much is about the reader. Three of the six sections describe the person receiving the output rather than the task itself, which is the structural insight the framework is actually built on.
Why does CO-STAR work so well on content?
Because content failures are almost never comprehension failures. The model understood you. It just wrote for nobody in particular.
Ask a model to "write a Facebook post about our new hairdryer" and you get something competent and unusable, because the model has no idea whether it is writing for a nineteen-year-old on TikTok or a sixty-year-old comparing warranties. It picks a default, and the default is the flat mid-Atlantic marketing voice that everyone now recognises on sight. Style, Tone and Audience are three separate levers against that default, and they fail in different ways, which is precisely why collapsing them into one instruction does not work.
Style is craft: sentence rhythm, vocabulary, structural habits. Tone is attitude: warm, blunt, apologetic, deadpan. Audience is knowledge state: what they already know, what they care about, what will make them stop reading. You can write in a plain style with a hostile tone for an expert audience. Those are three independent axes, and CO-STAR is the only common framework that gives each one its own line.
That is also why CO-STAR is the framework worth reaching for when the same prompt gets reused across a team. The Audience slot is where institutional knowledge lives, and it is the slot that a new hire cannot guess. Once the six sections are written down, the prompt stops being one person's habit and becomes something a team can edit. We covered the general version of that argument in how to write better ChatGPT prompts.
Where does CO-STAR underperform?
On anything where being correct matters more than reading well. This is the part the aggregator posts leave out, and it is not a small caveat.
Reasoning and analysis. CO-STAR has no slot for how to think. Four of its six sections govern presentation. If the task is "work out why our churn spiked in March", the framework will faithfully deliver a beautifully toned, audience-appropriate wrong answer. What you needed was an instruction to work through the steps and show them, which is a different technique entirely. See chain-of-thought prompting for the tool that does fit.
Code and debugging. There is no slot for constraints, no slot for the stack, no slot for what must not change. Style and Tone are close to meaningless when the output is a patch. You can bolt Context onto the framework and stuff everything in there, but at that point the framework is not doing the work, the Context section is.
Anything needing examples. CO-STAR has no few-shot slot. When output shape is hard to describe but easy to demonstrate, two examples beat six paragraphs of description, and the framework gives you nowhere to put them without inventing a seventh section.
Edge cases and refusals. There is no slot for "if you do not have enough information, ask" or "if the data does not support a conclusion, say so". That gap is exactly what AUTOMAT fills with its atypical-cases and topic-allowlisting slots, and it is the main reason AUTOMAT survives production use better than CO-STAR does.
Structured and machine-read output. Response can say "return JSON", but it cannot carry a schema, field types, or validation rules. If a downstream system parses the output, you want a JSON prompt with an explicit schema, not a prose sentence describing one.
Non-text generation. CO-STAR is a text framework. Video and image models want camera, lens, motion and subject slots, which have no CO-STAR equivalent at all. Our Kling AI prompt format guide covers a six-part framework built for that job instead. Reaching for CO-STAR there is a category error.
How does CO-STAR compare with the other frameworks?
By slot count and by what each slot buys you. All three of these are worth knowing, and they do not compete for the same tasks.
| Feature | CO-STAR | RTF | AUTOMAT |
|---|---|---|---|
| Slots to fill | 6 | 3 | 7 |
| Dedicated tone slot | Mode/tone | ||
| Dedicated audience slot | User persona | ||
| Dedicated output-format slot | |||
| Explicit role or persona slot | |||
| Slot for worked examples | |||
| Slot for edge cases or refusals | |||
| Slot for reasoning steps | |||
| Rough time to write from scratch | 2 to 4 minutes | Under a minute | 5 to 10 minutes |
| Best fit | Audience-facing copy | Quick one-off asks | Reusable production prompts |
RTF is the one to use when CO-STAR would be overkill, which is most of the time on throwaway asks. AUTOMAT is the one to graduate to when a prompt is going into production and someone else will run it. Our roundup of seven prompt frameworks covers the rest, including CRAFT and CARE, and makes the same argument this page makes: you need two or three, not seven.
One structural quirk worth naming. CO-STAR has no Role slot. Style can carry a persona, and both primary sources give persona examples under S, but it is a writing-style instruction rather than an expertise instruction. If you want the model to reason from a professional's knowledge rather than write in their voice, CO-STAR is not where that goes.
14 copy-paste CO-STAR prompts
Every one below has all six sections filled with something specific. Replace the bracketed placeholders and delete any slot that genuinely does not apply, per the playbook's own mix-and-match rule.
Marketing and launch
CONTEXT
We are a bootstrapped B2B SaaS with 40 paying teams. We are launching a
shared-workspace feature that our three largest customers asked for by name.
No funding announcement, no big numbers to quote.
OBJECTIVE
Write a launch announcement email that gets existing paying customers to
turn the feature on in their workspace this week.
STYLE
Plain product writing. Short paragraphs, no adjectives before nouns unless
they carry information, no bullet lists of benefits.
TONE
Matter-of-fact and slightly understated. We are not excited, we are useful.
AUDIENCE
Existing paying admins who already like the product and have limited time.
They do not need to be sold on us, only on why this is worth ten minutes.
RESPONSE
Subject line under 45 characters, then 120 to 160 words of body, then one
call to action as a single sentence. Plain text, no markdown.
CONTEXT
We published a case study where a 12-person agency cut their reporting
time from 6 hours a week to 40 minutes using our templates. The client
has approved being named.
OBJECTIVE
Turn the case study into a LinkedIn post that gets agency owners to click
through to the full write-up.
STYLE
First person, founder voice. One concrete number in the first two lines.
No hooks that promise a thread, no rhetorical questions as openers.
TONE
Direct, curious, not triumphant. Credit the client, not the tool.
AUDIENCE
Agency owners and operations leads between 5 and 30 staff who are sceptical
of AI case studies because they have read forty fake ones.
RESPONSE
Between 120 and 180 words, single-line paragraphs, one link at the end,
no hashtags, no emoji.
CONTEXT
We run a paid newsletter about supply chain logistics. Renewal season is
in three weeks and last year 22% of annual subscribers lapsed silently.
OBJECTIVE
Write a renewal reminder email that gets lapsing subscribers to renew
before their access ends, without discounting.
STYLE
The style of a trade publication editor writing to a colleague, not a
marketer writing to a list.
TONE
Respectful and unbothered. Assume they may reasonably choose to leave.
AUDIENCE
Working logistics managers who subscribed with company money and need one
defensible line to justify the renewal to a finance approver.
RESPONSE
Subject line, 150 words maximum, including one sentence they could paste
directly into an expense justification. Plain text.
CONTEXT
We are writing hero copy for a landing page selling a physiotherapy booking
tool to single-practitioner clinics. The competing pages all lead with
"streamline your practice".
OBJECTIVE
Produce three distinct hero section options, each with a headline and a
one-sentence subhead, that lead with a specific problem rather than a
category claim.
STYLE
Concrete nouns, no abstractions. Each headline must name a thing that
happens in a real clinic day.
TONE
Calm and specific. No urgency, no exclamation marks.
AUDIENCE
Solo physiotherapists who run their own admin, are not shopping for
software, and land on this page from a Google search about no-shows.
RESPONSE
Three numbered options. Each: headline under 60 characters, subhead under
120 characters. Then one line per option explaining the angle it takes.
Customer-facing and support
CONTEXT
A customer on our annual plan has asked for a refund four months in,
citing a feature that was on our roadmap page and has slipped. Our
published refund window is 7 days. They are polite but firm.
OBJECTIVE
Draft a reply that declines the full refund, offers a pro-rated credit
toward a monthly plan, and keeps the relationship intact.
STYLE
Support writing, not legal writing. Name the policy once, then move to
what we can actually do.
TONE
Accountable without grovelling. Do not apologise more than twice.
AUDIENCE
A reasonable customer who has a legitimate grievance and will screenshot
this reply if it is bad.
RESPONSE
Email body only, 120 to 180 words, no subject line, no bullet points,
ending with a specific next step rather than an open question.
CONTEXT
Our onboarding docs assume users have already connected their calendar.
Support gets roughly 15 tickets a week from users stuck before that step.
OBJECTIVE
Write a docs page section that gets a first-time user from a fresh account
to a connected calendar without needing support.
STYLE
Numbered procedure. One action per step. Every step names what the user
should see afterwards.
TONE
Neutral and literal. No encouragement, no "simply" or "just".
AUDIENCE
Non-technical first-time users who have not read anything else on the site
and may be on a work laptop with restricted permissions.
RESPONSE
A short intro of two sentences, then numbered steps, then a three-item
troubleshooting list covering the most common blockers.
CONTEXT
We are recording a weekly 40-minute interview podcast about independent
software businesses. This episode covers a founder who shut down a
profitable product deliberately.
OBJECTIVE
Write the episode description and chapter timestamps that make someone
scrolling a podcast app stop and press play.
STYLE
Editorial, in the register of a good radio listing. No teaser questions
that the episode does not answer.
TONE
Curious and slightly contrarian.
AUDIENCE
Indie founders and solo operators who have heard a hundred growth episodes
and are tired of them.
RESPONSE
A 60-word description, then 6 to 8 timestamped chapter titles, each under
50 characters. Return the timestamps as a plain list.
Internal and operational
CONTEXT
We are hiring our first customer support person. We are a five-person
remote team across three time zones, bootstrapped, no HR function. The
last two hiring rounds failed because applicants expected a bigger company.
OBJECTIVE
Write a job description that attracts people who want a small-company job
and deters people who do not.
STYLE
Honest job-post writing. State the constraints in the first third, not
buried under perks.
TONE
Plain and unromantic. No mission language, no "rockstar".
AUDIENCE
Experienced support people currently at larger companies who are choosing
between us and a safer, bigger option.
RESPONSE
Sections: what the job is, what the first 90 days look like, what is hard
about it, what we pay and how, how to apply. Under 450 words total.
CONTEXT
Monthly investor update for 14 angel investors. This month revenue grew
6%, but our largest customer gave notice and churn will hit next month.
We have 19 months of runway.
OBJECTIVE
Write the update, leading with the churn rather than the growth.
STYLE
Numbers first, narrative second. Every claim followed by the figure that
supports it.
TONE
Frank. No spin, no silver linings appended to bad news.
AUDIENCE
Angel investors who have seen many updates, will notice an omission
faster than a bad number, and can help with intros if asked directly.
RESPONSE
Under 400 words. Sections: headline metrics, what went wrong, what we are
doing about it, one specific ask. No charts, no attachments.
CONTEXT
We are changing our remote work policy from fully flexible to two fixed
overlap hours per day. The team was not consulted before the decision.
OBJECTIVE
Write the internal announcement that explains the change, the reasoning,
and what is not changing.
STYLE
Internal comms, not corporate comms. Name the decision-maker.
TONE
Direct and non-defensive. Acknowledge the lack of consultation once,
without dwelling on it.
AUDIENCE
An 11-person team, several of whom took the job partly for the flexibility
and will read this as a step toward a return-to-office policy.
RESPONSE
Under 300 words. Open with the change itself in the first sentence. End
with how and when people can push back.
CONTEXT
We ran a discovery call with a 60-seat logistics company. They named three
pain points, have an incumbent tool with two years left on contract, and
their champion is an operations lead without budget authority.
OBJECTIVE
Write the follow-up email that keeps the deal alive and equips the
champion to make the case internally.
STYLE
Business writing with no sales register. Summarise their words back to
them before introducing ours.
TONE
Useful and unhurried. No urgency, no artificial deadline.
AUDIENCE
An operations lead who liked the call, has no budget, and needs something
forwardable to a finance director who was not on the call.
RESPONSE
Under 200 words, with a clearly separable three-bullet block the champion
can forward without editing. Plain text.
Technical and long-form
CONTEXT
We shipped a release with three user-visible changes, one deprecation with
a six-month window, and a security fix we are not describing in detail.
Our changelog is read mostly by non-developers.
OBJECTIVE
Write release notes that tell a non-technical admin what changed and what
they need to do about it.
STYLE
Changelog register. Each entry leads with the user-visible effect, not the
component name.
TONE
Neutral. Do not celebrate the fixes or apologise for the deprecation.
AUDIENCE
Workspace admins who are not developers, skim changelogs, and mainly want
to know whether anything will break for their team.
RESPONSE
Three sections: Changed, Deprecated, Fixed. Each item one sentence, with
an action line only where the reader has to do something.
CONTEXT
Submitting to a practitioner conference on data engineering. The CFP wants
a 200-word abstract, rejects vendor pitches, and the talk is about a
migration we did badly the first time.
OBJECTIVE
Write a conference talk abstract that gets accepted by a reviewer reading
two hundred submissions.
STYLE
Technical talk abstract. State what the audience will be able to do
afterwards, in specific terms.
TONE
Confident about the lesson, honest about the failure.
AUDIENCE
Programme committee reviewers who are practitioners themselves and reject
anything that reads like marketing.
RESPONSE
Title under 70 characters, abstract of 180 to 200 words, then three
bulleted takeaways of one line each.
CONTEXT
We are applying for a small arts grant. The funder cares about community
reach, has a 150-word summary field, and explicitly asks applicants to
avoid jargon.
OBJECTIVE
Write the summary paragraph that opens the application.
STYLE
Clear civic writing. No sector jargon, no words like "impactful" or
"leverage".
TONE
Warm but concrete. Every claim tied to a number or a named partner.
AUDIENCE
A grant assessor reading sixty applications, non-specialist, scoring
against published criteria of reach, need and feasibility.
RESPONSE
Exactly one paragraph, 140 to 150 words, structured as who we are, what we
will do, who it reaches, and what the grant specifically pays for.
CONTEXT
Monthly churn rose from 3.1% to 5.4% in March. We shipped a pricing change
on 2 March and a mobile redesign on 18 March. Data attached as CSV.
OBJECTIVE
Identify the most likely cause of the churn increase and state your
confidence in it.
STYLE
Analytical memo. Claims, then evidence, in that order.
TONE
Sceptical. Argue against your own conclusion once before settling.
AUDIENCE
A founder who will act on this and does not want to be told what they
already suspect.
RESPONSE
Under 400 words: conclusion, evidence, confidence level, what would
change your mind.
METHOD
Work through this step by step before answering. List every hypothesis
the data could support, then eliminate.
IF UNSURE
If the data cannot distinguish between two causes, say so explicitly and
name the query that would.
How do you know a CO-STAR prompt is working?
Change one section and see whether the output changes. If it does not, that section is doing nothing and you can delete it.
That test sounds trivial and almost nobody runs it. A large share of CO-STAR prompts in circulation have a Tone section reading "professional" and a Style section reading "clear and concise", neither of which constrains anything, because both describe the default the model was already producing. A slot that does not change the output is not a slot, it is decoration, and decoration is what makes a six-section prompt feel more rigorous than it is.
Three specific checks worth running before you save a prompt for reuse:
Swap the Audience and reread. Change "solo physiotherapists" to "hospital procurement managers". If the output barely moves, your Audience section is being ignored, usually because the rest of the prompt already pins the vocabulary too tightly.
Read the Response section back as a spec. If you cannot tell whether an output complies, the model cannot either. "Concise" is not a spec. "120 to 160 words, no bullet lists" is.
Ask whether Style and Tone are saying the same thing. They collapse constantly. Style is craft, Tone is attitude. If both slots contain adjectives from the same family, merge them and keep the framework at five sections.
That process is the whole difference between a prompt you wrote once and a prompt you can hand to someone else. Prompt Architects exists for the second kind: a library where a prompt lives with its variables filled in, reachable from the web app, the browser extension, or an MCP server at https://mcp.prompt-architects.com/mcp that Claude Desktop, Claude Code, Cursor and Codex can all read. Every plan including the free one runs on built-in AI, so there is no API key to supply, and the published free tier is 5 prompt enhancements per day per our FAQ page.
What that does not do is write your CO-STAR sections for you. Nothing does. The Audience section is the one containing knowledge that only you have, and no tool can guess who reads your emails. What a library gets you is that once you have written that section well, you never write it again.
CO-STAR earns its reputation on exactly one axis, and it is a genuinely valuable one: it forces you to describe the reader before you describe the task. For prose that someone has to want to read, that is most of the job. For everything else, use it as a starting shape and be honest when the task needs slots CO-STAR does not have.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An Account