The TAG Prompt Framework

TL;DR: The TAG prompt framework is three lines — Task, Action, Goal — built for a fast, single-shot request, not production work. Task names what you're working with, Action states the instruction, Goal defines what success looks like. No inventor is credited anywhere we could verify; the earliest dated public use we found is a February 2024 blog post. It's genuinely useful for quick asks and genuinely too thin the moment output format or a persona starts to matter.

What Is the TAG Prompt Framework?

TAG is a three-part prompt structure: Task, Action, Goal. You name what you're working with, state the instruction, and describe the outcome that would count as a win.

Task: [what you're working with — the subject or situation]
Action: [the specific instruction — what you want done]
Goal: [what a successful result looks like]

That's the entire framework. No role, no format, no context field, no room for an example. Where RTF closes with a format instruction and CO-STAR spends three of its six fields on tone, audience, and style, TAG spends its third field on the one thing those frameworks leave to inference: what "good" means for this particular ask.

It reads almost too simple to matter, and for a lot of requests it is too simple. But the third field is doing more work than it looks like on the page, and the fastest way to see that is to watch it change an output while nothing else in the prompt moves.

Where Did TAG Actually Come From?

We could not find a credited inventor, and we looked. There is no GitHub commit like CRISPE's, no government playbook like CO-STAR's, no LinkedIn Pulse listicle with a named author and a date, the way a sibling three-letter framework in this cluster traces to one. The earliest dated public use of this exact Task-Action-Goal expansion we could fetch and confirm is a blog post published 23 February 2024, on a personal AI-tools site with a single named author. It defines the three fields the same way every later source does and names no earlier origin for the acronym.

Since then, at least three independent sources have published the identical breakdown with no meaningful disagreement on what the letters stand for: a prompt-framework reference tool (undated, current as of this writing), a knowledge-base article from a prompting SaaS product, and a dated blog entry from January 2025 in an unrelated "AI Quick Tips" series. All four sources — spanning a personal blog, a reference tool, a product knowledge base, and a consultancy's newsletter — describe Task, Action, and Goal in the same order with the same meaning. That kind of quiet convergence, with no single source claiming credit, is itself informative: it reads like a mnemonic that spread hand-to-hand through practitioner content rather than one that was coined once and cited forward.

How Do You Build a TAG Prompt, Field by Field?

Start from a bare request and add one field at a time. The interesting part isn't Task or Action, which mostly restate what a decent one-line prompt already says. It's watching Goal change the output while Task and Action stay almost fixed.

Weak, no framework at all:

Give me name ideas for my app.

Technically a working prompt. You'll get five plausible names, none of them wrong, none of them obviously right for anything in particular.

+ Task, made specific:

Task: I'm naming a budgeting app for freelancers who worry about missing tax deadlines.

+ Action, stated as an instruction:

Task: I'm naming a budgeting app for freelancers who worry about missing tax deadlines.
Action: Suggest 5 one-word or two-word name candidates.

Already more useful than the weak version, mostly because Task supplies context the bare request never stated. But every name candidate the model produces at this point is still a guess at tone, because nothing has told it what "good" means yet.

+ Goal, version one — trustworthy:

Task: I'm naming a budgeting app for freelancers who worry about missing tax deadlines.
Action: Suggest 5 one-word or two-word name candidates.
Goal: Names should sound trustworthy and calm to someone anxious about a deadline, not playful.

+ Goal, version two — same Task, same Action, different Goal:

Task: I'm naming a budgeting app for freelancers who worry about missing tax deadlines.
Action: Suggest 5 one-word or two-word name candidates.
Goal: Names should feel fun and shareable, the kind of name someone screenshots for a TikTok.

Same subject, same instruction, one word of Goal changed. Version one steers toward names that sound like "Ledger," "Steady," "Anchor" — calm, reassuring, financial-sounding words. Version two steers toward something punchier and more brandable, closer to what you'd see on an app store trending list. Nothing about the Task or the Action changed. Goal did all of that work by itself, which is the actual proof this three-field structure isn't just three restatements of the same idea.

When Does TAG Actually Work?

Best for the situations it was built for: fast, low-stakes, single-shot requests where you're the only reader and you don't need a particular shape back.

• A first-pass brainstorm you'll edit down yourself
• A quick explanation of a concept you half-remember
• Naming, tagline, or headline options before you've committed to a direction
• A rough draft you're going to rewrite anyway, where speed beats precision

Take the second bullet on its own, since "quick explanation" is doing a lot of unexamined work. "Explain database indexing to me" gets a serviceable, textbook answer. Add three lines: Task, a junior developer who just inherited a slow query. Action, explain what a database index actually does. Goal, decide whether adding one here is worth the write-speed tradeoff it costs. Same underlying question, but now the model's default answer and the answer you actually needed start to overlap, because Goal told it what the explanation is for. TAG doesn't make a model smarter. It makes your ask specific enough that generic and useful stop being different things.

Templates like TAG earn their keep exactly when the overhead of a bigger framework would slow you down more than a slightly rougher answer costs you. If you're going to throw the output away or rewrite it heavily either way, three lines is the right amount of setup.

Where Does TAG Run Out?

At the two things it deliberately left out: a format instruction and a role.

No format slot. This is the gap that matters most in practice. Goal describes an outcome ("names should sound trustworthy"), not a shape ("as a numbered list of five, one line each"). RTF and CO-STAR both name the output format explicitly as a dedicated field; TAG never does. Run the same TAG prompt twice and you can get a paragraph one time and a bulleted list the next, because nothing in the framework tells the model to hold its shape steady.

No role. If the answer needs to sound like a specific kind of expert, or read differently depending on who's asking, TAG gives you nowhere to say so. You can fold a persona into Action ("as a brand strategist, suggest…"), but at that point you're borrowing RTF's idea, not using TAG's.

No examples, no context. Like RTF, TAG has nothing resembling few-shot prompting, and no field for background the model needs but hasn't been given. For anything where the desired style is easier to show than describe, TAG alone won't get you there.

None of these three gaps make TAG a bad framework. They make it a framework with a narrow job. RTF was built to hand the model a persona and a shape; CO-STAR was built to handle an audience and a tone; TAG was built to answer one question fast, and it does that one job about as efficiently as three words can. The mistake is reaching for TAG on a task that actually needed one of the other two, then blaming the acronym when the output comes back thin.

How Does TAG Compare to RTF, RACE, and CREATE?

TAG sits at the minimal end of this framework cluster. CREATE, the framework we cover in the companion post to this one, sits near the other end — six fields instead of three, built for a longer creative brief rather than a quick ask. Seeing them side by side makes the trade-off concrete.

TAG and RTF are the same size but solve different problems: TAG names the outcome and leaves format to the model, RTF names the format and leaves outcome to inference. RACE sits one field larger and merges format and outcome into a single "Expectation" line, which is a reasonable middle ground if you don't want to pick between TAG and RTF's respective gaps. CREATE is a different kind of tool entirely, built for briefs long enough that six fields are worth the setup cost, which TAG's whole premise says you should avoid for a quick ask. For the rest of the cluster — CRAFT, CO-STAR, Chain-of-Thought — see the roundup of seven ChatGPT prompt frameworks.

Should You Upgrade a TAG Prompt, or Start Over?

Upgrade it. You almost never need to abandon TAG and start from a different framework's template; you need to add the one field it's missing for the task in front of you.

• Output keeps coming back in the wrong shape → add a Format line, borrowed straight from RTF: "Format: 5 bullet points, one line each."
• Output doesn't sound like the right kind of expert → add a Role line before Task: "Act as a brand strategist."
• Output is fine but you need to reuse this exact ask weekly → that's the point at which a heavier, reusable structure like CREATE starts paying for itself, because the setup cost is spread across many runs instead of one.

The honest rule for the whole cluster: reach for TAG first on anything fast and disposable, patch it with one borrowed field the moment a specific gap shows up twice, and only jump to a six-field framework once you're building something you'll run more than a handful of times. Our prompt engineering cheat sheet has the one-page version of every framework in this cluster if you want the full set in one place.