The GCSE Prompting Framework Explained

Key takeaways

• ✓GCSE stands for Goal, Context, Style, and Examples. It is a four-part prompt engineering framework that gives any AI tool enough information to return a genuinely useful first response.

• ✓Most weak AI outputs trace back to a weak prompt, not a weak model. Structuring prompts with GCSE closes that gap without requiring any technical background.

• ✓The framework works across tools, whether your team uses Microsoft Copilot, Google Gemini, ChatGPT, or Claude, so it travels with people as the technology changes.

• ✓GCSE is practical enough to teach in a half-day workshop and repeatable enough to build into a shared prompt library.

• ✓You do not need all four elements in every prompt. Understanding what each one does lets you decide which to include and which to leave out.

What is the GCSE prompting framework?

GCSE is a four-part prompt engineering framework that gives knowledge workers a repeatable structure for writing instructions to AI tools. The acronym stands for Goal, Context, Style, and Examples. Each element answers a different question the AI needs resolved before it can give you a genuinely useful response.

The framework exists because most people's first instinct when opening a chat window is to type a vague request and hope for the best. "Write me a summary of this report" is a complete sentence, but it tells the AI almost nothing about what a good summary looks like for your purposes. GCSE forces you to slow down for thirty seconds and supply the information that turns a generic output into something you can actually use.

Here is what each letter covers at a glance:

The framework does not require every element in every prompt. A quick task, asking an AI to fix the grammar in a short email, may only need G. A longer, higher-stakes piece of work, writing a tender response or a policy document, will benefit from all four. The skill is knowing which elements are load-bearing for the task in front of you.

It is also tool-agnostic. GCSE works with Microsoft Copilot, Google Gemini, ChatGPT, Claude and any other large language model your team is using. The underlying principle is the same across all of them: the quality of your output is bounded by the quality of your input.

The problem GCSE solves

Most prompt failures are not caused by a weak AI model. They happen because the person writing the prompt left out information the model needed. GCSE gives you a checklist for that missing information before you hit send.

How does each element work?

Each letter in GCSE maps to one thing a language model needs in order to produce a genuinely useful response. Skip one and the model fills the gap with assumptions, which are rarely the assumptions you would have made yourself.

G: Goal

The goal tells the model what you actually want as an output. Not a topic, not a vague direction, but a specific deliverable.

Compare these two openers:

• "Write something about our new onboarding process."

• "Write a 200-word internal announcement for our Sydney office team about the new onboarding process, ready to paste into Slack."

The second version gives the model a format (announcement), a length (200 words), an audience (Sydney office team), and a channel (Slack). Every one of those details changes the output. The goal is the most important element in the framework, so if you only have time to improve one thing about your prompts, improve this.

C: Context

Context is everything the model does not already know about your situation. That includes your role, your organisation, the audience for the output, and any constraints that should shape the response.

A policy analyst writing a brief for a state government minister needs different context than a marketing coordinator writing copy for a retail campaign, even if they are both asking for "a short summary". The model has no way to know which one you are unless you say so.

Good context is specific without being exhaustive. A sentence or two is usually enough. For example: "I work in the procurement team of a mid-sized Australian manufacturer. My audience is our CFO, who wants concise answers and dislikes jargon."

That single line will shift the tone, vocabulary, and structure of almost any output you ask for.

S: Style

Style covers how you want the response written. Tone, format, length, and level of technical detail all live here.

Some examples of useful style instructions:

• "Use plain English suitable for a non-technical executive."

• "Bullet points only, no prose paragraphs."

• "Formal tone, similar to a consulting firm deliverable."

• "Keep it under 150 words."

Without a style instruction, the model defaults to something generic and slightly formal, which is fine for a first draft but rarely exactly right for your context. Specifying style costs you five seconds and frequently saves you a full rewrite.

One thing worth knowing: style and goal overlap slightly. If your goal already specifies a format ("write a Slack message"), you do not need to repeat the format instruction in the style element. Use style to add what the goal did not cover.

E: Examples

Examples are the most underused element of the framework, and often the most powerful. Showing the model a sample of what good looks like removes almost all ambiguity about tone, length, and structure.

