The ICIO Prompt Framework

TL;DR: ICIO is Instruction, Context, Input, Output: a four-slot prompt structure where Instruction and Context stay fixed across runs, Input is the one thing that changes per call, and Output states the shape you want back. It's the framework that maps most directly onto how an actual API call is built, and it's a poor fit the moment the task needs a persona or a tone.

What Is the ICIO Framework?

ICIO is a four-part prompt structure: Instruction, Context, Input, Output. Instruction is the fixed task. Context is the background the model needs to do it well. Input is the specific data for this one run. Output states the format you want back.

The useful thing about ICIO isn't the four words themselves; several other frameworks in this cluster cover similar ground. It's the split between the first two slots and the last two. Instruction and Context describe the job, and they don't change no matter which piece of data you run through it. Input and Output describe this one call, and they change every single time. That split is exactly how a production prompt template, a system message, or an API call is actually built: a fixed part and a variable part, kept separate on purpose.

Who Actually Coined ICIO, and What Do the Two "I"s Really Stand For?

The four-element idea has a solid, dated source. The acronym label does not, and the sources that use it disagree with each other.

The elements themselves trace to DAIR.AI's Prompt Engineering Guide, whose GitHub repository added its first guide in February 2023 and remains live today at promptingguide.ai (accessed 3 September 2026). Its "Elements of a Prompt" section defines exactly four components:

"Instruction - a specific task or instruction you want the model to perform"

"Context - external information or additional context that can steer the model to better responses"

"Input Data - the input or question that we are interested to find a response for"

"Output Indicator - the type or format of the output."

That page never uses the label "ICIO." It just lists four elements. The acronym appears to be something later writers attached to an already-circulating idea, and once we went looking for who did that first, the sources stopped agreeing with each other.

The earliest dated use of the acronym we could find is Edu360 Cloud's Medium post, published 9 December 2023, which writes it as "ICIO (Input, Context, Intention, Output)" (medium.com/@edu360harvey, accessed 3 September 2026). That's a real, different mapping: Input for the first letter, Intention for the third.

The version that matches the DAIR.AI wording almost exactly, and the one most current pages copy, is Kai Ni's Medium post, published 25 May 2025: "ICIO — Instruction, Context, Input data, Output indicator" (medium.com/@kai.ni, accessed 3 September 2026).

What Does Each Letter Actually Force You to Decide?

Instruction and Context are the two slots you write once and never touch again for a given job. Input and Output are the two slots that make the difference between a one-off prompt and a reusable one: Input is a hole you fill in each time, and Output is the contract you're holding the model to no matter what goes in that hole.

How Do You Build an ICIO Prompt, Slot by Slot?

Start weak, then add each slot and watch what changes. The task: classifying customer feedback.

Weak, no framework at all:

Classify this feedback.

Technically a request, but it doesn't say what the categories are, what background matters, or what shape the answer should take. The model will guess at all three.

+ Instruction:

Instruction: Classify the sentiment of the customer feedback below as
Positive, Negative, or Mixed.

Better, but still missing the thing that actually determines whether this classifier is useful for a B2B support queue instead of a generic sentiment tool.

+ Context, the slot that changes the actual answer:

Instruction: Classify the sentiment of the customer feedback below as
Positive, Negative, or Mixed.
Context: This is from a B2B SaaS support queue. Feedback that mentions
downtime, lost data, or a missed SLA should weigh Negative even when the
tone is polite, because a calm complaint about an outage is still a serious
one.

This is the slot doing the real work, and it's worth pausing on why. Without it, a message like "the outage last week wasn't ideal but your team handled it well" reads as mostly positive: polite, complimentary, resolved. With the Context line, the same message correctly reads as Mixed at best, because the model now knows that "outage" is a weight the tone alone can't cancel out. Nothing about Instruction changed. Context is the whole reason the classification would otherwise be wrong.

+ Input, the part that changes on every single call:

Instruction: Classify the sentiment of the customer feedback below as
Positive, Negative, or Mixed.
Context: This is from a B2B SaaS support queue. Feedback that mentions
downtime, lost data, or a missed SLA should weigh Negative even when the
tone is polite, because a calm complaint about an outage is still a serious
one.
Input: "The outage last week wasn't ideal but your support team handled it
really well and kept us updated the whole time."

+ Output, completing the prompt:

Instruction: Classify the sentiment of the customer feedback below as
Positive, Negative, or Mixed.
Context: This is from a B2B SaaS support queue. Feedback that mentions
downtime, lost data, or a missed SLA should weigh Negative even when the
tone is polite, because a calm complaint about an outage is still a serious
one.
Input: "The outage last week wasn't ideal but your support team handled it
really well and kept us updated the whole time."
Output: Return exactly one label (Positive, Negative, or Mixed) followed by
a one-sentence rationale. No other text.

