Prompting GPT-5.6 for Agentic Work

This skill distills OpenAI's official GPT-5.6 usage and prompting guides into an operating procedure for writing agent prompts. GPT-5.6 rewards lean, outcome-first prompts: OpenAI's internal evaluations found leaner system prompts improved scores by roughly 10–15% while cutting total tokens 41–66% and costs 33–67%. The family is gpt-5.6-sol (flagship), gpt-5.6-terra (balanced), gpt-5.6-luna (efficient high-volume); the gpt-5.6 alias routes to sol.

When to use

Use this skill when you are:

• Writing or revising a system/developer prompt for any GPT-5.6 model doing multi-step or tool-using work.
• Migrating an agent from GPT-5.5 or GPT-5.4 to GPT-5.6.
• Deciding whether to enable Programmatic Tool Calling (PTC), multi-agent (beta), pro mode, or persisted reasoning — and how to prompt for them.
• Tuning reasoning.effort, text.verbosity, or approval/stopping behavior.
• Debugging a GPT-5.6 agent that over-asks for confirmation, stops too early/late, narrates every tool call, or ignores tool prerequisites.

Do NOT use it for: non-GPT-5.6 models (behavior claims here are model-specific), or plain single-turn chat prompts with no tools or multi-step goals — most rules below concern agentic contracts.

Rules

