Master Prompts in 2026: Stop Prompting Like It's 2023 A developer argues that the era of verbose 'act as an expert' prompts is over, advocating for 'master prompts' as a stable policy layer above individual tasks. The piece details a structured framework with blocks for role, goal, context, process, constraints, output contract, and failure policy, emphasizing hard constraints and explicit success criteria over vague quality adjectives. It also highlights the shift toward context engineering and the importance of planning and verification in production AI systems. I still see people paste a 40-line “act as a senior expert with 20 years of experience” block into ChatGPT and call it engineering. That stopped working as a strategy a while ago. Models got better. Context windows got bigger. Agents started calling tools. And the failure mode shifted. It’s rarely “the model is dumb” now. It’s “your system has no contract.” This is a long, practical write-up on master prompts — the stable policy layer above individual tasks. How to write them. How to force planning. How to run Plan → Act → Observe → Verify without theater. How to make the same prompt useful to a tired human at 11pm and to an agent loop that only understands schemas. I’ve broken enough production prompts across GPT-4o, Claude 3.5 Sonnet, and Gemini-class stacks to have opinions. Some of them are uncomfortable. done when checks — not from longer personality blocks.A master prompt is not a magic spell. It’s the policy layer : User prompts change every hour. Master prompts change when your standards change. If you rewrite your “system personality” for every ticket, you don’t have a system. You have vibes. This distinction matters more once you leave single-chat workflows and enter prompt engineering for production — multi-step agents, tool routers, RAG pipelines, shared team libraries. The master prompt becomes the constant. Everything else is runtime input. Official docs still matter here, even if the ecosystem moved fast: One shift I care about in 2026: people say context engineering more than prompt engineering. Same game, wider board. You’re not only choosing words. You’re choosing what the model sees on each step inside a limited context window — policy, retrieved docs, tool traces, and the live task. Every master prompt I’ve kept in production has some version of these blocks. Skip one and you pay for it later. | Block | Hard question it answers | |---|---| | Role | Who are you, for whom? | | Goal | What counts as success in measurable terms? | | Context | What’s true about this environment right now? | | Process | In what order do you work? | | Constraints | What is forbidden even if it would be convenient? | | Output contract | What shape must the answer take? | | Failure policy | What do you do when data is missing? | ROLE You are a specific role . You work for audience . GOAL Success = observable outcome . Failure examples: what “almost right” looks like . CONTEXT - Product / domain: - Hard limits: - Sources of truth: PROCESS 1 State assumptions or ask the minimum clarifying question. 2 Build a dependency-aware plan. 3 Execute one atomic step at a time. 4 Verify against done when. 5 Return result + residual risks. CONSTRAINTS - Do not invent facts, APIs, quotes, or metrics. - Do not fake tool output. - If uncertain, say so and propose the cheapest check. OUTPUT Plan Result Verification Open questions Notice what’s missing: motivational fluff. “Be world-class.” “Think deeply.” Models already try. What they lack is your definition of finished work. On Claude 3.5 Sonnet and GPT-4o alike, vague quality adjectives underperform hard constraints and explicit success criteria. The model isn’t missing ambition. It’s missing your acceptance tests. The internet loves acronyms. Most of them are the same idea in a hoodie. RTF — Role / Task / Format Fine for small jobs. Don’t overbuild. CRAFT — Context / Role / Action / Format / Tone Good default for writing, analysis, support. Plan-and-Solve Force a plan before the answer. Boring. Effective. See the planning literature around Plan-and-Solve https://www.emergentmind.com/topics/plan-and-solve-prompting and agent planning surveys like arXiv:2402.02716 https://ar5iv.labs.arxiv.org/html/2402.02716 . Chain-of-Thought Still the simplest accuracy lever on multi-step reasoning. Original paper: Wei et al., 2022 https://arxiv.org/abs/2201.11903 . Tree of Thoughts When one path isn’t enough and you need deliberate search. Yao et al., 2023 https://arxiv.org/abs/2305.10601 . ReAct Thought → Action → Observation. If your agent uses tools and you don’t have this loop, you’re improvising. Pick one structure. Run it for a week. Measure. Then change one variable. Anthropic’s own guidance still ranks clarity, examples, thinking, structure above theatrical roleplay. Read their best practices https://claude.com/blog/best-practices-for-prompt-engineering if you haven’t in a while. Most “agent failures” are just un-decomposed work. A useful rule from task-decomposition practice: keep breaking the job down until each leaf task is doable in 1–3 tool calls and has a crisp done when . If a step needs a short novel of instructions, it isn’t a step yet. EngineersOfAI notes on decomposition https://engineersofai.com/docs/agentic-ai/long-horizon-planning/Task-Decomposition are blunt about this for a reason. This is the boring core of LLM orchestration : not more model calls for their own sake, but a graph of verifiable work units. Decomposition-first Build the full plan, then execute. Best for stable workflows: migrations, docs, publish checklists. Interleaved Plan a little, act, replan. Best for research and debugging where the map changes under your feet — including RAG pipelines where retrieval quality shifts mid-run. { "goal": "Ship a technical article with a pre-publish quality pass", "assumptions": "Target platform is Dev.to", "Audience is builders using LLMs in real workflows" , "tasks": { "id": "t1", "title": "Outline + claims list", "depends on": , "tool hint": "none", "done when": "H2/H3 outline exists and 8–12 claims are listed" }, { "id": "t2", "title": "Write full draft", "depends on": "t1" , "tool hint": "none", "done when": "Complete draft with no TODO markers" }, { "id": "t3", "title": "Fact-check hard claims", "depends on": "t2" , "tool hint": "search", "done when": "Every strong claim has a source or is marked UNVERIFIED" }, { "id": "t4", "title": "Publish checklist + SEO verify", "depends on": "t3" , "tool hint": "api", "done when": "Top 5 impact/effort fixes are written from evidence" } , "risks": "Stale references", "Generic advice with no operational detail" } You are Task Planner. You do not execute. You only produce an executable plan. Rules: 1 Split the goal into atomic steps. 2 One step = one action or one tool call. 3 Declare dependencies. 4 Every step needs done when. 5 If information is missing, add assumptions and clarifying questions. 6 No prose essay. Structure only. Return strict JSON: { "goal": "...", "assumptions": , "clarifying questions": , "tasks": { "id": "t1", "title": "...", "description": "...", "depends on": , "tool hint": "none|search|code|browser|api", "done when": "..." } , "risks": } Microsoft’s agent curriculum makes the same point in plainer language: define the goal, break it, then assign work. See their planning design chapter https://github.com/microsoft/ai-agents-for-beginners/blob/main/07-planning-design/README.md . Once you have a plan, stop letting the model freestyle the whole graph. Plan → Act → Observe → Verify → Repair or Next Without Verify , agents lie politely. They narrate completion. They do not prove it. This loop is where prompt engineering for production stops being “wording” and becomes control flow. The master prompt defines the rules. The orchestrator enforces step boundaries. Tools supply evidence. Verification closes the books. You are Executor Agent. Take exactly one next task from the plan. Do not jump ahead. Inputs: - plan JSON - current task id - tool results if any Method: 1 Re-read done when for the current task. 2 If blocked on missing data, request a tool or mark blocked. 3 Do the smallest useful action. 4 Return: Action Evidence Status: done | partial | blocked Next recommendation If Status is partial or blocked: 1 Name the blocker in one sentence. 2 Propose the cheapest next check. 3 Do not rewrite the entire plan unless dependencies actually changed. This is less glamorous than “autonomous agent.” It is also why some systems finish jobs and others generate confident debris. I used to spend an hour polishing adjectives. Now I spend that hour deciding what not to put in context. Use the smallest token set that still steers behavior. That’s token efficiency as an engineering constraint, not a slogan. | Content | Placement | |---|---| | Stable policy / role | Front of the prompt also helps caching | | Reference docs / data | Clearly delimited blocks | | Retrieved RAG chunks | After policy, tagged and ranked by relevance | | Examples | After policy, before the live task | | User task | End | In RAG pipelines , the master prompt should also say how to treat retrieved text: prefer it over parametric memory, cite chunk ids, and refuse to invent when retrieval is empty. Without that policy, retrieval becomes decoration. OpenAI’s notes on prompt caching https://platform.openai.com/docs/guides/prompt-caching are worth reading if cost and latency matter: put stable prefixes first, variable content last.