What is the GUIDE Framework?
GUIDE is a structured prompt engineering framework built around the metaphor of consulting an expert advisor. The acronym stands for Goal, Understanding, Information, Direction, and Evaluation — five components that together produce prompts optimized for teaching, consulting, and complex advisory tasks.
- G — Goal: Define what you want to achieve
- U — Understanding: Calibrate the model's knowledge baseline
- I — Information: Supply the raw material
- D — Direction: Specify the approach and structure
- E — Evaluation: Set the success criterion
What sets GUIDE apart from other structured frameworks is its closing component: Evaluation. Instead of ending when the model delivers an answer, GUIDE asks the model to measure that answer against a defined success criterion. This self-evaluation loop dramatically improves output quality by making the standard of success explicit from the start.
GUIDE is particularly powerful when you are not just looking for information but for guidance — when you want the model to think with you, not just respond to you. Its Direction component also gives you precise control over the model's approach, preventing it from defaulting to a generic answer structure when a specific one would serve you better.
When to Use the GUIDE Framework
Teaching & Tutoring
Set a learning goal, share the student's current understanding, provide source material, and define what mastery looks like — the model becomes a structured tutor.
Consulting & Advisory
Brief the model like an external consultant: your goal, the context, the data you have, and how you need the advice structured.
Technical Documentation
Supply raw technical information and direct the model to produce documentation for a specific audience, evaluated against readability criteria.
Business Planning
Define a business goal, share market information, and direct the model to build a plan — with Evaluation ensuring the output is actionable and complete.
Performance Optimization
Describe a performance problem, share diagnostics, and direct the model to prioritize solutions — evaluated by whether a developer can implement them in a given timeframe.
Hiring & Recruitment
Write job descriptions, craft interview questions, or evaluate candidate profiles against a defined hiring goal with explicit success criteria.
How to Use the GUIDE Framework
- 1
Goal — Define what you want to achieve
State the end result you are looking for in concrete terms. Be specific about the outcome, not just the activity. "Help me write a job description" is weaker than "Help me write a job description that attracts senior PMs and filters out junior candidates."
- 2
Understanding — Calibrate the model's knowledge baseline
Share your relevant experience, expertise level, and any prior attempts. Also signal what the model can assume and what it should not. This prevents both over-explanation and under-explanation in the response.
- 3
Information — Supply the raw material
Provide everything the model needs to work with: data, documents, code, specifications, constraints. The richer and more accurate this section, the more grounded and actionable the model's guidance will be.
- 4
Direction — Specify the approach and structure
Tell the model how to tackle the problem, not just what to produce. Define the sequence, the angle, the format, and any methodological preferences. This is where you prevent generic, formulaic responses.
- 5
Evaluation — Set the success criterion
Describe what a successful response looks like from your perspective. Frame it as a test: "A good answer will allow X person to do Y without needing Z." The model uses this to self-assess and calibrate its output before presenting it.
Prompt Examples
Goal: Help me write a compelling job description for a Senior Product Manager role at a Series B fintech startup that attracts experienced candidates without over-filtering. Understanding: I am a non-technical founder with limited HR experience. I know what the role needs to do functionally, but I struggle to write copy that resonates with strong PM candidates. The company values autonomy, data-driven decision making, and cross-functional collaboration. Information: The role owns the core payments product. The team is 4 engineers and 1 designer. The PM will report directly to me. Salary range is $160k–$185k with meaningful equity. We are fully remote with quarterly in-person sprints. Direction: First, identify what top PM candidates look for in a job description. Then draft a job description that leads with the mission and opportunity, follows with responsibilities and qualifications, and ends with a clear benefits and culture section. Avoid jargon and buzzwords. Evaluation: The result is successful if a PM with 5+ years of experience would read the description and immediately understand the scope of ownership, the growth opportunity, and whether they are a fit — without needing to ask clarifying questions.
Goal: Advise me on how to reduce the cold-start latency of a Python AWS Lambda function from ~3 seconds to under 800ms. Understanding: I am a backend developer with 3 years of Python experience and 1 year of AWS Lambda experience. I understand the concept of cold starts but have not profiled my function to know which layer is the slowest. The function uses SQLAlchemy, Pandas, and a custom internal library. Information: The Lambda is configured with 512MB RAM, Python 3.11 runtime, deployed as a zip package (current size: 48MB). It connects to an RDS PostgreSQL instance via a connection pool. Cold starts happen for approximately 15% of invocations in production. Direction: Start by identifying the most common root causes of cold-start latency for Python Lambdas of this type. Then provide a prioritized list of optimizations, starting with the highest-impact, lowest-effort changes. Include specific configuration values or code patterns where applicable. Evaluation: A good answer will give me a clear action plan I can implement in one sprint (5 business days), with each recommendation including an expected latency improvement in milliseconds or a percentage range.
Pros and Cons
| 🟢 Pros | 🔴 Cons |
|---|---|
| Evaluation component makes success criteria explicit and improves output quality | Five components require meaningful upfront investment per prompt |
| Direction component prevents generic, formulaic responses | Evaluation component is only as useful as the success criteria you write |
| Scales well from simple advisory tasks to complex consulting scenarios | Less suited for quick, factual queries where zero-shot is more efficient |
| Intuitive consultation metaphor accessible to non-technical users |
Frequently Asked Questions
What does GUIDE stand for in prompt engineering?
GUIDE stands for Goal, Understanding, Information, Direction, and Evaluation. It is a five-component framework designed for advisory, teaching, and consulting-style prompts where you want the model to not only answer a question but genuinely guide you toward a well-reasoned outcome.
What makes GUIDE different from other structured frameworks?
GUIDE's defining feature is its Evaluation component, which asks the model to assess whether its own output meets the goal. Most frameworks end at the answer — GUIDE closes the loop by including a success criterion that the model applies to its own response. This makes it especially effective for complex or high-stakes tasks.
What should I write in the 'Direction' component?
Direction tells the model how to approach the task — the method, the sequence of steps, or the angle of attack. For example: 'Start by identifying the root cause, then propose three solutions ranked by cost-effectiveness.' Direction prevents the model from choosing an approach that is valid but not useful to you.
How is 'Understanding' used in GUIDE vs. in QUEST?
In QUEST, Understanding is about providing background context from your perspective. In GUIDE, Understanding also includes what the model's starting knowledge base should be — it calibrates both the context you bring and the knowledge the model should assume or defer on. This makes GUIDE more consultation-focused.
Can I use GUIDE for technical documentation tasks?
Yes. GUIDE works well for documentation when you use the Goal to specify the audience, Information to supply the raw technical details, Direction to set the structure, and Evaluation to define what 'good' documentation looks like (e.g., 'a junior developer should understand every step without prior context').
What goes in the 'Information' component?
Information is the data, facts, or materials the model needs to do the task. This is where you paste in raw data, provide reference documents, share URLs, include code snippets, or supply any other input that the model should process or reason from. It is the raw material for the model's work.
Is GUIDE suitable for non-technical users?
Absolutely. GUIDE is particularly well-suited for non-technical users who need expert-level guidance. The framework's consultation metaphor — briefing an expert advisor — is intuitive. You describe what you want (Goal), what you know (Understanding), what you have (Information), how you want it approached (Direction), and what success looks like (Evaluation).