Prompt better. Score higher.
A practical guide to the seven criteria ROIP measures: what each one means, what a prompt that leaves it open looks like, and how to fix it in your next AI session.
You don't need all seven in every prompt.
ROIP only counts the decisions you would have cared about. If a prompt leaves nothing important open, it loses nothing, however short it is: there's no reward for adding instructions just to tick a box. Use each guide below to recognize when a criterion matters, and what settling it up front looks like.
“What's the capital of Peru?”
Calls forDirection“Summarize this contract for our sales team in five bullets. They mostly care about renewal terms.”
Calls forDirectionContextFormat“Polish this paragraph. Don't add or remove any content.”
Calls forDirectionConstraints“Point 3 is wrong. The term is 24 months, not 12. Fix it and keep the rest.”
Calls forEvaluationContext
Direction
Tell the AI what you want, and what a good outcome looks like.
The model can only aim at the target you give it. Direction covers the task itself: the goal, why you need it, and the role to take.
When direction is missing, the model fills the gap with the most generic reasonable guess. That guess is rarely what you had in mind, and fixing it costs you a turn.
Common problems
- Vague direction
- “Help me with my resume” could mean rewrite it, critique it, tailor it to a job, or reformat it.
- A task without a goal
- “Summarize this” doesn't say what the summary is for, so the model can't decide what to keep.
- Conflicting instructions
- “Keep it short but cover everything in detail” forces the model to pick one, and it may pick wrong.
- Unnecessary ambiguity
- Words like “better,” “improve,” or “professional” mean different things to different people. Say better how.
Weak vs. strong
- YouWrite an email to my team about the deadline.
Which deadline, what changed, and what should the team do? The model has to invent all of it.
- YouWrite an email telling my team the launch has moved from March 3 to March 17. The goal is to reassure them: the delay is to fix a payment bug, not because anyone fell behind. Ask each lead to send an updated timeline by Friday.
States the change, the reason, the tone to strike, and the one action the team needs to take.
- YouMake this paragraph better.
“Better” has no target. The model will guess, often by making it longer and more formal.
- YouTighten this paragraph for a non-technical executive. Cut jargon, keep it under 80 words, and lead with the cost impact.
Replaces “better” with an audience, a limit, and a priority the model can actually check against.
Try this in your next session
- Start with the outcome: “I need X so that Y.”
- Name the audience and what they should think, feel, or do after reading.
- Swap adjectives for criteria: “professional” becomes “no slang, no exclamation points, formal sign-off.”
- Resolve conflicts yourself. If length and depth trade off, say which one wins.
Context
Give the AI the background it can't know on its own.
The model doesn't know your company, your project, your data, or what you've already tried. Every missing fact becomes an assumption, and assumptions are where responses quietly go wrong.
Good context is relevant and specific. More isn't always better: the goal is to give the model what it needs to decide well, not everything you have.
Common problems
- Missing context
- Asking for a pricing recommendation without saying who your customers are or what competitors charge.
- Assumptions the model has to make
- Without details, it assumes a default: a typical budget, a common tech stack, a US audience, an intermediate skill level.
- Irrelevant context
- Pasting a 40-page document when one section matters buries the important part.
- Stale context
- Details from earlier in the conversation that no longer apply but were never corrected.
Weak vs. strong
- YouWhy is my code slow?
No code, no scale, no environment. The model can only offer generic performance advice.
- YouThis Python function processes a 2-million-row CSV and takes about 40 seconds. It runs nightly on a server with 4 GB of memory, so memory matters more than speed. I've already tried reading it in chunks with pandas. Here's the function: […]
Gives the scale, the environment, the real constraint, and what's already been ruled out.
- YouWrite a cover letter for this job.
The model knows nothing about you, so it writes a letter that could belong to anyone.
- YouWrite a cover letter for the product analyst posting below. I'm moving from four years in retail operations. My most relevant work is the weekly inventory dashboard I built that my whole region still uses. Posting: […]
Supplies the job, the career change, and the one accomplishment worth building the letter around.
Try this in your next session
- Ask yourself what a smart colleague who's new to this would need to know.
- Include what you've already tried, so the model doesn't suggest it again.
- Share the facts that shape the answer: your audience, your tools, your data, your policies.
- Paste the relevant part of a document, not all of it, and say which part matters.
- Correct context that has changed: “Ignore the earlier budget. It's now $5,000.”
Format
Specify the shape of the answer you need.
The same content can be a paragraph, a table, a checklist, or JSON. If you'll paste the output into a message, read it on a phone, put it on a slide, or feed it to another tool, say so.
A clear format instruction saves the turn you'd otherwise spend asking for a rewrite.
Common problems
- No length guidance
- You get a full essay when you needed two lines, or a one-liner when you needed depth.
- The wrong structure
- Prose when you needed to compare options side by side, or bullets when you needed a flowing argument.
- Unspecified tone
- A casual answer for a formal document, or a stiff one for a friendly message.
- Loose data formats
- Asking for “JSON” without the fields, types, or what to do when a value is missing.
Weak vs. strong
- YouCompare these three laptops.
You'll likely get three long paragraphs that are hard to compare at a glance.
- YouCompare these three laptops in a table with columns for price, weight, battery life, and ports. Below the table, give a one-sentence recommendation for a student who travels every week.
Names the structure, the exact columns, and a short, targeted conclusion.
- YouPull the contacts out of this text as JSON.
Field names, nesting, and missing values are all left to chance, which breaks anything that parses the output.
- YouPull the contacts out of this text as a JSON array. Each item: { "name": string, "email": string or null, "company": string or null }. Return only the JSON, with no explanation.
Defines the schema, how to handle missing values, and that nothing else should be returned.
Try this in your next session
- Give a length: a word count, a number of bullets, or “fits on one screen.”
- Name the structure: a table, numbered steps, headings, or a single paragraph.
- Say where it's going: a Slack message, a slide, an email, or code that will parse it.
- For data, define the fields, their types, and what to do with missing values.
- Say what to leave out: “No introduction and no summary at the end.”
Constraints
Say what's off-limits, and the bounds the answer has to stay inside.
Constraints are the decisions about what the answer must not do: what must stay unchanged, what to avoid, the budget, the deadline, the rules it has to follow. The model can't see any of them unless you say so.
A missing constraint rarely shows in the first answer. It shows when you notice the AI rewrote the numbers you needed kept, promised a feature that isn't shipped, or planned a budget you don't have, and you spend a turn undoing it.
Common problems
- Unstated no-go areas
- “Polish this email” and the AI changes the dates, the prices and your sign-off, because nothing said they were fixed.
- Missing bounds
- A plan with no budget or deadline assumes a generous one. A plan for your situation needs yours.
- Rules the model can't know
- Brand words you never use, claims legal won't allow, a version of a library you're stuck on.
- Constraints buried in the middle
- A crucial “don't” in the fourth paragraph of a long prompt is easy for the model to drop.
Weak vs. strong
- YouPolish this launch email for customers.
Nothing says what has to stay. Dates, prices and promises are all fair game for a rewrite.
- YouPolish this launch email for customers. Don't change any dates or prices, keep it under 150 words, and make no promises about features that aren't shipped.
States what must not change, the length bound, and the one claim to avoid.
- YouPlan a team offsite for next quarter.
Budget, dates and travel limits are left to the model, so the plan fits an imaginary team.
- YouPlan a two-day team offsite for 14 people in late May. Budget is $9,000 all in, nobody flies, and it has to be within two hours' drive of Boston.
Gives the budget, the date window and the travel limit the plan has to respect.
Try this in your next session
- Lead with what must not change: “Keep the numbers and my wording; only fix grammar.”
- Give the bounds as numbers: budget, deadline, word count, versions.
- Name what to avoid: topics, claims, tools, words.
- Put hard limits near the start of the prompt, not buried in the middle.
- If two constraints conflict, say which one wins.
Examples
Show what a good result looks like when describing it isn't enough.
Some qualities are easier to show than explain: a brand voice, a labeling scheme, a data format, a particular kind of humor. One good example can replace a paragraph of description.
Models follow examples closely, though. A careless example can lock in its length, topic, or quirks when you only meant to show the tone.
Common problems
- Describing instead of showing
- “Write it in our voice” means nothing to a model that has never seen your voice.
- One narrow example
- With a single example, the model copies its length, topic, and structure, not just the quality you wanted.
- Examples that contradict your instructions
- Asking for 50 words, then showing a 200-word example. The example usually wins.
- Weak examples
- The model matches the flaws in an example as faithfully as its strengths.
Weak vs. strong
- YouWrite a product description for our canvas tote in our brand voice.
The model has never seen the brand voice, so it falls back on generic marketing copy.
- YouWrite a product description for our canvas tote in our brand voice. Two we like: 1. “The Field Jacket. Waxed cotton, brass snaps, built for rain you didn't plan on.” 2. “The Day Pack. 22 liters, one zip, nothing you'll never use.” Match the rhythm and plain tone, not the products.
Two varied examples show the pattern, and the last line says what to copy and what to ignore.
- YouSort these support tickets into categories.
The model invents its own categories, and they won't match the ones your team uses.
- YouLabel each ticket Billing, Bug, or How-to. Examples: “I was charged twice this month” → Billing “The export button does nothing” → Bug “How do I add a teammate?” → How-to
One example per label makes the boundaries between categories clear.
Try this in your next session
- Reach for an example when the quality you want is hard to put into words.
- Use two or three varied examples, so the model learns the pattern rather than the surface.
- Say what each example demonstrates: the tone, the structure, or the level of detail.
- If a particular mistake is likely, include an edge case or a “not like this” example.
- Make sure your examples follow your own instructions.
Evaluation
Judge the response, then tell the AI exactly what to change.
The first answer is a draft. Strong prompters read it critically, decide what worked and what didn't, and feed that back in the next turn.
Vague reactions make the model guess what you disliked, so it often changes the parts that were fine. Precise feedback gets a precise fix.
Common problems
- Vague feedback
- “This is bad,” “try again,” or “make it better” gives the model nothing to act on.
- Not checking
- Accepting confident-sounding facts, numbers, or code without verifying them before you build on them.
- Letting wrong assumptions stand
- A mistaken assumption from the first turn quietly carries through the whole session.
- Starting over
- Rewriting the original prompt from scratch instead of building on what was already good.
Weak vs. strong
- You, turn 1Draft a launch email for our new shared calendars.
- AIHere's a draft: “Big news! Shared calendars are here…”
- You, turn 2This is bad. Try again.
The model doesn't know what was wrong, so the next draft may lose what worked and keep what didn't.
- You, turn 1Draft a launch email for our new shared calendars.
- AIHere's a draft: “Big news! Shared calendars are here…”
- You, turn 2Keep the structure. Two changes: the opening assumes readers already know what shared calendars are, so add one sentence explaining them. And remove the “30% faster” claim. We don't have data for it.
Says what to keep, pinpoints each problem, and explains why, so the fix is targeted.
- YouAre you sure that's right?
This invites the model to second-guess everything, or to simply agree that it was right.
- YouIn step 3 you used last year's tax brackets. Recalculate using this year's brackets and show the new total.
Identifies the exact error and the correction, and asks to see the result.
Try this in your next session
- Say what to keep, so it doesn't get lost in the rewrite.
- Point to the exact part that's wrong, and say why it's wrong.
- Check facts, numbers, and code before the next step depends on them.
- Correct a wrong assumption as soon as you spot it.
- When you're unsure, ask for two alternatives, then pick one or combine the best parts.
Task Decomposition
Break a big goal into smaller, connected steps.
Asking for everything at once (research, analysis, decisions, and a polished deliverable) makes the model rush every part, and gives you no chance to steer along the way.
Splitting the work lets you check each step before the next one depends on it, so errors get caught early instead of baked into the final result.
Common problems
- One giant prompt
- A multi-stage task crammed into a single request, with no checkpoints.
- Mixing research and conclusions
- When facts and opinions arrive together, you can't tell which is which.
- Executing before planning
- Getting a full draft before agreeing on the outline, then rewriting all of it.
- Steps out of order
- Writing the summary before the analysis exists, or pricing before knowing the costs.
Weak vs. strong
- YouWrite a full business plan for my coffee subscription startup.
The model has to invent the market, the pricing, and the strategy in one pass, and you can't correct any of it until the end.
- You, turn 1First, list the questions a business plan for a coffee subscription needs to answer. Don't answer them yet.
- You, turn 2Good. Let's start with the market. Here's what I know about our customers: […]
- You, turn 3Now draft the pricing section, using the market numbers we just agreed on.
- You, turn 4Combine everything into a two-page plan.
Plans first, works through each part in order, and assembles the pieces only after each one has been checked.
- YouResearch our three competitors and tell me which features we should build.
Research and recommendations arrive tangled together, and the conclusions rest on facts you never got to check.
- You, turn 1For each of these three competitors, list their main features and pricing. Facts only, no opinions yet.
- You, turn 2Based on that list, which needs do none of them cover well?
Separates gathering facts from drawing conclusions, so the analysis stands on information you've reviewed.
Try this in your next session
- Plan first: ask for an outline or an approach before the full output.
- Separate gathering information from drawing conclusions.
- Handle dependencies in order, so each step builds on the result of the last.
- Review each step before moving on to the next.
- Finish with an assembly step that combines the pieces into the final result.
Before you send
Seven quick questions. If the answer to one doesn't matter for this prompt, skip it and move on.
- DirectionWould someone else reading this prompt know exactly what a good answer looks like?
- ContextIs there anything the AI would have to guess about my situation?
- FormatWill the answer arrive in a shape I can use right away?
- ConstraintsIs there anything the answer must not do, or a limit it has to stay inside, that I haven't said?
- ExamplesIs the result I want easier to show than describe?
- EvaluationHave I told the AI exactly what worked and what needs to change?
- Task DecompositionIs this goal small enough to get right in one step?
See how your next AI session scores.
Install the extension and connect your terminal, then keep working in ChatGPT, Claude, Gemini, Copilot or your terminal. Worsley scores each session and tells you what to change next time.