Now the useful part: Instruction and Context never have to change again. Run this same prompt against a thousand different tickets and only Input moves. That's not a stylistic choice, it's the entire reason to reach for ICIO over a framework that doesn't separate "the job" from "this run's data."

Why Is ICIO the Framework Closest to How an API Call Is Actually Built?

Because its four slots map, almost without translation, onto the three parts a real API call already has: a fixed instruction block, a variable payload, and a response contract.

Instruction plus Context is what goes in a system message: the part you write once and reuse across every request to that endpoint. Input is what goes in the user message or request payload: the one thing that's different on every call. Output is the response format or schema you're asking for, whether that's "one word" or a strict JSON schema a downstream service will parse.

{
  "system": "Instruction: Classify sentiment as Positive, Negative, or Mixed. Context: B2B SaaS support queue; weigh downtime/data-loss/SLA mentions as Negative regardless of tone.",
  "input": "The outage last week wasn't ideal but your support team handled it really well.",
  "output_schema": { "label": "Positive | Negative | Mixed", "rationale": "string" }
}

That's not a coincidence and it's not a forced analogy. ICIO's four words are just human-readable labels for a shape that every classification pipeline, extraction task, and few-shot template already needs, whether or not anyone calls it ICIO. If you're building anything that runs the same instruction against many different inputs, structuring the prompt this way from the start saves you from discovering the split later, the hard way, when Input and Instruction have gotten tangled together in one paragraph.

For structured output specifically, our JSON prompts guide goes deeper on making the Output slot a real schema rather than a loose description.

Where Does ICIO Overlap With Everything Else, and Where Does It Run Out?

Heavily, and it's worth saying so rather than selling four letters as a bigger idea than they are.

ICIO's Instruction and Output map closely onto RTF's Task and Format. That's not a coincidence either: both frameworks are answering "what to do" and "how to shape it back," just with different words and, in ICIO's case, a formal split between background (Context) and the one thing that changes (Input) that RTF leaves implicit in whatever you paste after Task. For a genuinely one-off prompt, that split buys you nothing. For a prompt you'll run fifty times with new data each time, it's the entire value of the framework.

Where ICIO genuinely runs out: tone, audience, and persona. There's no slot for any of them, and bolting a voice instruction onto Context is a workaround, not a feature. For anything a human reader has to enjoy, not just correctly parse, CO-STAR carries the slots ICIO doesn't have. ICIO also has no slot for edge cases or scope the way AUTOMAT does; if your classifier needs to say "I don't know" on ambiguous input, that's a line you add yourself, not something the framework prompts you to include. And if the job needs a persona at all, even a thin one, RTF or our APE breakdown cover territory ICIO doesn't try to.

Do You Need to Learn ICIO If You Already Know RTF?

Not really, unless you're building something that runs the same prompt against changing data. That's the honest answer, and it's worth being direct about it instead of arguing every framework earns a permanent place in your head.

For a one-off chat message, RTF and ICIO produce the same result through nearly the same effort; the extra formality of naming Context and Input separately doesn't buy you anything when there's no second run to protect. The value shows up specifically the moment you're building a template, a classifier, a support-ticket router, or anything with a fixed instruction and a stream of different inputs behind it. At that point, ICIO isn't a competing framework so much as RTF's shape rewritten for the job of running many times instead of once.

A reader who deeply understands why separating fixed instructions from variable data matters is better equipped than one who has memorized ICIO, RTF, RACE, CO-STAR, and three more without noticing that four of them are the same underlying idea in different words. Learn the underlying split once. Reach for whichever framework's vocabulary fits the task in front of you. Our roundup of prompt frameworks covers the wider set, including CRAFT and Chain-of-Thought, if you want the full picture rather than one more acronym.

16 Copy-Paste ICIO Prompts

Every prompt below fills all four slots. Swap the bracketed details and run as written; several are written the way you'd actually template them for repeat use.

Sentiment classification (support queue)

Instruction: Classify the sentiment of the message below as Positive,
Negative, or Mixed.
Context: B2B SaaS support ticket. Mentions of downtime, billing errors, or a
missed SLA should weigh Negative regardless of tone.
Input: [paste message]
Output: One label plus a one-sentence rationale. No other text.

Extraction, structured fields from an email

Instruction: Extract the shipping details from the email below.
Context: Emails come from customers confirming or changing an order; some
fields may be missing.
Input: [paste email]
Output: JSON with keys name, address, city, postal_code, requested_date. Use
null for any field not present. No extra keys.

Code review, single defect class