1. Simplify before adding. Delete repeated statements of the same rule, style/process instructions that do not change behavior, examples that do not change behavior, process instructions for behavior the model already does reliably, and tools or tool descriptions unrelated to the task. GPT-5-class models follow prompt contracts closely, so also sweep the prompt for contradictions — a contradiction is an instruction the model will try to obey.
2. Retain only the contract. Keep: the user-visible outcome; success criteria and stopping conditions; safety, business, evidence, and permission constraints; tool-routing rules where the route depends on context; and required output shape plus validation requirements. Everything else is a candidate for deletion.
3. Write outcome-first, not step-by-step. State the destination and let the model choose the path. Pattern: "Resolve the customer's issue end to end" followed by a "Success means:" list (make the decision from available evidence, complete allowed actions before responding, return named fields such as completed_actions, customer_message, blockers, and if evidence is missing ask for the smallest missing field).
4. Reserve absolutes for invariants. Use ALWAYS/NEVER/must/only for true invariants such as safety rules. For judgment calls, write decision rules instead — absolutes on judgment calls create brittle behavior.
5. Give an explicit stopping condition that ranks efficiency below correctness. Source pattern: resolve in the fewest useful tool loops, "but do not let loop minimization outrank correctness, required evidence, calculations, or required citations."
6. Define autonomy tiers once, compactly. (a) For requests to answer, explain, review, diagnose, or plan: inspect materials and report; do not implement changes unless also asked. (b) For requests to change, build, or fix: make in-scope local changes and run non-destructive validation without asking. (c) Require confirmation for external writes, destructive actions, purchases, or material scope expansion. Name the safe local actions explicitly. Do not repeat approval instructions — repetition causes unnecessary pauses.
7. For long-running work, name the current layer. Distinguish research, design, implementation, review, and external coordination so the model knows which phase it is authorized to advance.
8. Route tools by exposing fewer of them. Expose only task-relevant tools. Each description must state purpose, when to use it, important return fields, and error behavior.
9. Enforce prerequisites and fallbacks in the prompt. Tell the model: before acting, resolve required discovery, retrieval, and validation steps, and do not skip a prerequisite because the final state seems obvious. On empty, partial, or suspiciously narrow tool results, try one or two meaningful fallbacks before concluding no result exists. Parallelize independent reads; stay sequential when one result determines the next action.
10. Use PTC only for bounded reduction stages. PTC lets the model write JavaScript that orchestrates tools in a hosted runtime, passing results between calls. Enable it by adding the programmatic_tool_calling tool and setting allowed_callers. Good fits: filtering, joining, sorting, ranking, deduplication, aggregation; batching across many similar records; repeated deterministic validation; reducing large structured results to a compact schema. Use direct tool calls instead when one call suffices, intermediate outputs are already small, each result may change the next decision, an action requires approval, the final answer must preserve citations or native artifacts, or the workflow needs semantic judgment between calls.
11. Prompt PTC explicitly. State which bounded stage uses PTC, which documented tools it may call, the exact compact output schema including required evidence fields, concurrency/retry/stopping limits, and which work stays direct tool calling. Test program_output and the final assistant message as separate surfaces.
12. Multi-agent (beta) coordinates parallel subagents and synthesizes their results. It can reduce wall-clock time and improve performance for complex tasks that divide cleanly into independent workstreams.
13. Set reasoning.effort empirically, downward first. Levels: none, low, medium, high, xhigh, max. When migrating from GPT-5.5/5.4, preserve the current effort as baseline, then test one level lower on representative tasks — GPT-5.6 often maintains or improves quality with fewer tokens. Use low for latency-sensitive work when quality holds, medium as the balanced start, high/xhigh only when evals show a meaningful gain, max for the hardest quality-first workloads. Before raising effort, check whether the prompt is missing a success criterion, dependency rule, tool-routing rule, or verification loop — that is the cheaper fix.
14. Use pro mode selectively. Set reasoning.mode: "pro" (same model slug) for high-value tasks where marginal quality materially matters — complex optimization, critical code review, deep analysis with clear criteria. Skip it for routine, latency-sensitive, or high-volume work without demonstrated gains. Prompt it outcome-first with goals, context, constraints, required evidence, success criteria, output format; do not add "think harder" instructions.
15. Control length with text.verbosity plus specifics. GPT-5.6 is more concise by default than GPT-5.5, so re-evaluate inherited brevity instructions. Set text.verbosity (low/medium/high) as the default, and for shorter answers state what must remain and what can be omitted — e.g. lead with the conclusion, include supporting evidence, material caveats, and the next action; omit secondary detail and repetition.
16. Define tone as concrete choices, not labels. Replace vague labels with specific writing behavior: how directly to state the answer, whether to acknowledge a reported problem before giving the next step, and when reassurance or sign-offs are appropriate. Separately define collaboration style: when to ask questions, make assumptions, take initiative, explain tradeoffs, check work, and handle uncertainty.
17. Keep progress updates sparse. Ask for a short visible preamble before the first tool call, then outcome-based updates at major phase changes only. Do not ask the model to narrate routine tool calls. When replaying history, preserve assistant phase values so the model can tell commentary from the final answer.
18. Ground retrieval with a strategy, not a mandate. For ordinary Q&A: one broad search with short, discriminative keywords; answer from top results if they support the core request; retrieve again only when a required fact, owner, date, ID, or source is missing, the user asked for exhaustive coverage or comparison, a specific artifact must be read, or an important claim would be unsupported. For research outputs: cite only retrieved sources, attach citations to the claims they support, label inference separately from directly supported facts, and state conflicts between sources. Never invent names, metrics, dates, roadmap status, customer outcomes, or product capabilities.
19. Require validation and rendering before finalizing. After changes, run the most relevant available validation: targeted tests for changed behavior, type/lint checks, build checks for affected packages, or a minimal smoke test when full validation is too expensive. For visual artifacts, render and inspect layout, clipping, spacing, missing content, and visual consistency. For frontend work, also instruct: inspect and preserve existing design tokens/components/patterns, add no extra features or decorative UI unless requested, and preserve responsive behavior and expected states. For coordinate-sensitive or dense images, set image detail to original (or auto) instead of letting the image be resized.
20. Configure the runtime for multi-turn agents. Use the Responses API for reasoning, tool-calling, and multi-turn workflows. Persisted reasoning via reasoning.context (defaults to all_turns on GPT-5.6) helps when objective, assumptions, and priorities stay stable across turns; avoid carrying stale reasoning that only adds tokens and latency. For explicit prompt caching, keep reusable prefixes stable and avoid churn; cache writes cost 1.25× uncached input rates and reads stay discounted — monitor cached_tokens and cache_write_tokens. For end-user apps, pass a stable safety_identifier; real-time cyber/bio misuse classifiers can block or mid-stream pause generations.
21. Migrate one variable at a time. Order: (1) switch model, preserve current reasoning effort; (2) run representative evals before touching the prompt; (3) remove obsolete scaffolding, repeated instructions, irrelevant tools; (4) add only the smallest targeted instruction that fixes a measured regression; (5) re-run evals after each prompt or reasoning change. Never rewrite a working prompt stack all at once — you lose attribution between model, effort, prompt, tools, and runtime. Debug regressions from a small set of real traces: identify the failure mode, find the causing instruction or contradiction, make a surgical edit, rerun the same cases.