An example can be something you wrote previously, a piece you found elsewhere, or even a rough sketch. For instance: "Here is an email I sent last quarter that hit the right tone. Match that style: [paste email]."

Examples do more work than instructions

Telling a model "be concise and direct" is open to interpretation. Showing it a 60-word email you wrote that was concise and direct removes the ambiguity entirely. One good example is usually worth three paragraphs of style instructions.

You do not always need a full example. A short excerpt, a before-and-after pair, or even a description of what you do not want ("not like a corporate press release") all give the model useful signal. The more examples you provide, the less room there is for the model to guess.

Why does prompt structure matter?

Without a consistent approach, most people write prompts the way they write a quick message to a colleague: short, contextless, and optimistic that the other party will fill in the gaps. AI tools do not fill in gaps the way a colleague does. They fill them with assumptions, and those assumptions are often wrong.

The result is a familiar cycle. You get an output that is close but not quite right, so you tweak it and try again. A few iterations later you either accept something mediocre or abandon the task. Neither outcome is what the technology promised.

The hidden cost of unstructured prompting

Rework is not just a time cost. When people repeatedly get poor outputs, they conclude the tool is not useful for their work. That belief spreads, and adoption stalls before it starts.

Structured prompting breaks that cycle by making your intent legible to the model before it begins generating. When a prompt includes a clear goal, the right context, a specific scope, and an output format, the model has what it needs to produce something usable on the first attempt far more often.

There is also a consistency problem that matters at the team level. When everyone prompts differently, outputs vary wildly for the same task. A team of six people writing competitive summaries might get six outputs with different lengths, tones, depths of analysis, and formats. That variation creates downstream editing work and makes it harder to build shared templates or a prompt library the whole team will use.

GCSE gives a team a shared vocabulary. When someone says "did you set the scope on that?" or "what format did you ask for?", everyone knows what that means. That shared language is what turns prompting from an individual habit into a repeatable team practice.

How do you use GCSE in a real workflow?

The fastest way to see the difference GCSE makes is to compare a typical prompt against a structured one. Here is a scenario most knowledge workers will recognise.

The situation: A policy adviser needs to summarise a lengthy government consultation document for their director. The director has 10 minutes before a stakeholder meeting and needs to know the key points and any risks.

Without a framework

"Summarise this document."

The output will be a generic synopsis, probably three to five paragraphs that compress the document evenly. It will not emphasise risk. It will not account for the director's time constraint or meeting context. The adviser will spend another 10 minutes editing it into something usable.

With GCSE

Breaking the task into the four elements first:

• Goal: Produce a briefing note the director can read in under five minutes before a stakeholder meeting on the proposed amendments.

• Context: The reader is the director of the policy team. She is familiar with the policy area but has not read the full document. The meeting involves external stakeholders who may raise objections about implementation timelines.

• Source: (Paste or attach the consultation document.)

• Expectations: Bullet-point format. Lead with the two or three most contested amendments. Flag any implementation risks that stakeholders are likely to raise. No more than 400 words.

The resulting prompt looks like this:

"I need a briefing note my director can read in under five minutes before a stakeholder meeting on the proposed amendments in the attached document. She knows the policy area but hasn't read the full document. The meeting includes external stakeholders who may push back on implementation timelines. Use bullet points, lead with the two or three most contested amendments, flag likely stakeholder objections, and keep it under 400 words."

The output from that prompt is ready to forward. No editing pass required.

The time saving is in the editing, not the generating

Most teams underestimate how long they spend cleaning up AI output. A structured prompt reduces that editing pass from minutes to seconds, which is where the real productivity gain sits.

The same pattern applies across workflows: drafting board papers, writing client emails, building slide outlines, analysing customer feedback. The scenario changes, but the four elements stay constant. Once a team internalises GCSE, they stop treating every prompt as a blank-page problem and start treating it as a structured brief, which is exactly how they brief a capable colleague.

Which AI tools does GCSE work with?

GCSE works with any general-purpose AI assistant: Microsoft Copilot, Google Gemini, ChatGPT, and Claude all respond well to structured prompts. The framework is tool-agnostic because it addresses something universal, which is that AI models perform better when they have clear context, a defined goal, enough supporting detail, and an explicit format to aim for.

