The RICE Framework for AI Prompting

I used to think AI was unreliable. I'd write a prompt, get something vaguely in the right direction, tweak it, get closer, tweak it again, and after three or four rounds I'd finally have something usable. It worked, but it was expensive and exhausting. The model hadn't changed between attempts. My goal hadn't changed. So why did the same prompt produce brilliant architecture one day and useless fluff the next?

That question bugged me enough to start studying not just the outputs, but the thought processes behind them. I traced how the model reasoned its way from my instructions to its response, and compared the prompts that landed with the ones that didn't. After a while, the pattern became impossible to ignore. It wasn't the model's fault. It was how I was talking to it.

The same way I learned to write clearly for humans through years of reading and writing, I needed to learn to articulate for machines, not in code, but in structure, in clarity, in intent. Four elements kept surfacing in the prompts that worked consistently: Role, Intent, Context, and Expectations. I called it RICE.

Why RICE works

RICE forces you to articulate what you actually want at a level of detail a machine can act on, and the side effect is that it makes you think more clearly about what you're asking for.

• It saves money. Every vague prompt means more iterations, more tokens, more time spent refining an output that could have been right the first time.
• It prevents the AI from making its own decisions. Without clear articulation, the model fills the gaps with guesses, and those guesses compound into a result that's close to what you wanted but never quite there. RICE closes those gaps so the AI executes what you intended, not what it assumed. In other words: RICE reduces variance rather than guarantees correctness.
• It works everywhere. RICE is not a strict checklist. You choose and combine the elements and attributes that fit your specific ask. Some prompts need deep context and minimal expectations. Others need a precise role and a clear intent. The framework adapts to what you're building, and scales from quick prompts to long-running projects.
• It works for everyone. Engineers get precise, reproducible outputs. Executives get faster results without needing to understand how the underlying technology works. Organizations can share effective prompt patterns instead of everyone reinventing their own approach.

The teams I've seen fail with AI didn't fail because the technology wasn't ready. They asked vague questions, got vague answers, and concluded AI was useless. With the right structure, it's remarkably reliable. Not perfect, but predictable enough to trust.

The Four Elements of RICE

To make it easier to talk to AI, I imagine myself onboarding a new hire for a specific task whose success depends entirely on the clarity and completeness of my instructions. RICE consists of four elements, each with their own attributes, that help me formulate instructions an agent can actually execute.

R is for Role

Every new hire is given a role, and every good prompt starts the same way: establishing who the AI agent is. Not just a job title, but a well-defined identity with the right boundaries and perspective.

A vague role makes the AI default to generic patterns. It won't know whether to answer like a mid-level developer or a chief architect, whether to prioritize speed or accuracy, whether to assume enterprise or consumer context. Every one of those choices changes the output.

A well-defined role covers expertise, domain, and capabilities. Get it right and everything that follows has a solid foundation.

Expertise and seniority

An agent should know what level it operates at.

A weak role prompt says:

"You are a software engineer, write a function to handle user authentication."

A strong one says:

"You are a senior backend engineer with over a decade of experience building authentication systems, with deep knowledge of OAuth 2.0, JWT, and session management patterns."

The level matters. A junior engineer and a senior architect produce fundamentally different outputs for the same task.

Domain constraints

It's important to define the boundaries the agent should not cross, like a new hire who joins a specific business unit or team.

"You are a platform architect in the energy sector. Your expertise covers Azure cloud services, Kubernetes, and enterprise integration patterns. Do not provide guidance on data center hardware, network engineering, or security operations."

Boundaries keep the AI focused on what's relevant to you. Without them, it defaults to generic patterns that don't fit your domain.

Capabilities

An AI agent must be told where its capabilities lie, else it will start making its own decisions to fill the gaps.

"You are a frontend engineer skilled in Next.js 15+, Tailwind, and TypeScript. You follow a component-driven development workflow and you have access to a design system reference for UI patterns and accessibility standards."

Specific skillsets constrain the AI's approach to what actually works in your environment.

Putting it all together

