Try this prompt.
Summarize these meeting notes.
The tool has the notes and can produce a clean recap. It still has to guess which decisions matter, who needs the result, and what should happen next.
I have had versions of this governance discussion with healthcare leaders. The group is deciding what staff should understand before they begin using an approved AI tool and who will own the education. It also needs a way to decide whether people are ready. A general summary can bury those decisions and next steps.
This article assumes you are using an AI tool and workflow your organization has approved, with information it permits for that use.
So what should have been in the request?
Another way to think about a prompt
There are plenty of formulas. RTF uses three parts. CO-STAR uses six. Other frameworks divide the work in other ways.
Their origins vary, and so does the evidence behind them. In an April 2026 preprint, Mayo Clinic researcher David A. Cook synthesized 11 published prompt frameworks and reported that most have obscure origins and none document a scholarly derivation of their parts. For many, the earliest traceable source is a video, blog post, or vendor website. Cook then proposed PICCO, short for Persona, Instructions, Context, Constraints, and Output. His paper offers a taxonomy of prompt-design concepts and a five-element reference architecture for prompt generation. Cook describes it as conceptual and methodological work and says its performance as an optimization method has not been empirically validated.
One detail in his method stuck with me. When Cook asked LLMs to help find frameworks, they produced several additional “state-of-the-art frameworks” that turned out to be hallucinations.
The acronyms still have a practical use. They give people a checklist for information that is easy to leave out.
You can see the overlap in vendor guidance. Microsoft’s current Copilot documentation, updated February 2026, names four parts: the goal, context, expectations, and source.
I rarely write from a template. After working through these frameworks, I landed on three plain questions that fit on a card and are simple to explain:
- What are you trying to get done?
- What context and source should the AI use?
- What would make the answer useful here?
They cover the same ground Microsoft names, with context and source combined. This exact triad remains unvalidated. I use it as a plain-language, workforce-wide starting point for familiar, human-reviewed tasks in an approved tool. It gives people an easy way to think about the outcome, the information the AI should use, and the result they need. More structured frameworks, task-specific training, and local governance still apply where the work calls for them.
Governance sets the boundaries for the tool, permitted information, authoritative sources, and review expectations. The questions give educators a shared way to connect prompt writing with those boundaries.
For teaching, I put the questions in this order because it is easier to follow. The finished request can use whatever order reads naturally. When steps must happen in sequence, say so.
What are you trying to get done?
Name the outcome.
“Summarize these meeting notes” names an activity. “Summarize these meeting notes and create a plan for the next steps” names a result. The second version gives the AI a selection rule that moves decisions ahead of background detail.
When the outcome is hard to name, that is useful information too. The person may still be deciding what the work is.
What context and source should the AI use?
Give the AI enough relevant context to understand the situation and do the task. Include the facts, source material, examples, and constraints that could change the answer.
Context includes what you tell the AI and what the tool can retrieve. That may include an attached file, a connected drive or database, or a resource or search tool made available through a Model Context Protocol (MCP) connection. The application still controls how that connection is used.
For a policy question, the tool needs access to the current policy. I can attach the file or point the AI to an approved connected source.
The prompt can stay simple: “What does our policy say about recording meetings? Use the policy I attached. If you cannot access it, say so.” I still need to confirm that the answer matches the policy.
A peer-reviewed ICLR 2025 study introduced “sufficient context” as a way to separate two failures: the model failing to use good context and the supplied context lacking enough evidence to answer the question. On the open-book question-answering tasks tested, larger models including GPT-4o, Claude 3.5, and Gemini 1.5 Pro often answered incorrectly instead of abstaining when the context was insufficient.
An incomplete source can still produce a fluent answer.
Keep useful background even when it makes the prompt longer. Add or reorganize detail when the first answer exposes a gap or representative testing shows that a change helps.
Use a role when perspective matters
A role can help frame the perspective, vocabulary, and priorities of a response. Name the role, explain how that perspective should shape the conversation or output, and give the AI enough relevant context to understand the situation.
For example: “You are an AI governance leader reviewing this AI policy plan in line with the others. Focus on gaps and open questions.”
A peer-reviewed Findings of EMNLP 2024 study tested 162 personas across 2,410 factual multiple-choice questions and found no average improvement over a no-persona control. The best persona varied unpredictably from question to question. The study placed personas in system prompts and used open-weight models and multiple-choice items, so it does not settle open-ended writing or every current assistant.
What would make the answer useful here?
Describe the output: audience, format, length, tone, constraints, and what a good result looks like. Use the parts that matter and leave the rest out.
Question 3 is about the output and its format. The response check happens after the AI answers.
Specific requirements give the AI a target and give the reviewer something concrete to check. “Start with a short summary, then list the next steps” is a specification you can hold a draft against.
Watch one get built
Here is a composite example.
Start with the weak version.
Summarize these meeting notes.
Name the outcome.
Summarize these meeting notes and create a plan for the next steps.
Add the context and source.
Use the attached meeting notes. If you cannot access them, say so.
Describe what would make the answer useful.
Start with a short summary. Then list the next steps.
Every added sentence answers one of the three questions, and the request still reads like something a busy person would write.
Treat the first response as a draft
Whatever comes back is a first draft. Tell the AI what worked, what is missing, and what should change. Continue the conversation and improve the response one turn at a time.
As you revise, check four things:
- Does each material claim come from the named source, and are proposed recommendations labeled clearly?
- Does the response include every requested element?
- Are missing details marked rather than invented?
- Did any number, qualifier, warning, or decision change?
In this example, a plan that invents a decision or next step fails the check, even if it looks polished.
Cook groups the final AI-led check under self-criticism: asking the LLM to critique its prompt, response, or reasoning path and suggest improvements. For a draft that matters, I add one final follow-up to challenge the answer and my own premise:
Adversarially pressure-test this response. Challenge my assumptions and tell me what you would change.
This is a second pass from the same system, so it can repeat the first answer’s blind spots. I still compare material claims with the named sources and make the judgment myself.
Three places I would use these questions
After an AI governance discussion
Turn meeting notes into a decision summary and next-step plan.
- Goal: Summarize the discussion and identify the next steps.
- Context and source: The meeting notes.
- What makes it useful: A short summary followed by the next steps.
Looking up a policy
Answer a specific question about the organization’s approved use of AI.
- Goal: Answer the policy question.
- Context and source: The current policy, attached or available through an approved connected source.
- What makes it useful: A direct answer. If the AI cannot access the source, it should say so.
Building an AI literacy session
Turn governance priorities into an education outline for people beginning to use an approved AI tool.
- Goal: Prepare a practical introduction to the tool and the organization’s expectations for its use.
- Context and source: The current AI policy, approved use cases, audience roles, and the features available in the tool.
- What makes it useful: Learning goals, a 45-minute agenda, one practice exercise, and questions the governance group still needs to answer.
These examples come from work I can speak to directly in AI governance and education. Each team can apply the same questions to a familiar, approved task from its own work.
When more structure helps
These three questions give the broader workforce a shared starting point. Some roles and use cases need more structured frameworks, role-specific training, tested examples, and clear review steps. Pair the framework with practice in the actual tool and representative cases. That training should match the task and the consequences of getting the answer wrong.
More structure also helps when the task involves several sources, worked examples, dependent steps, required output sections, or a shared template for repeated work.
Breaking the work into smaller tasks is decomposition. When each prompt builds on the output of the one before it, Cook calls that prompt chaining.
Current Anthropic guidance recommends numbered steps when order or completeness matters. It also suggests giving a prompt to a colleague with little context and seeing whether that person can follow it. Confusion in that test is a sign that the request needs more work.
For large documents, the same guidance recommends placing the source material near the top and the specific request after it.
Vendor guidance changes with the model and product. Test representative examples in the tool your team uses before teaching a technique as a rule.
Advanced prompting methods and terminology
Cook draws useful lines between terms that often get mixed together.
Prompt generation is composing a prompt. Cook reserves prompt engineering for deliberate, iterative evaluation and refinement.
A prompt framework is a general blueprint for its structure, and prompt elements are the parts of that framework. A prompting technique is a systematic way to structure or sequence one or more prompts.
I use prompt engineering more broadly in the G4E glossary. There it covers design, testing, versioning, governance, prompt templates, examples, tool instructions, and output schemas. That broader definition fits how a health system manages prompts as operational assets. Cook’s narrower definition helps a team distinguish writing a prompt from testing how well it performs.
Here are several techniques from Cook’s taxonomy, using the governance-meeting example from this article.
- Zero-shot prompting. Give the AI instructions without examples. Cook describes this as a basic prompt made from PICCO elements. For the governance meeting, ask it to extract decisions, owners, and dates without providing a sample summary.
- Few-shot prompting. Include examples of the desired input and output so the AI can follow the pattern. The G4E glossary says “a few” examples; Cook’s definition explicitly begins with one. Provide one or two approved decision summaries, then ask the AI to use the same structure for the new meeting.
- Chain-of-thought prompting. Ask the AI to state an approach or follow a worked reasoning example. Provide one example showing how a decision becomes a next step, then ask the AI to apply that reasoning pattern to the remaining decisions. Treat the explanation as a draft and check it against the source.
- Ensembling. Generate several responses, then select one or combine them into a final response. Produce three candidate summaries, compare what each one missed, and assemble one draft. Responses from the same system can share blind spots.
- Decomposition and prompt chaining. Split a complex task into smaller tasks. A chain passes one result into the next prompt. Extract the decisions first, identify owners and dates next, then create the summary and action plan.
- Self-criticism. Ask the AI to critique its prompt, response, or reasoning path, then use that critique to improve it. Use the pressure-test prompt above, then verify each material change against the notes.
- Meta-prompting. Ask the AI to write or improve the prompt itself. Have it ask about the outcome, sources, and format before drafting the prompt you will use.
Start with zero-shot prompting. Add examples when consistency matters, break apart multistep work, and use critique or multiple drafts when the added review is worth the effort.
These methods can improve fit, consistency, or completeness. Their value depends on the task, model, source material, and review process. For consequential healthcare work, representative testing and human review remain part of the job.
Know which prompt the user controls
The request on the screen is one layer of a deployed system. Vendor or organization instructions, conversation history, attached files, connected databases, MCP resources and tools, templates, permissions, and model settings can also shape the result.
In an embedded healthcare workflow, a user may have little access to those other layers. Before you build prompt training, confirm what the user can type, attach, retrieve, save, or change. Aim the training at controls they can use.
Let the AI help you write the prompt
Cook calls this meta-prompting: asking an LLM to write or improve a prompt. The AI can help you build a detailed request.
Help me write a prompt for [task]. Ask me about the outcome, context, sources, and useful format. Then draft a prompt I can review.
Review what it produces. Cut details the task does not need, correct its assumptions, and adjust the structure before you run it.
Once I have a prompt, I add one line at the end when a missing detail could change the result:
Before you answer, ask any questions you need to clarify the task. If your tool has a structured question feature, use it.
The line encourages clarification. The model still decides whether it has enough information. Claude Code calls its built-in tool AskUserQuestion; other interfaces may ask through the regular conversation.
After you see the answer, use a follow-up to close a visible gap.
Put the first two actions in order of impact and mark missing owners as “TBD.”
How I would use this in an AI literacy discussion
I would start with one approved tool and one familiar task from the group’s own work.
The three questions would go on a card:
- What am I trying to get done?
- What context and source should the AI use?
- What would make the answer useful here?
For the next 30 minutes, I would have the group write the vague version first and inspect what the model guessed. Together, we would build the improved request one question at a time, use the four response checks above, and revise one visible gap.
Then the group would run the final prompt across several representative examples, because one polished answer proves very little.
I use the same response-check habit in the SIGN Method, where Instruct is the action this article expands and Ground catches what Instruct misses.
Prompt writing belongs inside a broader push on healthcare AI literacy.
Prompting keeps changing as the models and products change, so this should stay an open discussion. If you try these questions in workforce education, I would love to hear what makes sense, what creates confusion, and what you would change.
If you are working through AI adoption at a health system and want to talk it through, schedule a call or connect with me on LinkedIn.
Frequently Asked Questions
What do RTF, CO-STAR, CRISPE, and RISEN stand for?
Using the versions documented in Buffalo State’s RTF guide and Cook’s 2026 cross-framework synthesis:
- RTF: Role, Task, and Format.
- CO-STAR: Context, Objective, Style, Tone, Audience, and Response.
- CRISPE: Capacity and Role, Insight, Statement, Personality, and Experiment.
- RISEN: Role, Instructions, Steps, End goal, and Narrowing constraints.
These frameworks and the three questions here are alternative memory aids. Test the structure you choose on representative work in your actual tool.
What is the PICCO framework, and how does it relate to these three questions?
PICCO stands for Persona, Instructions, Context, Constraints, and Output. In the April 2026 preprint The PICCO Framework for Large Language Model Prompting: A Taxonomy and Reference Architecture for Prompt Structure, David A. Cook proposes it as a five-part reference architecture derived from a search and synthesis of 11 published prompt frameworks. The paper also separates prompt frameworks, prompt elements, prompt generation, prompting techniques, and prompt engineering. It covers implementation topics including iterative prompt engineering, self-critique, security, privacy, bias, and trust.
PICCO offers a broader map for people who want a detailed framework. The three questions here are a general workforce starting point. Goal and outcome map most closely to Instructions. The context and source question can hold Persona and Context, plus Constraints on sources, privacy, or policy. Format and output map to Output and other task-specific Constraints. The mapping is approximate because the two frameworks were built for different purposes.
Cook describes PICCO as conceptual and methodological work and says it has not been empirically validated as an optimization method. It is a single-author preprint, and only three of the 11 source frameworks came from peer-reviewed literature. Test it on representative work in the tool your organization uses.
Does the order of a prompt matter?
For short requests, the three questions work as a thinking sequence and the finished prompt can read naturally. Use numbered steps when actions must happen in order. With large documents, Anthropic recommends putting the source material before the specific request.
Does telling the AI to “act as an expert” make it more accurate?
A role can help when perspective is what you need. Name the role, explain how that perspective should frame the conversation or output, and provide enough relevant context and source material for the AI to understand the situation. The peer-reviewed study described above found no average factual-accuracy gain from personas in the tasks it tested. Use sources and review for factual support.
How much context should I include?
Give the AI enough relevant context to understand the situation and answer the question. That includes what you provide in the prompt and what the tool can retrieve from attached files, connected databases, or resources and tools available through MCP and other integrations. Name the source you want it to use. For a policy question, tell the AI which current policy to use and ask it to say when it cannot access the source.
Does better prompting reduce the need to check the output?
Clearer instructions improve how well a draft fits the request. Factual accuracy, policy interpretation, source support, and decisions still require review before anyone relies on the result.
References
| Source | What it supports |
|---|---|
| Cook, The PICCO Framework for Large Language Model Prompting, arXiv preprint, April 2026 | Synthesis of 11 published frameworks; the element lists for CO-STAR, CRISPE, and RISEN; PICCO's five-part reference architecture; distinctions among prompt generation, prompt frameworks, prompt elements, prompting techniques, and prompt engineering; definitions and examples of advanced prompting methods; implementation and responsible-prompting topics; the obscure origins of most frameworks; the hallucinated frameworks the LLM-assisted search produced; and the author's statement that PICCO is not empirically validated. Single-author preprint, not peer reviewed. |
| Microsoft, Get started writing prompts in Microsoft 365 Copilot, updated February 2026 | A vendor's plain-language prompt model naming four parts: goal, context, expectations, and source. Used to show the overlap with the three questions. |
| Joren et al., Sufficient Context: A New Lens on Retrieval Augmented Generation Systems, ICLR 2025 | Peer-reviewed study distinguishing model-use failure from insufficient retrieved context in open-book question answering. Supports the warning that models may answer incorrectly instead of abstaining when context is insufficient. |
| Zheng et al., When “A Helpful Assistant” Is Not Really Helpful, Findings of EMNLP 2024 | Peer-reviewed study of 162 personas across 2,410 factual questions, finding no average gain over a no-persona control and difficult-to-predict role effects within the study's scope. |
| Anthropic, Prompting best practices, accessed August 29, 2026; Claude Code tools reference, accessed August 30, 2026 | Numbered steps when order or completeness matters, a human clarity test, placing long source material above the question, and Claude Code's built-in tool for gathering requirements or clarifying ambiguity. |
| Model Context Protocol, Architecture overview, accessed August 30, 2026 | Official documentation explaining that MCP servers can expose tools and contextual resources to AI applications, while the application controls how the provided context is managed and used. |