That said, a few practical differences are worth knowing.

Context window size varies between tools and subscription tiers. A context window is simply how much text a model can hold in a single conversation. Claude and GPT-4o currently handle very long prompts comfortably, which means you can paste in a lengthy document as context without truncation. The free tiers of some tools have shorter limits, so a heavily detailed GCSE prompt with a large pasted document may need trimming if you are on a basic plan.

System prompts work slightly differently across platforms. In ChatGPT, custom instructions or a custom GPT let you bake the Goal and Style elements in once, so individual prompts only need Context and Examples. Copilot in Microsoft 365 operates inside specific apps (Word, Teams, Outlook) where the application itself provides some context automatically, meaning your prompts can often be shorter. Gemini in Workspace behaves similarly. Claude's Projects feature lets you store persistent instructions that carry across conversations.

None of these differences break the framework. They just mean experienced users adapt the weight they give each element depending on the tool and the task.

One framework, every tool

GCSE is not a ChatGPT trick or a Copilot shortcut. It is a thinking structure. Once your team understands it, they carry it across every tool they use today and every tool they will use in two years.

If your team uses multiple AI platforms, that is actually an argument for standardising on a shared prompting framework rather than learning tool-specific workarounds. Consistency in how people think about prompts reduces the retraining cost every time a new tool is introduced. The why prompting is a team skill, not an individual one article explores this point in more detail.

Frequently asked questions

What does GCSE stand for in prompting?

GCSE stands for Goal, Context, Style, and Examples. It is a prompt engineering framework that gives knowledge workers a repeatable four-part structure for writing AI prompts that return useful, on-target responses. Each letter represents one ingredient: what you want the AI to produce, the background it needs to work from, how you want the answer delivered, and a sample that shows what good looks like.

Is GCSE a formal standard or something Better People developed?

GCSE is a practical teaching framework used in Better People's AI fluency workshops, designed to be memorable and immediately applicable for non-technical teams. It is not an industry-wide standard or a vendor specification. Many prompting frameworks exist under different names, and they tend to share the same underlying logic: giving the model a clear goal, sufficient context, and a concrete reference point. GCSE packages that logic in a form that sticks after a half-day workshop.

Do I need to include all four elements every time?

No. Goal is the only non-negotiable element. A prompt with no clear goal rarely produces a useful result, regardless of how much context you add. Context and Style are high-value additions for most professional tasks. Examples are most useful when the format or tone matters and is hard to describe in words. For a quick factual lookup, a one-line prompt is often enough. The framework's value is in knowing which elements to reach for when a response is not quite right.

Does GCSE work with Microsoft Copilot and Google Gemini, or just ChatGPT?

GCSE works across all major AI tools, including Microsoft Copilot, Google Gemini, Claude, and ChatGPT. The underlying models differ, but they all respond to the same inputs: a clear goal, relevant context, a preferred style, and illustrative examples. Where the tools vary is in how they access context. Copilot can pull context from your Microsoft 365 documents directly, which means your C element is sometimes implicit rather than written out. The framework adapts to that; the thinking stays the same.

How long does it take a team to get comfortable with GCSE?

Most teams can write structurally sound prompts within a single half-day workshop, given enough guided practice on tasks they actually do. The first few applications after training are the critical window. Teams that build a shared prompt library and treat prompting as a team skill rather than an individual habit tend to embed the framework more durably than those who leave it to individual effort.

Want your team writing better prompts from day one?

GCSE is a straightforward framework, but knowing the theory and applying it under the pressure of a real workday are two different things. Most teams need a few hours of guided practice before the habit sticks.

Better People's AI workshops are built around exactly this kind of practical repetition. Participants work through real prompts drawn from their own roles, get immediate feedback, and leave with a shared vocabulary they can carry back into their teams. That last part matters: as we cover in why prompting is a team skill, not an individual one, consistency across a team produces better results than one highly skilled individual working in isolation.

Ready to get your team prompting well?

We'll walk you through workshop formats, delivery options, and which approach suits your team's size and AI tool stack. Most teams leave with a prompt library they can use immediately.

Explore AI workshops →