Suggested prompt skeleton (from the official guide)

Role: [the model's function and context]
Personality: [tone and collaboration style]
Goal: [user-visible outcome]
Success criteria: [what must be true before the final answer]
Constraints: [policy, safety, business, evidence, and side-effect limits]
Tools: [which tools to use, when, and what not to use]
Output: [sections, length, format, and tone]
Stop rules: [when to retry, fallback, abstain, ask, or stop]

Checklist

Before shipping a GPT-5.6 agent prompt:

• Prompt states the user-visible outcome and a "Success means:" list, not a step script.
• Explicit stop rule present; efficiency ranked below correctness, evidence, and citations.
• Three-tier autonomy policy written once: report-only requests / autonomous in-scope changes + non-destructive validation / confirmation for external writes, destructive actions, purchases, scope expansion.
• Safe local actions named explicitly; approval instructions not repeated.
• Only task-relevant tools exposed; each description covers purpose, when-to-use, return fields, error behavior.
• Prerequisite rule and 1–2-fallback rule for empty/partial results included.
• PTC decision made per rule 10; if enabled: programmatic_tool_calling tool added, allowed_callers set, bounded stage + eligible tools + output schema + concurrency/retry/stopping limits spelled out; program_output and final message tested separately.
• reasoning.effort chosen from baseline evals, with one-level-lower tested; reasoning.mode: "pro" only where quality gain is demonstrated.
• text.verbosity set; inherited brevity boilerplate re-evaluated against GPT-5.6's more concise default.
• Validation step required before finalizing (tests/lint/build/smoke; render-and-inspect for visual output).
• Progress updates limited to one preamble + phase-change updates.
• Duplicates, dead examples, contradictions, and unused tools removed.
• Migration done one variable at a time with evals between changes.

Anti-patterns

• Bloated prompts: repeated rules, behavior-neutral examples, process instructions for things the model already does — measured to hurt scores, not just cost.
• ALWAYS/NEVER on judgment calls instead of decision rules.
• Repeating approval requirements, which triggers unnecessary confirmation pauses.
• Letting loop-minimization outrank correctness, required evidence, calculations, or citations.
• Using PTC where each result should change the next decision, actions need approval, or citations/native artifacts must survive to the final answer.
• Marking a feature verified on unit-level signals alone when the guide asks for rendering/inspecting visual artifacts before finalizing.
• Adding "think harder" prose in pro mode instead of outcome, evidence, and success criteria.
• Raising reasoning.effort before checking for a missing success criterion, dependency rule, tool-routing rule, or verification loop.
• Narrating routine tool calls; dropping assistant phase values when replaying history.
• Rewriting the whole prompt stack during migration, destroying attribution of behavior changes.
• Inventing names, metrics, dates, roadmap status, customer outcomes, or product capabilities in grounded outputs.
• Churning cached prompt prefixes (writes cost 1.25× uncached input) or carrying stale persisted reasoning across turns.

Source

• Using GPT-5.6 — https://developers.openai.com/api/docs/guides/latest-model — 2026-07-09
• GPT-5.6 prompting guide — https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6 — 2026-07-09

Distilled from the official document(s) above on 2026-08-12. If this skill and the source disagree, trust the source.