The best prompts aren’t the longest or the shortest. They’re the ones that include exactly what’s needed.
In the GPT-5.5 era, a complete prompt typically contains seven components: role definition, task objective, context, tool rules, opening behavior, stop conditions, and output format. But not every task needs all seven. Knowing when to leave something out matters more than knowing how to write it.
The Seven-Part Framework
| Component | Purpose | Required/Optional | Common Mistakes |
|---|---|---|---|
| Role Definition | Set identity and capability boundaries | Optional | Generic “you are an expert” statements |
| Task Objective | Define what needs to be accomplished | Required | Vague goals or multiple objectives mixed together |
| Context | Provide background information | Situational | Dumping irrelevant information |
| Tool Rules | Define available tools and usage rules | Required when tools exist | Unclear guidance on when to use which tool |
| Opening Behavior | Control the first response | Optional | Letting the model ask unnecessary questions before acting |
| Stop Conditions | Define when to stop | Required for complex tasks | Missing stop conditions causing infinite loops |
| Output Format | Specify output structure | Situational | Overly rigid formatting requirements |
Let’s break down each component.
Part One: Role Definition
Purpose: Set the AI’s identity and capability boundaries, but not to have it “play expert.”
Good example:
You are a code review assistant focused on identifying security vulnerabilities and performance issues. You do not rewrite code. You only identify problems and suggest fixes.
Bad example:
You are a senior developer with 10 years of experience, proficient in various programming languages and frameworks.
The difference: The good example defines capability boundaries (review only, no rewriting). The bad example just piles on adjectives.
One-line principle: Role definition is about drawing boundaries, not bragging.
When to skip it: If the task is already clear and doesn’t need special identity framing, you can skip this. “Summarize this article” doesn’t need a role definition.
Part Two: Task Objective
Purpose: Clarify what needs to be accomplished. This is the only component you can’t skip.
Good example:
Task objective: Extract 3 key risk factors from this financial report, with each risk backed by specific data.
Bad example:
Please analyze this financial report, tell me what problems exist, also check for investment opportunities, and summarize management’s attitude.
The difference: The good example has one clear objective. The bad example mixes three different tasks together.
One-line principle: One prompt solves one core problem.
When to split: If you find yourself writing “also” or “while you’re at it,” you’re stuffing multiple tasks together. Split them into separate prompts.
Part Three: Context
Purpose: Provide background information to help the model understand the specific scenario.
Good example:
Background: This is an internal document for a technical team. Readers already understand basic concepts, so no need to explain terminology.
Bad example:
Background: Our company is a SaaS startup with 20 people, our main customers are SMBs, we use React + Node.js, and we’re currently building a new feature…
The difference: The good example provides only relevant information. The bad example dumps unrelated details.
One-line principle: Only provide information that affects the output. Everything else is noise.
When to skip it: If the task doesn’t depend on a specific scenario, you don’t need context. “Convert this code to Python” doesn’t need your company background.
Part Four: Tool Rules
Purpose: Define available tools and usage rules. This is a new addition in the Agent era.
Good example:
Available tools:
– search_web: Search for current information, prioritize for time-sensitive questions
– read_file: Read local files, use when referencing existing materials
Usage rules:
– If the question can be answered with existing files, prioritize read_file
– If you need current data, use search_web
– Don’t use tools just to use them
Bad example:
You can use search, read files, write files, and other tools.
The difference: The good example clarifies when to use which tool. The bad example just lists features.
One-line principle: Tool rules are decision trees, not feature lists.
When you must write this: Whenever your prompt involves tool calls, you must clarify usage rules. Otherwise the model will misuse or avoid them.
Part Five: Opening Behavior
Purpose: Control the model’s first response to avoid it asking a bunch of questions before starting work.
Good example:
Opening behavior: Begin the analysis immediately. Don’t ask me what format I need or what specific requirements I have.
Bad example:
Please confirm my requirements first, then start working.
The difference: The good example makes the model start immediately. The bad example triggers a “confirmation loop.”
One-line principle: Unless you need the model to ask questions first, make it start immediately.
When to skip it: Most of the time you can skip this. Only add it when you notice the model consistently asking questions before acting.
Part Six: Stop Conditions
Purpose: Define when to stop, avoiding infinite loops or premature stopping.
Good example:
Stop conditions:
– Success: Stop after finding 3 cases that meet the criteria
– Failure: If 5 searches yield no qualifying cases, report current progress and explain why
– Exception: If you encounter inaccessible resources, skip and continue
Bad example:
Stop when the task is complete.
The difference: The good example defines three stop scenarios (success/failure/exception). The bad example says nothing useful.
One-line principle: Stop conditions should cover success, failure, and exception scenarios.
When you must write this: Any task involving search, loops, or multiple steps must have clear stop conditions.
Part Seven: Output Format
Purpose: Specify output structure, but don’t over-constrain it.
Good example:
Output format:
– Use Markdown
– Each risk factor in its own paragraph
– Present data in tables
Bad example:
Output format must strictly follow this template:
[Risk 1]: XXX
[Data Support]: XXX
[Impact Level]: XXX
…
The difference: The good example provides structural guidance. The bad example provides a rigid template.
One-line principle: Format is for readability, not for constraining the model.
When to skip it: If you have no special formatting requirements, you don’t need to write this.
Combination Strategies: When to Use Which Parts
Minimal prompt (task objective only):
Summarize the core arguments of this article.
Use case: Simple, clear tasks that don’t need special handling.
Standard prompt (task objective + stop conditions + output format):
Task objective: Extract 3 key data points from this report.
Stop conditions: Stop after finding 3.
Output format: Present in a table.
Use case: Most everyday tasks.
Complete prompt (all seven parts):
Role definition: You are a data analysis assistant.
Task objective: Find 3 data points supporting “AI is transforming education.”
Context: This is a report for investors, requiring authoritative data.
Tool rules: Prioritize search_web for current data.
Opening behavior: Start searching immediately, don’t ask what type of data I want.
Stop conditions: Stop after finding 3 data points from authoritative sources. If 5 searches yield nothing, report your findings.
Output format: Each data point includes source, date, and specific value.
Use case: Complex agent tasks involving multiple steps, multiple tools, and multiple decision points.
Self-Check List
– Is the task objective clear and singular?
– If tools are involved, are usage rules clearly defined?
– If the task is complex, are stop conditions defined?
– Is the role definition actually necessary? (Usually it’s not)
– Does the context contain only relevant information?
– Does the output format over-constrain the model?
The seven-part structure isn’t dogma. It’s a checklist. Every time you write a prompt, run through these seven parts and ask yourself: “Do I need this part?” If yes, write it. If no, skip it.
The essence of prompt engineering is achieving the clearest objective with the fewest constraints.
Stay updated with our latest AI insights