"You are a senior enterprise architect at a large European telecom company. You specialize in business and application architecture, with deep experience in Azure cloud services, AI platform engineering, and enterprise integration patterns. You have worked extensively with the TOGAF framework and have practical experience building platforms in the energy and telecom sectors."

And from another perspective:

"Assume the role of an executive advisor specializing in AI-driven transformation for large enterprises. Your experience spans the energy, telecom, and financial services sectors. You communicate complex technical concepts clearly to C-suite leaders without dumbing them down."

I is for Intent

Unless the new hire knows what they are hired to do, their experience and expertise won't be enough. Intent answers what you want to accomplish, and the most common mistake is stopping at a surface-level description that leaves too much room for interpretation.

A strong intent has two layers: the goal, and the depth of the ask.

Goal

What do you want, exactly? Unless you know what you want, the agent won't know what to do.

"Convert this Excel spreadsheet into a functional dashboard that can be presented as a high-level operational report to the top execs in the organization."

That's a start, but vague enough that the AI could produce anything from a simple table to a full analytics suite. What will the dashboard contain? Should it be a one-pager? Should users just consume it, or interact with it? This is where depth and specificity come in.

Depth and specificity

"Convert the Excel spreadsheet into a working dashboard with both a summary view showing high-level KPIs and a detailed drill-down view for each individual data point. The summary should highlight trends and anomalies. The detail view should show the raw data with sorting and filtering."

The simple prompt gives you something. The deeper one gives you what you actually want.

Audience

Who is this for? The same intent produces different outputs depending on the audience. A dashboard for the executive team emphasises KPIs and trends. A dashboard for the engineering team emphasises raw data and drill-downs. The audience shapes the tone, the level of detail, and what the AI chooses to highlight.

"Create a summary of this incident report for two audiences. For the executive team: focus on business impact, timeline, and resolution. For the engineering team: focus on root cause, technical details, and remediation steps."

"This documentation is for new developers joining the team. Assume no prior knowledge of our internal systems. Explain concepts from first principles. Include setup instructions and common troubleshooting steps."

Putting it all together

Here's an example for Business Analysts:

"Create a PRD for a new internal AI assistant platform. The document should cover the business case, technical architecture options, implementation roadmap, and risk assessment. It needs to be detailed enough for engineering to estimate effort, but structured so leadership can make a go/no-go decision."

And another, for the techies:

"Design and implement a user management microservice that handles registration, authentication, authorization, and profile management. The service must support OAuth 2.0 and SAML-based single sign-on, provide REST and gRPC APIs, and include rate limiting, audit logging, and integration tests. Deliver a complete PRD, an OpenAPI specification, and a working service deployed to our Kubernetes staging environment."

One more, for the execs:

"This presentation will be delivered to an executive leader who has genuine interest in AI but limited hands-on experience with coding tools. Frame everything around strategic value. They need to see the business outcome, not the implementation details."

C is for Context

Context is where the quality of the output is decided. It expands the what, and answers the why, the why not, the how, and the how not.

Think about onboarding a new hire again. You've told them their role and what they need to do, but they still have a hundred questions. Where do I find the documents? What systems can I touch? What does the schema look like? What happens if I get it wrong? Most prompts skip these questions entirely, leaving the AI to fill the gaps with assumptions that are often wrong.

Good context covers five areas: source, workflow, impact, consequences, and guardrails.

Source

Tell the agent where to get the information it needs, otherwise it will wander.

"Connect to the PostgreSQL database at db.example.com using the credentials in the .env file. Read the schema from the public schema only."

Workflow

How do we do things around here?

"Follow the existing CI/CD pipeline. Commit to develop first, then create a PR for review. Do not deploy directly to production."

Impact

Why does this matter? Adding impact to the context reinforces the success mentality in the agent and focuses its thinking.

"This dashboard will be presented to the executive team. The accuracy of the data directly affects our Q4 investment decisions."

Consequences

What happens if the results are inaccurate? Defining negative consequences reinforces the right path.

"A data leak would be a critical incident, loss of customer trust and regulatory fines. Guard all PII fields. If you're unsure, ask rather than assume."

Guardrails and constraints

What should the AI never do? This is perhaps the most important attribute of context.

