Ajitha.
Back to Blog
AIPrompt EngineeringTutorialRISEN

Stop Winging Your Prompts — Use the RISEN Framework

2026-02-226 min read

I'll be honest — for the longest time, I was just guessing with my prompts. Type something in, get something back, tweak it a bit, repeat. It worked, kind of. But the results were inconsistent, and I never really knew why one prompt worked better than another.

Then I came across the RISEN framework, and things started to click.

In this post, I'll walk you through what RISEN is, how each part of it works, and how you can start applying it right away — with real examples you can copy and adapt.

We'll cover:

  • What the RISEN framework is and why it works
  • A breakdown of each component with examples
  • A before/after prompt comparison
  • Tips for applying RISEN to your own use cases

Let's get into it.

What is RISEN?

RISEN is a prompt engineering framework that gives your prompts structure and intention. Instead of throwing a vague instruction at an AI model and hoping for the best, RISEN helps you communicate clearly — almost like giving a new teammate a proper brief.

RISEN stands for:

  • R — Role
  • I — Instructions
  • S — Steps
  • E — End Goal
  • N — Narrowing (constraints)

Think of it like a recipe. Each ingredient matters, and leaving one out changes the dish. You can make soup without salt — but it won't taste the same.

Breaking Down RISEN

R — Role

This is where you set the context for who the model should be when responding. Not just "you are an assistant" — go specific. The more grounded the role, the more targeted the output.

Example:

You are a senior developer advocate with 10 years of experience writing
technical tutorials for developers new to APIs.

Defining a role helps the model calibrate the tone, depth, and vocabulary of its response. A "senior developer advocate" will write differently than a "friendly chatbot."

I — Instructions

This is the what. What do you actually want the model to do? Be direct and use action verbs.

Example:

Write a beginner-friendly blog post explaining how webhooks work.

Don't bury the ask. Lead with it.

S — Steps

This is where you give the model a roadmap. If your task has a natural sequence — tell it. This is especially useful for complex outputs like tutorials, analyses, or multi-part content.

Example:

Follow these steps:
1. Start with a real-world analogy to explain webhooks
2. Define what a webhook is in plain English
3. Show a simple webhook payload example in JSON
4. Explain how to verify and respond to a webhook event
5. End with a common mistake developers make

Giving steps keeps the output structured and prevents the model from improvising in ways you didn't want.

E — End Goal

This is the why. What should the reader walk away with? Naming the end goal helps the model stay focused — especially for longer outputs that can drift off-topic.

Example:

The goal is for a developer who has never used webhooks before to feel
confident enough to set up their first webhook listener after reading this post.

This is different from instructions — instructions tell the model what to do, end goal tells it what success looks like.

N — Narrowing

These are your constraints. Length, format, things to include, things to avoid. This is where you tighten the output.

Example:

Keep the post under 800 words. Avoid marketing language. Use code examples
in Node.js only. Do not assume the reader knows what HTTP is.

Narrowing is one of the most underused parts of prompting. Without it, you get a response that's technically correct but practically not what you needed.

Putting It All Together

Here's a full RISEN prompt for writing a developer blog post:

Role:
You are a developer advocate with experience writing tutorials for
developers who are new to APIs and webhooks.

Instructions:
Write a beginner-friendly blog post explaining how webhooks work.

Steps:
1. Start with a real-world analogy
2. Define what a webhook is in plain language
3. Show a sample webhook payload in JSON
4. Explain how to verify and respond to a webhook
5. End with one common mistake developers make

End Goal:
The reader should feel confident setting up their first webhook listener
after reading this post.

Narrowing:
- Keep it under 800 words
- Use Node.js for all code examples
- Avoid jargon — define technical terms when you use them
- No marketing language

Compare that to the version most of us start with:

Write a blog post about webhooks.

Same topic. Wildly different outputs. The RISEN version gives the model everything it needs to actually help you.

Use relevant fields and you can remove certain component as per your need.

Tips for Applying RISEN

Be specific in the Role. "You are a software engineer" is weaker than "You are a backend engineer with experience in distributed systems writing for an audience of junior developers."

Use Steps for anything sequential. If you find yourself getting outputs that are incomplete or out of order, Steps will fix that almost every time.

Treat Narrowing as your filter. It's the difference between a response that answers the question and one that answers the question in the way you can actually use.

Iterate. Your first RISEN prompt doesn't have to be perfect. Adjust one component at a time and see how the output changes. That's how you build intuition for this.

Wrapping Up

RISEN isn't magic — it's just good communication. The more clearly you can express what you want, the more useful the response will be. And that's true whether you're writing prompts for an AI model or writing requirements for your engineering team.

Give it a try with your next prompt. I think you'll notice the difference pretty quickly.

Thanks for reading! If you have questions or want to share a prompt you've built using RISEN, feel free to reach out.