ROSES
The only framework here that makes you supply the answer before asking for it.
What is ROSES?
ROSES has five slots: Role, Objective, Scenario, Expected Solution and Steps. It is built for teaching material — training modules, runbooks, onboarding, coaching plans — and it contains one idea no other framework here has: you supply the correct answer, and ask the model to build the path to it.
The unusual slot is Expected Solution, and it inverts how people normally prompt. Everywhere else you describe the problem and ask for an answer. In ROSES you state the answer — the refund is approved, the incident is escalated at ten minutes — and the model’s job is to construct the route a learner should follow to reach it. That is exactly right for training, because in training the answer is not in doubt and the reasoning is the whole deliverable. It is also the single most effective anti-hallucination device on this site: a model that has been given the conclusion has nothing left to invent.
Where ROSES Came From
A modern acronym without a founder
ROSES has no documented author and no history before prompting. It is one of the longer acronyms in the family, and unusually it is shaped around a use case rather than around general writing — the slots only make sense if what you are producing teaches somebody something. Any page naming an inventor is guessing.
What it inherits from instructional design
The shape is older than the acronym. Scenario-based learning — put the learner in a specific situation, show the correct handling, break it into steps — has been standard in corporate training for decades, precisely because abstract policy does not survive contact with a real customer. ROSES is that method with the slots named.
Why Expected Solution exists
Because training material with an uncertain answer is not training material. If the handling is genuinely in doubt you are writing a decision aid, not a lesson — and you want SCQA or a reasoning framework. The presence of this slot is ROSES telling you what it is for.
The 5 Slots, One at a Time
Each slot is a decision. Leave it out and the model still makes it — just without you.
The learner half matters more than the writer half. A first-week agent who has used a helpdesk before but never seen your product needs different material from a career changer — the first needs product specifics, the second needs the concepts underneath. Naming prior experience is what stops the material being pitched at nobody.
Objective must be a capability, not a topic. "Understand our refund policy" is untestable; "handle a refund request end to end without escalating, and know the two cases where they must escalate" can be checked by watching someone do it. The second half — knowing the limits — is the part people leave out.
A clean scenario teaches nothing. The value is in the complication — the customer is inside the refund window but has used the product heavily, which is exactly the situation where a new agent invents a policy. Pick the case that produces the mistake you are trying to prevent.
The slot that defines the framework. Give the answer — and give the parts of it that are counter-intuitive, because those are what the material exists to teach. "Does not mention usage" is the whole lesson in the example below; without it the model will write a module that has the agent weighing usage, which is the error you were trying to prevent.
Steps should be numbered and each should carry three things: what to check, what to say, and what to record. Material that gives only the first is a policy document; material that gives all three is something an agent can hold in one hand on a live ticket.
One Task, Before and After
The task: Write a training module on handling refund requests. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.
Write training material for new support agents.
Seven words. You will get generic customer-service advice with invented policy details, invented system names and invented reason codes — material that would actively mistrain an agent.
Role: You are a support enablement lead writing for agents in their first week, who have used a helpdesk before but have never seen our product. Objective: After this module an agent should be able to handle a refund request end to end without escalating, and know the two cases where they must escalate. Scenario: A customer emails asking for a refund on an annual plan they bought nine weeks ago. Our policy allows refunds within 60 days. They are inside the window but have used the product heavily. Expected Solution: The agent approves the refund, does not mention usage, and offers a downgrade as an alternative before processing. Steps: Break the handling into numbered steps, each with what to check, what to say, and what to record. Think through where a new agent would most likely go wrong before you write the steps. For example, a step should read like this: ``` 3. Check the purchase date in Billing > Subscriptions. If it is inside 60 days, approve - do not weigh usage. Record the reason code REFUND_WINDOW. ``` Write 500-700 words in five headed sections. Do not invent policy details, reason codes or system names beyond those given, and do not tell the agent to use their judgement on the refund window.
Ninety-six — the highest score of any worked example on these pages. Five slots, all filled concretely, plus a fenced sample step and an explicit ban on invention.
Why ROSES scores highest of all
Ninety-six is the top of every framework page here, and it is not because ROSES is the best framework. It is because its slots happen to line up with almost everything the scorer measures:
The only shortfall. "Support enablement lead" is a real role but not a seniority-plus-domain one — and honestly, for training material the learner description matters far more than the writer’s title.
Supplying the answer removes the model’s licence to invent one. In a domain full of policy details and reason codes, that is worth more than any instruction about accuracy.
One concrete case fills the context dimension; numbered steps with a fenced sample fill format and examples. Two slots covering four checks.
The transferable idea is the inversion: where you already know the answer, give it. Most people withhold the conclusion because asking feels like the point of prompting — and then spend the next three attempts correcting a model that guessed. If the outcome is not in doubt, stating it converts an unreliable generation into a formatting task.
Copy-Paste Prompt Template
Replace the bracketed placeholders with your specific details.
Role: [Who writes, and — more importantly — who learns, including what they have done before] Objective: [What the learner can DO afterwards, including where they must stop] Scenario: [One concrete case, including the detail that makes it awkward] Expected Solution: [The correct handling, stated by you — especially the counter-intuitive parts] Steps: [Numbered, each with what to check, what to say and what to record] ``` [one sample step in the exact shape you want] ``` [Length and sections. Ban invented policy, codes and system names]
When ROSES Fits — and When It Does Not
- Training modules, onboarding material and internal enablement.
- Runbooks and incident procedures, where the correct handling is fixed and the steps matter.
- Coaching and mentoring plans built around a specific situation.
- Lesson plans and tutorials — anything scenario-based.
- Any task where you know the right answer and need the path to it written out.
- Anything where the answer is genuinely open. Expected Solution has nothing to hold. Use SCQA or ReAct.
- Short messages. Five slots for a Slack post is more scaffolding than message — use APE.
- Persuasion and marketing. ROSES teaches; it does not move anyone.
- Exploratory analysis, where supplying a conclusion would defeat the exercise.
10 Ready-Made ROSES Prompts
Every prompt below was produced by the Frompting generator with ROSES selected — not written by hand for this page. Each is scored by our prompt checker; the median is 91/100. Click one to open it, then copy.
Training: new customer support agents 84
You are a training content developer tasked with creating comprehensive onboarding material for new customer support agents. The goal is to equip these agents with the knowledge, skills, and confidence needed to handle customer inquiries effectively, maintain high satisfaction scores, and adhere to company policies. Assume the agents will be supporting [PRODUCT_OR_SERVICE: specify the product or service they will assist with] and will operate in a [CHANNEL: specify primary support channel, e.g., email, chat, phone]. The training should result in a clear, self‑contained guide that new hires can study independently and reference on the job, covering essential concepts, typical interaction flows, and best‑practice techniques. Deliver a structured document that includes: 1. An introductory overview that explains the purpose of the training and the key outcomes expected of the agents. 2. A realistic onboarding scenario that places the learner in a typical first‑day situation, describing the environment, tools, and common customer issues they will encounter. 3. The desired solution for the scenario, detailing the correct approach, tone, and procedural steps the agent should follow to resolve the issue successfully. 4. A step‑by‑step instructional section that breaks down the training into logical modules (e.g., product knowledge, communication skills, escalation process, use of support software). For each module, provide: - A concise learning objective. - Core content points (bullet format). - Example dialogues or interactions. - Quick‑check questions or prompts for self‑assessment. The final guide should be approximately 1,200–1,500 words, written in clear, professional language suitable for a [EXPERIENCE_LEVEL: specify novice, intermediate, or advanced] audience. Ensure the tone is supportive and encouraging, use concrete examples, and avoid unnecessary jargon. Quality criteria: - Completeness: all essential support competencies are covered. - Clarity: instructions are easy to follow and free of ambiguity. - Practicality: includes real‑world examples and actionable checklists. Exclude any references to internal company branding, proprietary tools not mentioned, or unrelated support channels. If any critical details are missing, state your assumptions and ask up to three clarifying questions before finalizing the material.
Workshop outline: teaching prompt writing 88
You are an instructional designer tasked with creating a detailed workshop outline that teaches participants how to write effective prompts. The workshop is intended for **[AUDIENCE TYPE]: e.g., beginners, intermediate users, or advanced practitioners** and should achieve the goal of enabling them to craft clear, purposeful prompts that produce reliable, high‑quality outputs. Assume the session will run for **[WORKSHOP LENGTH]: e.g., 2 hours, half‑day, full‑day** and will be delivered in a **[DELIVERY MODE]: e.g., live virtual, in‑person, or hybrid** setting. Produce an outline of **approximately 300 words** that includes: 1. A concise opening statement describing the facilitator’s role and the participants’ expected learning outcome. 2. A clear statement of the workshop’s primary objective. 3. A realistic scenario that frames the prompt‑writing task participants will practice. 4. The specific solution participants should be able to produce by the end of the session. 5. A step‑by‑step agenda (minimum three steps) detailing activities, timings, and instructional methods (e.g., brief lecture, hands‑on exercise, group discussion, feedback). Quality criteria: - The outline must be logically sequenced and easy to follow. - Each step should include an actionable activity and a brief rationale. - Language should be clear, professional, and free of unnecessary jargon. Exclude any references to the underlying framework or its component names. If any of the placeholders above are unknown, state your assumption and proceed, or ask up to three clarifying questions before finalizing the outline. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Onboarding checklist for an engineering hire 89
You are an experienced engineering onboarding specialist tasked with designing a concise, actionable checklist for a newly hired engineer. The purpose is to ensure the new hire can quickly become productive, understand essential processes, and integrate smoothly into the team. Assume the hire will join a [TEAM TYPE: e.g., software development, hardware design, systems engineering] team that follows a typical corporate onboarding schedule and will need to set up core development environments, access required systems, and learn key team conventions. The deliverable should be a clear, step-by-step checklist that a manager can hand to the new employee on day one. Include sections for pre-start preparation, first-day activities, first-week milestones, and any required compliance or security steps. Use plain language, keep each item brief (no more than one sentence), and format the list as markdown bullet points. Aim for a total length of 305-405 words. Quality criteria: 1. All critical onboarding tasks are covered without unnecessary detail. 2. Items are ordered logically by time frame (pre-start → day 1 → week 1). 3. The checklist is easy to scan and act on. Exclude any company-specific policies or tools that are not provided; if such details are needed, note them as “[PLACEHOLDER: specific tool or policy]”.
Coaching plan for an underperforming report 96
You are a performance coaching specialist. Your task is to create a concise, actionable coaching plan for a team member who is currently underperforming. The plan should be written for the team member’s direct manager to implement over a short-term period. The output must be a structured document of approximately 625-825 words, organized as follows: 1. **Context** - Briefly describe the team member’s role and the specific performance gaps to address. 2. **Goal** - State the clear performance improvement target the manager should aim for. 3. **Situation** - Outline a realistic scenario in which the manager will apply the coaching (e.g., a weekly 1-on-1 meeting, a project deadline, or a skill-building workshop). 4. **Solution Overview** - Summarize the expected outcome of the coaching plan, including measurable indicators of success. 5. **Action Steps** - Provide 4-6 concrete, sequential steps the manager should follow, each with a brief rationale and an estimated time allocation. **Quality criteria**: - Each step must be specific, observable, and time-bound. - The language should be supportive yet direct, avoiding vague advice. - Include at least two measurable metrics (e.g., task completion rate, quality score) to track progress. **Boundary**: Do not include generic leadership theory; focus solely on practical actions the manager can take immediately. If any essential details are missing, state your assumptions clearly and ask up to three clarifying questions (e.g., the team member’s exact role, the primary performance issue, the desired improvement timeframe). [TEAM_MEMBER_NAME]: Provide the name of the employee. [TEAM_MEMBER_ROLE]: Specify the employee’s job title. [PERFORMANCE_ISSUE]: Describe the key area where performance is lacking. [IMPROVEMENT_TIMEFRAME]: Indicate the target period for achieving improvement. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Lesson plan: spreadsheets for beginners 91
You are an instructional designer tasked with creating a beginner‑level lesson plan for teaching spreadsheet fundamentals. Your goal is to produce a clear, engaging, and practical lesson plan that enables absolute novices to understand and use basic spreadsheet functions confidently. Assume the lesson will be delivered in a classroom or virtual workshop setting to learners with no prior spreadsheet experience. If any key details (such as the specific spreadsheet application, session length, or learner age group) are unknown, state your assumptions and ask up to three clarifying questions before finalizing the plan. The lesson plan should include: - A concise title and brief overview of the session. - Learning objectives expressed as observable outcomes. - Required materials and any pre‑session setup. - A step‑by‑step sequence of instructional activities, each with a purpose, estimated time, and suggested teaching method (e.g., demonstration, guided practice, independent exercise). - Simple hands‑on exercises that reinforce each concept. - An informal assessment or check‑for‑understanding activity at the end. Deliver the plan in plain text, organized with clear headings and bullet points where appropriate. Aim for a total length of 300–400 words. Ensure the language is beginner‑friendly, avoids jargon, and includes brief explanations for any technical terms introduced. Exclude any advanced topics such as macros, pivot tables, or complex formulas. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Mentoring guide for a junior designer 96
You are an experienced design mentor tasked with creating a concise, practical mentoring guide for a junior designer. Your purpose is to equip the mentee with clear expectations, core responsibilities, and actionable advice that will accelerate their growth and confidence in a professional design environment. Assume the guide will be used in a typical design team setting where the junior designer is transitioning from academic projects to real‑world client work. The deliverable should be a standalone guide of approximately 300 words, written in an approachable yet professional tone, and organized into three sections: (1) an overview of the junior designer’s primary role and key responsibilities, (2) the main objectives they should achieve in the first six months, and (3) a step‑by‑step plan outlining daily, weekly, and monthly actions to meet those objectives. Quality criteria: - Clear, specific actions that a junior designer can follow without additional explanation. - Language that balances professional terminology with brief definitions for any specialized terms. - A friendly, supportive voice that encourages self‑reflection and continuous improvement. Exclude any references to company‑specific tools, processes, or branding unless the user provides them. If any essential details (e.g., design discipline, team size, preferred tools) are missing, state your assumptions and ask up to three clarifying questions before finalizing the guide. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Runbook for a production incident 89
You are an experienced Site Reliability Engineer tasked with creating a concise, actionable runbook for responding to a production incident. Your purpose is to equip the on-call team with a clear, step-by-step guide that enables rapid detection, containment, resolution, and post-mortem documentation of critical service disruptions. Assume a typical incident where a core service becomes unavailable or exhibits severe latency, affecting end-users and downstream systems. The runbook should result in a fully documented response process that restores service, communicates status to stakeholders, and captures lessons learned for future improvement. Develop the runbook in the following order: 1. **Define the role** of the on-call responder, including required permissions and primary responsibilities. 2. **State the objective** of the incident response: restore normal service operation within the agreed Service Level Objective (SLO) while maintaining data integrity and clear stakeholder communication. 3. **Describe the scenario**: a production outage of the [SYSTEM_NAME: specify the affected service or component] triggered by [ALERT_SOURCE: specify monitoring/alerting system] indicating [ALERT_TYPE: e.g., high error rate, latency spike, service down]. 4. **Outline the expected solution**: identify the root cause, apply the appropriate remediation (e.g., restart service, roll back deployment, adjust configuration), verify service health, and complete incident documentation. 5. **Provide detailed steps** in a numbered list, covering: - Initial alert acknowledgment and verification. - Immediate communication to the incident channel and affected stakeholders. - Diagnostic commands or queries to gather logs, metrics, and traces. - Decision points for escalation to [ESCALATION_CONTACT: specify role or team] if the issue cannot be resolved within [ESCALATION_TIME: specify timeframe]. - Execution of the remediation action(s). - Validation of service restoration and monitoring for regression. - Post-incident reporting, including root-cause analysis, timeline, and action items. The runbook must be under 1050 words, formatted in plain text with clear headings and a numbered step list. Ensure each step is actionable, includes any required command snippets or configuration edits, and references the appropriate contact or tool. Do not include any information beyond what is specified; if any critical detail is missing, state the assumption made and proceed accordingly. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
Scenario exercise for sales training 91
You are a sales training designer. Create a scenario‑based exercise for a sales training session that guides participants through a realistic sales interaction and leads them to demonstrate the desired selling skills. The exercise should be organized as follows: 1. Define the participant’s role in the exercise (e.g., “You are a junior account executive”). 2. State the learning objective the exercise is intended to achieve (e.g., “Practice consultative questioning to uncover client needs”). 3. Present a concise, vivid scenario that sets the context, including the customer profile, product or service being sold, and any relevant constraints. 4. Describe the solution the participant is expected to arrive at (e.g., “Identify three key pain points and propose a tailored value proposition”). 5. List the step‑by‑step actions the participant should take to move from the scenario to the expected solution, using clear verbs and measurable checkpoints. The output must be a single markdown document, no longer than **350 words**. Include a brief “Instructions for the facilitator” section (max 50 words) that explains how to run the exercise and debrief. Quality criteria: - The scenario is specific, plausible, and relevant to a sales environment. - The steps are actionable, ordered logically, and allow the learner to demonstrate the objective. - Language is clear, professional, and free of unnecessary jargon. Exclude any references to the underlying framework or its component names. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the exercise. [AUDIENCE LEVEL]: specify the experience level of the sales trainees (e.g., entry‑level, mid‑career). [PRODUCT OR SERVICE]: specify what is being sold. [CUSTOMER TYPE]: specify the industry or segment of the fictional customer. [SESSION DURATION]: specify how much time the facilitator has for the exercise.
Internal guide to running a retrospective 87
You are an experienced agile coach tasked with creating an internal guide that teaches team members how to run a retrospective meeting effectively. The guide should enable any team within the organization to understand the purpose of retrospectives, prepare for them, facilitate the session, capture actionable insights, and follow up on improvements. Assume the guide will be used by a cross‑functional team that meets regularly for sprint retrospectives, but the specific team size, product area, and meeting cadence are unknown. Include placeholders for these details: [TEAM SIZE: number of participants] [PRODUCT AREA: brief description of the work] [RETROSPECTIVE FREQUENCY: e.g., weekly, bi‑weekly] The expected deliverable is a concise, well‑structured internal guide written in clear, professional language. It should be approximately 800 words, organized with headings and sub‑headings, and include bullet‑point checklists where appropriate. Quality criteria: 1. Clarity – each step is described in plain language with no ambiguous terms. 2. Actionability – the guide provides concrete actions, templates, or prompts that readers can use immediately. 3. Consistency – terminology and formatting are uniform throughout the document. Do not reference external frameworks, tools, or sources beyond the internal process. If any of the placeholders above are unclear, state your assumptions explicitly and ask up to three clarifying questions before finalizing the guide. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.
Study plan for learning SQL 96
You are an instructional designer specializing in technical skill development. Your task is to create a concise, self‑contained study plan that guides a learner from no prior SQL experience to proficiency sufficient for building and querying relational databases. The plan will be used by an individual who wants to study independently, allocating roughly [STUDY HOURS PER WEEK: specify the weekly time commitment] and aiming to complete the curriculum in [TOTAL DURATION: specify the overall timeframe, e.g., 8 weeks]. Deliver a study plan of approximately 300 words, organized as a clear sequence of weekly modules. Each module should list: - Core learning objectives (what the learner will be able to do). - Key topics or concepts to cover. - Recommended resources (books, online tutorials, videos, or interactive platforms). - Practical exercises or mini‑projects to reinforce learning. Quality criteria: 1. Content is accurate, up‑to‑date, and reflects widely accepted SQL standards. 2. The progression is logical, building on prior knowledge without gaps. 3. Resources are freely accessible or have clear free trial options. Exclude any advanced topics such as performance tuning, query optimization, or database administration beyond basic CRUD operations. If any of the above details are unclear, state your assumptions explicitly and ask up to three clarifying questions before finalizing the study plan. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Scores range from 84 to 96. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.
ROSES vs the Alternatives
The better choice for reference documentation. CLEAR explains a subject; ROSES walks a learner through one situation. Documentation is looked up, training is worked through.
Faster, and right when the output is a document rather than a lesson. RACE has no Scenario or Expected Solution — the two slots that make ROSES a teaching framework.
Superficially similar and aimed the other way. STAR recounts what someone DID; ROSES prescribes what someone SHOULD do. Past tense versus instructional.
Use SCQA when the answer is contested and you are arguing for it. ROSES assumes the answer is settled and teaches it.
A coverage checklist rather than a teaching structure. Useful for making sure a runbook omits nothing; ROSES for making it followable.
Five Ways People Get ROSES Wrong
The defining ROSES failure. "Handle it appropriately" throws away the only slot that makes this framework different, and the model goes back to guessing your policy.
A clean case teaches nothing, because nobody gets those wrong. Choose the situation that produces the actual mistake — and put the awkward detail in explicitly.
"Understand the refund policy" cannot be tested. Write what the learner will be able to DO, including where they must stop.
Role has two halves and the second is the one that changes the material. Prior experience, specifically: what they have done before and what they have never seen.
Training prompts invite fabricated reason codes, screen names and policy clauses, and fabricated training is worse than none. Ban it, and supply the real ones.
ROSES Questions
What does ROSES stand for?
Role, Objective, Scenario, Expected Solution, Steps. Five slots aimed at teaching material.
Why do I have to supply the answer?
Because in training the answer is not in doubt — the reasoning is the deliverable. Stating the Expected Solution also removes the model’s licence to invent policy, which is the most common way generated training material becomes actively harmful.
What if I do not know the expected solution?
Then ROSES is the wrong framework and you are writing a decision aid rather than a lesson. Use SCQA if you are making a case, or ReAct if you want the model to reason it out.
Who created ROSES?
No documented author. It is a modern prompt-engineering acronym, though its shape comes from scenario-based instructional design, which predates it by decades.
How is ROSES different from STAR?
Direction. STAR recounts something that already happened, in the past tense, to evidence a contribution. ROSES prescribes what someone should do in a situation they will meet.
Why does the worked example score 96?
Because ROSES has five concrete slots that happen to align with most of what the scorer measures — Scenario fills context, Steps fills format, and a fenced sample step fills examples. It is the highest of any worked example on these pages.
Generate a ROSES Prompt Instantly
Skip the manual template — Frompting applies ROSES to your topic in one click.
Try it FreeFramework Details
| Name | ROSES |
| Stands for | Role-Objective-Scenario-Expected Solution-Steps |
| Domain | People & Teams |
| Steps | 5 |
| Access | Free |