"You are to work only within the /src directory. Do not modify any file outside it. If a file must be changed elsewhere, flag it and stop."

Bringing it together

"Connect to the production-read-replica PostgreSQL at prod-replica.internal:5432 using the service account credentials. Read the orders schema only. This report goes to the board. Every number must be accurate to two decimal places. All changes go through feature branches with two approvals. Never expose customer PII. Never query the primary production database. This report is subject to GDPR compliance."

E is for Expectations

What does done actually look like? Without expectations, the AI doesn't know what the final deliverable should be, or when to stop working. You won't know when to stop reviewing either.

Expectations cover four things: artifacts, format, examples, and action.

Artifacts

The tangible result of the task. What do you want at the end?

"A container image pushed to our Azure Container Registry."

"A set of Jira tickets with description, acceptance criteria, and story points."

"A deployment script for the staging environment."

Format

What form should the output take?

"A markdown file for the PRD."

"A PDF for the architecture document."

"The dashboard must be a single-page HTML application with embedded CSS and JavaScript."

Examples

Sometimes the best way to communicate what you want is to show it. Provide existing examples to steer the agent in the right direction.

"Here is an example of a well-structured PRD from a previous project. Use it as a reference for tone, level of detail, and section structure."

"Refer to the design images in the /references folder, and recreate them in HTML. Make sure to keep the general look and feel, including the layout and the typography, but the approach should be modern."

Action

What to do with the artifact once it's ready?

"Deploy the dashboard to Vercel."

"Store the documents in the /docs folder."

"Send a summary to the team Slack channel."

Bringing it together

"I want a proof-of-concept application deployed to a publicly accessible URL. Deliverables include a running frontend, a REST API with Swagger documentation, a deployment guide in markdown, and a 10-slide executive summary PDF. Reference the project structure from our existing auth-service repository. Deploy to staging and notify the team in Slack."

How I use RICE

I use RICE in real projects that will last a long time. I use it in agentic applications, such as ChatGPT, and for agentic development, in tools such as GitHub Copilot and Claude Code. RICE can be used in simple prompts, or as instructions in AGENTS.md (or CLAUDE.md).

I use it as an agent skill, a copy-able template that can be pasted in applications like ChatGPT, and a prompt to convert a prompt into a RICE prompt. It’s all available under the Resources section at the bottom.

RICE has no strict limitations; it can be used in any context: from an analytical report to a full-blown application; from a presentation to requirements documents. The framework works for both general and technical audiences.

One example sticks with me because it helped me relay a technical topic with a non-technical exec. I had 45 minutes to introduce an executive lead to Claude Code - someone genuinely interested in AI, but without hands-on coding experience. They wanted to understand it, even try it out themselves, and I needed to position them as an AI-enabled leader, not just demo a tool.

I formulated a prompt using RICE to ask GitHub Copilot* to generate an HTML presentation that contained the instructions to first introduce them to basic prompting principles, and how RICE can be applied to improve the prompting quality, before showing them the basics of Claude Code.

* GitHub Copilot to talk about Claude Code?? Why??

Here it is, feel free to test it out yourself:

Role: Executive advisor specializing in AI transformation for large enterprises, with experience across energy, telecom, and financial services, and bridging the worlds of business and technology with clear communication styles that translate the language of one world to another.

Intent: Design an HTML presentation introducing Claude Code to an executive lead. Cover general prompting techniques and Claude Code specifics, with practical ideas for how executives can use AI coding tools for quick prototypes and data visualization. The presentation should also contain an introduction to the RICE Framework (Role, Intent, Context, Expectations) to enable the exec to create quality prompts and get accurate results.

Context: The meeting is 45 minutes long and includes a live demo. The executive has genuine interest in AI but limited hands-on experience with coding tools. Frame everything around strategic value. Include a sample prompt that demonstrates RICE. Do not go into the details of RICE or Claude Code, and stick to the overviews and basics. Example: basic commands in Claude Code (help, model, init, clear, compact, usage).

Expectations: An HTML presentation with at most 6 - 8 slides, in clear, corporate styles and simple wordings, positioned as a pre-step to the demo. Reference the style from the attached template. Save to the /presentations directory in both light and dark themes.

