{"slug": "master-prompts-in-2026-stop-prompting-like-it-s-2023", "title": "Master Prompts in 2026: Stop Prompting Like It's 2023", "summary": "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.", "body_md": "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.\n\nThat stopped working as a strategy a while ago.\n\nModels 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.”\n\nThis 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.\n\nI’ve broken enough production prompts across GPT-4o, Claude 3.5 Sonnet, and Gemini-class stacks to have opinions. Some of them are uncomfortable.\n\n`done_when`\n\nchecks — not from longer personality blocks.A master prompt is not a magic spell.\n\nIt’s the **policy layer**:\n\nUser prompts change every hour.\n\nMaster prompts change when your standards change.\n\nIf you rewrite your “system personality” for every ticket, you don’t have a system. You have vibes.\n\nThis 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.\n\nOfficial docs still matter here, even if the ecosystem moved fast:\n\nOne 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.\n\nEvery master prompt I’ve kept in production has some version of these blocks. Skip one and you pay for it later.\n\n| Block | Hard question it answers |\n|---|---|\n| Role | Who are you, for whom? |\n| Goal | What counts as success in measurable terms? |\n| Context | What’s true about this environment right now? |\n| Process | In what order do you work? |\n| Constraints | What is forbidden even if it would be convenient? |\n| Output contract | What shape must the answer take? |\n| Failure policy | What do you do when data is missing? |\n\n```\nROLE\nYou are a [specific role]. You work for [audience].\n\nGOAL\nSuccess = [observable outcome].\nFailure examples: [what “almost right” looks like].\n\nCONTEXT\n- Product / domain:\n- Hard limits:\n- Sources of truth:\n\nPROCESS\n1) State assumptions or ask the minimum clarifying question.\n2) Build a dependency-aware plan.\n3) Execute one atomic step at a time.\n4) Verify against done_when.\n5) Return result + residual risks.\n\nCONSTRAINTS\n- Do not invent facts, APIs, quotes, or metrics.\n- Do not fake tool output.\n- If uncertain, say so and propose the cheapest check.\n\nOUTPUT\n## Plan\n## Result\n## Verification\n## Open questions\n```\n\nNotice what’s missing: motivational fluff. “Be world-class.” “Think deeply.” Models already try. What they lack is your definition of finished work.\n\nOn 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.\n\nThe internet loves acronyms. Most of them are the same idea in a hoodie.\n\n**RTF — Role / Task / Format**\n\nFine for small jobs. Don’t overbuild.\n\n**CRAFT — Context / Role / Action / Format / Tone**\n\nGood default for writing, analysis, support.\n\n**Plan-and-Solve**\n\nForce 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).\n\n**Chain-of-Thought**\n\nStill the simplest accuracy lever on multi-step reasoning. Original paper: [Wei et al., 2022](https://arxiv.org/abs/2201.11903).\n\n**Tree of Thoughts**\n\nWhen one path isn’t enough and you need deliberate search. [Yao et al., 2023](https://arxiv.org/abs/2305.10601).\n\n**ReAct**\n\nThought → Action → Observation. If your agent uses tools and you don’t have this loop, you’re improvising.\n\nPick one structure. Run it for a week. Measure. Then change one variable.\n\nAnthropic’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.\n\nMost “agent failures” are just un-decomposed work.\n\nA 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`\n\n. 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.)\n\nThis is the boring core of **LLM orchestration**: not more model calls for their own sake, but a graph of verifiable work units.\n\n**Decomposition-first**\n\nBuild the full plan, then execute. Best for stable workflows: migrations, docs, publish checklists.\n\n**Interleaved**\n\nPlan 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.\n\n```\n{\n  \"goal\": \"Ship a technical article with a pre-publish quality pass\",\n  \"assumptions\": [\n    \"Target platform is Dev.to\",\n    \"Audience is builders using LLMs in real workflows\"\n  ],\n  \"tasks\": [\n    {\n      \"id\": \"t1\",\n      \"title\": \"Outline + claims list\",\n      \"depends_on\": [],\n      \"tool_hint\": \"none\",\n      \"done_when\": \"H2/H3 outline exists and 8–12 claims are listed\"\n    },\n    {\n      \"id\": \"t2\",\n      \"title\": \"Write full draft\",\n      \"depends_on\": [\"t1\"],\n      \"tool_hint\": \"none\",\n      \"done_when\": \"Complete draft with no TODO markers\"\n    },\n    {\n      \"id\": \"t3\",\n      \"title\": \"Fact-check hard claims\",\n      \"depends_on\": [\"t2\"],\n      \"tool_hint\": \"search\",\n      \"done_when\": \"Every strong claim has a source or is marked UNVERIFIED\"\n    },\n    {\n      \"id\": \"t4\",\n      \"title\": \"Publish checklist + SEO verify\",\n      \"depends_on\": [\"t3\"],\n      \"tool_hint\": \"api\",\n      \"done_when\": \"Top 5 impact/effort fixes are written from evidence\"\n    }\n  ],\n  \"risks\": [\n    \"Stale references\",\n    \"Generic advice with no operational detail\"\n  ]\n}\nYou are Task Planner. You do not execute. You only produce an executable plan.\n\nRules:\n1) Split the goal into atomic steps.\n2) One step = one action or one tool call.\n3) Declare dependencies.\n4) Every step needs done_when.\n5) If information is missing, add assumptions and clarifying_questions.\n6) No prose essay. Structure only.\n\nReturn strict JSON:\n{\n  \"goal\": \"...\",\n  \"assumptions\": [],\n  \"clarifying_questions\": [],\n  \"tasks\": [\n    {\n      \"id\": \"t1\",\n      \"title\": \"...\",\n      \"description\": \"...\",\n      \"depends_on\": [],\n      \"tool_hint\": \"none|search|code|browser|api\",\n      \"done_when\": \"...\"\n    }\n  ],\n  \"risks\": []\n}\n```\n\nMicrosoft’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).\n\nOnce you have a plan, stop letting the model freestyle the whole graph.\n\n```\nPlan → Act → Observe → Verify → Repair or Next\n```\n\nWithout **Verify**, agents lie politely. They narrate completion. They do not prove it.\n\nThis 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.\n\n```\nYou are Executor Agent.\nTake exactly one next task from the plan.\nDo not jump ahead.\n\nInputs:\n- plan JSON\n- current_task_id\n- tool_results (if any)\n\nMethod:\n1) Re-read done_when for the current task.\n2) If blocked on missing data, request a tool or mark blocked.\n3) Do the smallest useful action.\n4) Return:\n\n## Action\n## Evidence\n## Status: done | partial | blocked\n## Next recommendation\nIf Status is partial or blocked:\n1) Name the blocker in one sentence.\n2) Propose the cheapest next check.\n3) Do not rewrite the entire plan unless dependencies actually changed.\n```\n\nThis is less glamorous than “autonomous agent.” It is also why some systems finish jobs and others generate confident debris.\n\nI used to spend an hour polishing adjectives. Now I spend that hour deciding what *not* to put in context.\n\nUse the smallest token set that still steers behavior. That’s **token efficiency** as an engineering constraint, not a slogan.\n\n| Content | Placement |\n|---|---|\n| Stable policy / role | Front of the prompt (also helps caching) |\n| Reference docs / data | Clearly delimited blocks |\n| Retrieved RAG chunks | After policy, tagged and ranked by relevance |\n| Examples | After policy, before the live task |\n| User task | End |\n\nIn **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.\n\nOpenAI’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.\n\n```\n<policy>...</policy>\n<context>...</context>\n<retrieved>...</retrieved>\n<examples>...</examples>\n<task>...</task>\n```\n\nXML, Markdown headings, triple backticks — pick a convention and stop rotating it every sprint. Inconsistency is a silent quality tax across GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro deployments alike.\n\nLong-context tip that keeps showing up in lab guidance: put large source material first, put the actual question last. Anthropic has reported meaningful gains from that ordering on long inputs inside a large context window.\n\nGood examples are diverse and slightly annoying. Edge cases. Near-misses. Format traps.\n\nEight nearly identical happy-path samples teach the model to sound right while being fragile.\n\nTwo to five sharp examples beat a museum of mediocre ones.\n\nIf another system will consume the answer, stop accepting free-form essays.\n\n```\nReturn ONLY valid JSON:\n{\n  \"summary\": \"string\",\n  \"actions\": [{\"priority\": 1, \"fix\": \"string\", \"effort\": \"S|M|L\"}],\n  \"risks\": [\"string\"]\n}\nNo markdown fence. No commentary.\n```\n\nThen validate. Retry with the schema error. Humans can tolerate messy answers. Pipelines cannot — especially when the next hop is another agent, a ticket system, or a CMS write API.\n\n```\nTRUTH POLICY\n- Do not invent citations, numbers, APIs, dates, or “studies.”\n- If a claim is not grounded in provided context, retrieved chunks, or tool output, mark it UNVERIFIED.\n- Incomplete + honest beats complete + fabricated.\n- Prefer a cheaper verification step over a confident guess.\n```\n\nLabs keep repeating a version of this: allow “I don’t know.” It still gets ignored in the wild.\n\n```\nYou are a research analyst.\n\nProcess:\n1) Source plan first\n2) Notes with links/quotes\n3) Synthesis only after notes exist\n\nRules:\n- Every hard claim needs a source or UNVERIFIED\n- Separate facts from interpretation\n- End with confidence and open questions\n\nOutput:\n## Source plan\n## Notes\n## Synthesis\n## UNVERIFIED\n## Next checks\nYou are a senior engineer working under change control.\n\nProcess:\n1) Reproduce the problem\n2) Minimal fix\n3) Test or verification path\n4) Short explanation of the diff\n\nConstraints:\n- No drive-by refactors\n- No “while we’re here” features\n- If a public API changes, call it out explicitly\n\nOutput:\n## Root cause\n## Fix\n## Test plan\n## Residual risks\nYou are a technical editor with publishing standards.\n\nGoal:\nA draft that can ship — structure, claims, scanability, on-page hygiene.\n\nProcess:\n1) Outline\n2) Draft\n3) Fact-check\n4) Clarity pass\n5) Publish checklist (title, description, H1/H2, links, alts)\n6) If a live URL exists, run a verify pass and rank fixes\n\nOutput:\n## Outline\n## Final draft\n## Checklist\n## Top fixes\nYou are an incident triage agent.\n\nProcess:\n1) Symptoms → ranked hypotheses\n2) Cheapest diagnostic step\n3) Evidence\n4) Decision: fix / escalate / monitor\n\nOutput:\n## Hypothesis ranking\n## Next diagnostic step\n## Decision\n## Why\n```\n\nThese are intentionally plain. Flashy prompts age badly. Contracts age better.\n\nContent agents love generating. They hate proving the page is healthy after publish.\n\nA sane pipeline looks like this:\n\n```\nIdea → Outline → Draft → Fact-check → Edit → Publish checklist → Live verify → Fix backlog\n```\n\nThe last two steps are where quality either becomes real or becomes marketing.\n\nOnce you have a URL, stop guessing about titles, meta, heading hierarchy, schema, and performance signals. Measure.\n\nThis is the gap most LLM orchestration diagrams skip: generation is only half the loop. Publish workflows need a machine-readable verification service that agents can call, parse, and turn into ranked work.\n\n**AuditMe provides an API designed for automated SEO verification within AI agent pipelines.** It’s not a dashboard you stare at after the fact — it’s a structured audit endpoint agents can hit as a tool step, then convert JSON findings into priority-ordered fixes (meta, headings, Core Web Vitals, schema, links).\n\nPractical path:\n\n`done_when`\n\n.\n\n```\n{\n  \"id\": \"t5\",\n  \"title\": \"SEO verify live URL\",\n  \"depends_on\": [\"t4\"],\n  \"tool_hint\": \"api\",\n  \"done_when\": \"Audit evidence exists and top 5 fixes are ranked by impact/effort\"\n}\n```\n\nIf you’re wiring agents, use a structured endpoint rather than screenshots of dashboards. [AuditMe’s API docs](https://www.auditme.dev/api-docs) make that concrete: one request, JSON back, backlog out. No human copy-paste from a UI.\n\n```\nYou verify a published URL.\n1) Collect on-page signals (title, meta, H1, heading tree, links, CWV risks).\n2) If an audit tool/API is available, treat it as source of truth.\n3) Prefer structured audit APIs (e.g. AuditMe) over subjective page reading.\n4) Return only prioritized actions:\n   - priority\n   - issue\n   - fix\n   - effort (S/M/L)\nNo generic advice without evidence.\n```\n\nFor content and GEO/SEO workflows, a master prompt should end on **measurable next actions**, not applause for the draft. That’s the whole point of a verify layer — and why [AuditMe](https://www.auditme.dev/) fits as infrastructure in the agent graph, not as a blog-roll link in the intro.\n\nIf you can’t score a prompt change, you are collecting folklore.\n\n`v1`\n\nvs `v2`\n\nAnthropic’s docs are explicit: define success criteria and evaluation before you endlessly tweak wording.\n\n| Criterion | 0 | 1 | 2 |\n|---|---|---|---|\n| Goal | Missed | Partial | Hit |\n| Format | Broken | Close | Exact |\n| Facts | Invented | Soft | Grounded / marked |\n| Plan | Missing | Shallow | Executable |\n| Verify | None | Cosmetic | Checks `done_when`\n|\n\nIf three prompt iterations don’t move the score:\n\nDo **not** add another paragraph of “be meticulous.” That’s the opposite of prompt optimization.\n\n| Pattern | What breaks | Fix |\n|---|---|---|\n| “Make it high quality” | No success definition | Goal + `done_when`\n|\n| Twelve asks in one message | Dropped steps | Plan JSON + single-task executor |\n| No output contract | “Almost usable” answers | Schema / fixed headings |\n| Only negative instructions | Soft boundaries | State the desired behavior |\n| 900-line system prompt | Contradictions, wasted context window | High-signal policy, versioned |\n| No eval | Imaginary progress | Golden set + rubric |\n| Agent without verify | Fake completion | Status + Evidence required |\n| Claims without sources | Quiet hallucinations | UNVERIFIED policy |\n| RAG without retrieval policy | Retrieved noise treated as truth | Explicit ranking + refuse-if-empty rules |\n\nThe boring fixes win. They always did.\n\nStore them.\n\n```\nprompts/\n  master_v3.md\n  planner_v2.md\n  executor_v2.md\n  research_v1.md\nevals/\n  golden_set.json\n  rubric.md\nCHANGELOG.md\nv3 → v4\n- Required Verification section\n- Cut Role from ~120 words to ~40\n- Format score 1.4 → 1.8 on golden set\n- Reason: executor skipped done_when on multi-step jobs\n```\n\nPin model snapshots in production when behavior is load-bearing. Otherwise you’ll debug a prompt that didn’t change while the model underneath did.\n\nBy 2026, teams that treat prompts as disposable chat text are the same teams surprised by regressions every model bump — whether the stack is GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro.\n\nSteal this. Strip it. Make it yours.\n\n```\nSYSTEM / MASTER PROMPT\n\nYou are a reliable execution agent.\n\n1) ROLE\nDomain-competent specialist. Precise. Structured. No filler.\n\n2) OPERATING MODE\n- Plan before acting on complex work.\n- One focus at a time.\n- Verify done_when after each action.\n\n3) TOOLS\nUse tools when facts may have changed or verification is required.\nNever simulate tool output.\n\n4) PLANNING\nDecompose complex goals into tasks with dependencies and done_when.\nIf a step needs more than 3 tool calls, split it.\n\n5) TRUTH\nDo not invent. Mark UNVERIFIED. Ask for critical missing context.\nPrefer retrieved evidence and tool results over memory.\n\n6) OUTPUT CONTRACT\nDefault shape:\n## Plan\n## Work\n## Result\n## Verification\n## Risks / Next steps\n\n7) FAILURE HANDLING\nIf blocked:\n- state the reason\n- list what is missing\n- propose the cheapest next step\n\n8) STYLE\nShort sentences. Lists over fog.\nCode/JSON only when necessary.\n```\n\nWorks across GPT-class, Claude-class, and Gemini-class instruction styles. Not because it’s poetic — because it encodes process for LLM orchestration, not vibes.\n\n`done_when`\n\nThree red boxes means prototype. Not production.\n\n| Day | Move | Outcome |\n|---|---|---|\n| 1 | Write master v1 + gather 15 real tasks | Baseline contract |\n| 2 | Tighten Goal / Constraints / Output | Less format chaos |\n| 3 | Add plan JSON for hard jobs | Executable structure |\n| 4 | Add executor with Status/Evidence | Step control |\n| 5 | Add verify layer for publish/quality work | Fewer false dones |\n| 6 | Score v1 vs v2 | Numbers instead of opinions |\n| 7 | Cut 20–40% of prompt text without losing score | Team default v3 |\n\nAfter seven days you should have a standard, not a favorite paragraph.\n\nA system prompt is a message role in an API call. A master prompt is the *policy content* you usually put there — and keep stable across tasks. In practice, teams use “master prompt” for the versioned contract (role, goals, constraints, output rules) that many user tasks share.\n\nDon’t rely on tone. Require grounding: tool results, retrieved chunks, or explicit `UNVERIFIED`\n\nlabels. Force a verify step with `done_when`\n\n, and refuse simulated tool output. Hallucinations shrink when completion must be evidenced, not narrated.\n\nBecause the next consumer is often another agent, a validator, or an API — not a human reader. JSON (or another strict schema) makes success machine-checkable, enables retries on invalid structure, and keeps LLM orchestration deterministic at the boundaries.\n\nYes — the wording tax goes down, the systems tax goes up. Smarter models still need clear goals, step boundaries, retrieval policy, and verification. Prompt engineering for production is less about clever phrasing and more about contracts that survive model swaps.\n\nDon’t “finish reading later.” Install one piece.\n\n`done_when`\n\n.`master_v1.md`\n\n.That’s the whole game: a contract that survives model changes, teammate turnover, and the next hype cycle.\n\nMaster prompts in 2026 are not literature. They’re operations.\n\nHumans need them to stay consistent.\n\nAgents need them to stop improvising.\n\nWrite the contract. Measure it. Cut the noise. Ship.", "url": "https://wpnews.pro/news/master-prompts-in-2026-stop-prompting-like-it-s-2023", "canonical_source": "https://dev.to/edo911/master-prompts-in-2026-stop-prompting-like-its-2023-52dh", "published_at": "2026-09-03 06:50:39+00:00", "updated_at": "2026-09-03 07:23:27.244243+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "ai-tools", "developer-tools"], "entities": ["ChatGPT", "GPT-4o", "Claude 3.5 Sonnet", "Gemini", "Wei et al.", "Plan-and-Solve", "Tree of Thoughts", "Chain-of-Thought"], "alternates": {"html": "https://wpnews.pro/news/master-prompts-in-2026-stop-prompting-like-it-s-2023", "markdown": "https://wpnews.pro/news/master-prompts-in-2026-stop-prompting-like-it-s-2023.md", "text": "https://wpnews.pro/news/master-prompts-in-2026-stop-prompting-like-it-s-2023.txt", "jsonld": "https://wpnews.pro/news/master-prompts-in-2026-stop-prompting-like-it-s-2023.jsonld"}}