Instruction: Identify SQL injection risks in the function below.
Context: Python 3.12, this function builds a query from user-supplied
filters before hitting a Postgres read replica.
Input: [paste function]
Output: A numbered list; each item names the line and the specific risk. Say
"none found" if there are none. No style comments.

Translation, tone-preserving

Instruction: Translate the review below into English.
Context: This is a product review; preserve the original's casual tone and
any sarcasm rather than neutralizing it.
Input: [paste foreign-language text]
Output: The translation only, no notes, no bracketed clarifications.

Routing, support ticket triage

Instruction: Assign this ticket to one team: Billing, Technical, or Account.
Context: Billing covers charges and plan changes only. Technical covers
anything about product behavior. Account covers logins and permissions.
Input: [paste ticket text]
Output: One team name only.

Summarization, fixed length

Instruction: Summarize the article below.
Context: This feeds a daily digest email read by non-specialists in under 10
seconds per item.
Input: [paste article]
Output: Exactly two sentences, no jargon without a one-clause explanation.

Data cleaning, single-column normalization

Instruction: Normalize the job titles below to one of a fixed set.
Context: Valid categories: Engineer, Manager, Designer, Sales, Other. Titles
vary wildly in wording but usually map cleanly to one category.
Input: [paste list of raw job titles]
Output: A table, original title in one column, mapped category in the other.

Contract clause tagging

Instruction: Tag the contract clause below with its type.
Context: Valid types: Termination, Payment, Liability, Confidentiality,
Other. This is for a non-lawyer scanning a long contract quickly.
Input: [paste clause]
Output: One type, plus a plain-English one-sentence gloss of what it means.

Meeting notes to action items

Instruction: Extract action items from the transcript below.
Context: Notes are messy and include tangents; only extract things someone
explicitly agreed to do.
Input: [paste transcript]
Output: A list of owner and task pairs. Skip anything discussed but not
assigned.

Product review, feature request detection

Instruction: Determine whether the review below contains a feature request.
Context: A feature request is a specific ask for new functionality, not a
general complaint.
Input: [paste review]
Output: "Yes" or "No", plus the requested feature quoted verbatim if yes.

Resume screening, single criterion

Instruction: Determine whether the candidate below meets the minimum
requirement of 3+ years of backend experience.
Context: Count only roles explicitly described as backend, API, or server
engineering; frontend-only roles don't count.
Input: [paste resume text]
Output: "Meets" or "Does not meet", plus the total years counted.

Bug report triage

Instruction: Classify the severity of the bug report below as Critical,
High, Medium, or Low.
Context: Critical means data loss or an outage. High means a core feature is
broken with no workaround. Medium has a workaround. Low is cosmetic.
Input: [paste bug report]
Output: One severity level, plus the phrase that justified it, quoted.

FAQ answer drafting from a knowledge base excerpt

Instruction: Draft a one-paragraph FAQ answer to the question below, using
only the excerpt provided.
Context: This will publish verbatim on a public help page; do not add any
fact not present in the excerpt.
Input: Question: [paste question]. Excerpt: [paste source text]
Output: One paragraph, 40 to 70 words, no hedging language.

Log line classification

Instruction: Classify the log line below as Error, Warning, or Info.
Context: This feeds an automated alerting pipeline; only Error should ever
trigger a page.
Input: [paste log line]
Output: One word only, exactly matching one of the three categories.

Comment moderation, single policy

Instruction: Determine whether the comment below violates the no-harassment
policy.
Context: Policy covers targeted insults and threats, not disagreement or
strong criticism of a product.
Input: [paste comment]
Output: "Violation" or "No violation", plus the specific phrase that
triggered the decision if a violation.

Invoice line-item categorization

Instruction: Categorize the expense line item below.
Context: Valid categories: Software, Travel, Office, Marketing, Other. This
feeds an accounting export and must use exactly one category.
Input: [paste line item description and amount]
Output: Category name only.

Is This What Prompt Architects' Enhance Feature Does?

Roughly the same underlying idea, though not by literally running ICIO. Our enhancer takes a raw prompt and structures it into role, task, format, constraints, and tone in under two seconds, which is what all of these compact frameworks are automating pieces of by hand: turning an underspecified request into one with the parts a model actually needs stated explicitly.

What ICIO adds that our enhancer doesn't do for you is the discipline of separating the fixed part of a job from the part that changes every run, which matters once you're building something rather than asking a one-off question. Every plan runs on built-in AI with no API key required, and the published free tier is 5 prompt enhancements per day according to our FAQ page. Turning that structure into a reusable template with Input as the one field you swap is still the part only you can design, because only you know which piece of your prompt is actually the job and which piece is just this run's data.