It worked. The presentation was ready, it was relevant, and it fit the meeting. But the real win was that it showed the executive how structured prompting works through the very prompt that generated their deck.

A different kind of example came from a technical project where RICE made the difference between a prototype that worked and one that needed three more rounds of iteration.

I needed a business architecture view for one of our units. We use the Vintergatan methodology internally, a Swedish framework from IRM that maps capabilities, processes, and toolsets. The architecture team had the data in Excel files, but nobody outside the team could actually use it without understanding the technicalities of the data.

I wrote a quick prompt that generated a simple web view of the Vintergatan that could start the conversation. It followed RICE Framework partially, but it was structurally off, and the output was more generic than what we really needed. Nonetheless, it was just to get something tangible enough to take the next steps.

Here’s the prompt:

"You are an enterprise architect at our organization. We want to create a Vintergatan business architecture for a business unit in which we outline the capabilities and tools.

The solution should be a modern application based on Next.js, with a Vintergatan view for the public and an admin area for the admins to create, modify, and delete the various capabilities and the toolsets.

The idea is to make the Vintergatan more accessible to everyone, with a user-friendly experience that includes searching, filtering, and other features that make the architecture easier to read, understand, and navigate around.

While the references are in Swedish, we prefer the solution to be in English. I want you to first research on Vintergatan, then go through the excel files in the @references folder, and extract the relevant data in the right format for the application.

Then, make a comprehensive plan to create the application. Any document you generate should be placed in the docs folder, prefixed by the sequence number of the document by generation.

Upon my review and approval, proceed to creating the application."

It was a quick and dirty prompt that just worked, and it served its purpose: the conversation had begun. To be transparent: I did go through a few rounds refining it before it was close to what I presented to the stakeholders.

Once all signals were green, I then structured the same prompt with “real” RICE.

Role: Senior Full-stack Engineer at a Swedish energy company with deep knowledge of Enterprise Architecture and Vintergatan methodology.

Intent: Create a modern web application that visualizes the business capabilities and toolsets of the business unit using the Vintergatan framework. The goal is to make business architecture accessible to both technical and non-technical stakeholders who need to understand capabilities and tools but aren't architects themselves.

Context: Research Vintergatan at irm.se first. Then extract data from the Excel files in the @references folder and convert it into JSON, which should be stored in data.json file (create it if it does not already exist). Verify the data, then create a Next.js application that contains two views: 1. A public view that visualizes the Vintergatan and its details 2. An admin interface for CRUD operations. The public view will present the Vintergatan as a circular diagram, as close to the “real” version as we can draw, as well as list the capabilities and tools under it for easier access. It will also contain search, filter, and navigation features for direct access to the required information. The quality reflects on the team's credibility; the UI/UX must be polished and easy enough for the leadership team to use it intuitively. The references may be in Swedish, but the portal must be in English. Any documents you generate must go in the /docs with sequence-numbered filenames (eg: 01_prd.md, 02_architecture.md, etc.).

Expectations: A stable, functional Next.js application deployed to development in a container, following the CI/CD workflow outlined in the Makefile, documentation and JSON data files stored locally in their respective folders.

This version gave top-notch results in the first iteration.

The real lesson

I've been using RICE for months now, and it's saved me time, money, and a lot of frustration. More importantly, it's made me trust the output enough to rely on it. Not blindly, but predictably.

That's the thing I keep coming back to. The bottleneck isn't the model. It's how we talk to it.

Resources

Want to try out RICE yourself? You can write the RICE prompt yourself now, but here are some materials that might help you get more out of the framework:

• Agent Skill (AGENTS/CLAUDE.md instructions, skills, system prompts, etc.)
• Reusable template (copy/paste)
• RICE-conversion prompt (to transform a prompt to RICE-compliant prompt)

They are all copiable and downloadable from my RICE GitHub repository.

If you're working with AI agents and want to think through prompting strategies, architecture, or how to get your team better results, I'd love to connect. Reach out at zulmehdi.com or find me on LinkedIn.