GPT-5 Prompting Guide — Important Takeaways

TL;DR

The strongest GPT-5 prompts generally do these things:

1. Clearly define the outcome.

2. Tell the model how autonomous it should be.

3. Define when to research and when to stop researching.

4. Avoid contradictory instructions.

5. Give coding/design standards rather than micromanaging implementation.

6. Tell the agent to finish the whole task, not stop halfway.

7. Require verification after implementation.

8. Keep user-facing explanations concise while allowing detailed code.

9. Prefer acting over asking unnecessary clarification questions.

10. Iterate on prompts based on observed bad behaviour.

1. Control How Autonomous the Agent Should Be

One of the most important prompt controls is agentic eagerness.

You should explicitly decide whether the agent should:

• investigate deeply,

• act quickly,

• ask questions,

• make reasonable assumptions,

• or continue until the task is completely finished.

For coding agents, a strong default is:

Bias toward solving the problem yourself rather than asking the user for information you can discover from the codebase.

For longer tasks:

Keep going until the user's request is completely resolved. Do not stop after completing only part of the task.

Good default

<persistence> Keep going until the user's request is completely resolved. Do not stop when encountering uncertainty if the answer can reasonably be discovered from the repository, tools, documentation, or context. Make reasonable assumptions where necessary and document them. Avoid asking the user to approve a plan before implementing it when the changes can safely be reviewed or reverted afterward. </persistence>

2. Put Boundaries Around Research

GPT-5 naturally likes gathering context.

Telling it simply to:

Be extremely thorough.

can actually make it worse by causing unnecessary searching and tool calls.

Instead, describe how much context is enough.

A good pattern is:

<context_gathering> Start broad, then investigate the most likely areas. Search in parallel where possible. Stop gathering context when: - the relevant files/functions have been identified, - the likely root cause is understood, - and there is enough information to implement the change. Search again only if implementation or validation exposes a new unknown. Prefer acting over repeatedly searching. </context_gathering>

The key idea:

Give the model a stopping condition.

3. Prefer Targeted Context Over Maximum Context

Avoid instructions like:

Make sure you understand absolutely everything before proceeding.

Instead use:

Understand the parts of the system relevant to this task. Trace dependencies that affect the implementation, but avoid exploring unrelated parts of the codebase.

This prevents the agent from wandering through a large repository.

4. Explicitly Tell the Agent to Finish the Whole Task

Agents can sometimes solve the first obvious part and stop.

A useful instruction is:

<completion> Decompose the request into all required sub-tasks. Before finishing, verify that every requested item has been completed. Do not return after completing only the first part of a multi-part request. </completion>

This is especially useful for prompts containing phrases such as:

• implement X

• update Y

• migrate Z

• add tests

• update documentation

• verify everything works

5. Avoid Contradictory Instructions

GPT-5 follows instructions very precisely.

That means contradictions hurt more than they might with older models.

For example, avoid simultaneously saying:

Never make changes without asking. Do not ask for confirmation; implement changes immediately.

Or:

Always inspect the user record first. For emergencies, respond immediately before doing anything else.

Instead define the exception explicitly:

Inspect the user record before taking action, except in emergency situations where immediate safety guidance takes priority.

Rule of thumb

Before using a large system prompt, check for:

• conflicting rules,

• overlapping instructions,

• unclear priority,

• duplicate rules with slightly different wording,

• absolute rules that actually have exceptions.

6. Tell Coding Agents to Fix Root Causes

One of the strongest coding instructions in the guide is essentially:

Fix the problem at the root cause rather than applying surface-level patches.

A good coding rule set:

<engineering_principles> - Fix root causes rather than symptoms. - Keep changes focused on the requested task. - Avoid unnecessary complexity. - Follow existing architecture and conventions. - Prefer readable, maintainable code. - Reuse existing components and abstractions where appropriate. - Do not refactor unrelated code. </engineering_principles>

7. Make New Code Blend Into the Existing Codebase

Instead of telling the model exactly how to implement something, tell it to first understand the project's conventions.

It should inspect things like:

• nearby implementations,

• directory structure,

• existing components,

• package dependencies,

• naming conventions,

• architecture,

• tests,

• formatting/linting rules.

Then:

Make the new implementation look like it was written by the existing team.

This is usually more effective than specifying every implementation detail yourself.

8. Give Design Principles, Not Just Feature Requirements

For frontend work, GPT-5 performs better when you describe the quality bar.

For example:

<ui_principles> - Maintain strong visual hierarchy. - Keep spacing consistent. - Reuse existing design-system components. - Avoid unnecessary visual complexity. - Support loading, empty, error and success states. - Preserve accessibility. - Make interactive elements visually identifiable. - Ensure responsive behaviour. </ui_principles>

This gives the agent freedom while keeping its implementation aligned with your expectations.

9. Separate Concise Communication From Detailed Code

Cursor found an interesting balance:

Low verbosity for conversation. High clarity/detail for code.

A useful instruction:

Keep progress updates and the final explanation concise. When writing code, prioritize clarity and maintainability. Use descriptive names and straightforward control flow. Avoid compressed or clever code purely for brevity.

This prevents:

• huge conversational explanations,

• while also preventing overly terse generated code.

10. Encourage Proactive Implementation

For code-editing environments where changes are reviewable/reversible, agents should usually implement rather than ask permission to implement.

Instead of:

I found the issue. Would you like me to fix it?

Prefer:

I found the issue, implemented the fix, and verified it. Here is what changed.

A useful instruction:

When the requested change is clear and reversible, implement it rather than asking whether to proceed. Ask for clarification only when a material product or business decision cannot reasonably be inferred.

This can significantly improve coding-agent workflows.

11. Verification Should Be Part of the Prompt

Do not treat implementation as completion.

Tell the model explicitly to validate its work.

<verification> After making changes: - run the most relevant tests, - run lint/type checks where appropriate, - inspect the resulting diff, - check for accidental unrelated changes, - verify edge cases related to the change, - confirm the requested behaviour works. Do not consider the task complete until reasonable verification has passed. </verification>

For repository work, inspecting git diff and git status is especially valuable.

12. Don't Make the Agent Fix Everything It Finds

A useful boundary:

Ignore unrelated bugs, failing tests, or cleanup opportunities unless they prevent the requested task from being completed.

Without this, coding agents can turn a small task into a large refactor.

13. Use Structured Prompt Sections

The Cursor experiments found structured sections useful for instruction adherence.

XML-style blocks work particularly well:

<context> ... </context> <objective> ... </objective> <engineering_principles> ... </engineering_principles> <exploration> ... </exploration> <implementation> ... </implementation> <verification> ... </verification> <completion> ... </completion>

The XML itself isn't magical.

The benefit is that instructions become clearly separated and scoped.

14. Define Tool Behaviour Explicitly

For tool-using agents, specify:

• what tools are available,

• when they should be used,

• what requires confirmation,

• what actions are reversible,

• what actions are dangerous,

• when the model should stop searching.

For example:

Read/search operations may be performed proactively. Reversible code edits may also be performed proactively. Potentially destructive or irreversible actions require a much higher confidence threshold.

Different tools should have different levels of caution.

Searching a repository is low-risk.

Deleting production data is not.

15. Give Progress Updates During Long Tasks

For longer agent runs, brief updates improve the experience.

A good pattern:

Before starting a long task, briefly state the intended approach. During execution, provide occasional concise updates when meaningful progress has been made. Avoid narrating every individual tool call. At the end, summarize: - what changed, - what was verified, - and any remaining limitations.

This gives transparency without excessive chatter.

16. Reasoning Effort Should Match the Task

Not every request needs maximum reasoning.

Use lower reasoning for:

• simple transformations,

• obvious code edits,

• straightforward lookups,

• repetitive tasks.

Use higher reasoning for:

• architecture,

• debugging unclear problems,

• multi-file refactors,

• ambiguous requirements,

• migrations,

• complex dependency changes.

More reasoning is not automatically better.

17. For Low-Reasoning Models, Prompt Structure Matters More

When using minimal reasoning, explicitly provide:

• planning instructions,

• persistence instructions,

• tool rules,

• completion criteria,

• verification requirements.

The less internal reasoning budget the model has, the more useful a clear workflow becomes.

18. Self-Review Can Improve One-Shot Generation

For greenfield work, the guide suggests having the model internally establish a quality rubric.

For example:

<self_review> Before implementing, establish an internal quality rubric covering the most important aspects of the requested application. Use it to review the implementation before finishing. If an important area is clearly below the expected quality bar, improve it before returning the result. </self_review>

This can be useful for:

• new applications,

• UI generation,

• prototypes,

• landing pages,

• architecture designs.

Less useful for tiny fixes.

19. Use the Model to Improve Its Own Prompt

One of the most useful techniques in the guide is metaprompting.

When an agent repeatedly behaves badly, give the model:

1. the current prompt,

2. the desired behaviour,

3. the undesired behaviour.

Then ask:

What minimal changes to this prompt would make the desired behaviour more consistent while preserving as much of the existing prompt as possible?

This is much better than continuously adding random rules.

20. The Best General Coding-Agent Prompt Pattern

A strong reusable structure is:

<objective> Clearly describe the desired outcome. </objective> <persistence> Continue until the complete request has been resolved. Avoid unnecessary clarification questions. Make reasonable assumptions when they can be validated. </persistence> <context_gathering> Investigate the relevant parts of the repository. Start broad and narrow quickly. Do not explore unrelated code. Stop researching once implementation can safely begin. </context_gathering> <engineering_principles> Fix root causes. Keep changes focused. Follow existing conventions. Prefer simple, readable and maintainable code. Avoid unrelated refactoring. </engineering_principles> <implementation> Implement the requested behaviour proactively. Reuse existing abstractions where appropriate. Handle relevant edge cases. </implementation> <verification> Run relevant tests and checks. Inspect the diff. Verify the requested behaviour. Ensure no unintended changes were introduced. </verification> <communication> Keep progress updates concise. Do not narrate every tool call. At completion summarize what changed and what was verified. </communication>

The 8 Rules Worth Remembering

If you remember nothing else from the guide, remember these:

1. Tell the model what done means.

2. Tell it how autonomous it should be.

3. Give research stopping conditions.

4. Remove contradictory instructions.

5. Tell coding agents to follow the existing codebase.

6. Prefer root-cause fixes over patches.

7. Require verification before declaring completion.

8. Prefer proactive implementation over unnecessary questions.

The Biggest Prompting Mistake

Probably the most important lesson from the whole guide:

Do not keep adding instructions telling GPT-5 to be more thorough.

GPT-5 is already naturally thorough.

Overdoing instructions like:

• be extremely thorough,

• investigate everything,

• understand the full codebase,

• search extensively,

• double-check absolutely everything,

can make the agent slower, more verbose and more likely to overuse tools.

Instead tell it:

Investigate enough to confidently act, then act.

That is a much better default philosophy for GPT-5-style coding agents.