Plus 10

Why Your Prompts Keep Failing (And How Plus 10 Actually Fixes It)

You write a prompt. You tweak it for twenty minutes. You paste it in. The output is okay, maybe decent, occasionally brilliant, usually annoyingly inconsistent. Then you run the same idea three times and get three wildly different results. This is the default experience of working with large language models, and it's not your fault. The models are fundamentally non-deterministic by design. They optimize for plausible continuation, not correctness, and they will happily fill in gaps you never asked them to fill. Plus 10 is one of the more usable structured prompt frameworks I've actually stuck with long enough to recommend it without reservation. It's not a magic bullet. It won't make a broken task produce clean output, and it won't fix poor source material. But it does solve a real problem: the gap between what you mean when you type something and what the model interprets you as asking for. Most people skip the gap analysis entirely and just accept bad results as normal. That's why the outputs feel random.

What Plus 10 Is and What It Actually Does

Plus 10 is a seven-component prompt template that forces you to be explicit about role, task, context, constraints, output format, examples, and reasoning chain. Each component addresses a specific failure mode that shows up in my workflow almost daily. The "plus 10" naming convention comes from stacking ten practical refinements onto a base prompt template, with each addition closing a common loophole the model exploits through ambiguity. Here's how the template breaks down in practice: Role: You define who the model is pretending to be. This sounds trivial but it shifts the probability distribution of the output significantly. A prompt that says "act as a senior software engineer who has shipped production systems at scale" produces measurably different output than "act as a helpful AI assistant." The role primes the model's weighting toward domain-specific patterns in its training data.

Task: You state exactly what needs to happen. Not vaguely, not with implied context. The task line is where most people fail because they assume the model understands the objective from surrounding text. It doesn't. State it as a verb phrase with a measurable outcome. "Rewrite the following documentation to target intermediate Python developers" is functional. "Make this better" is not. Context: You provide the background the model needs but won't have otherwise. This includes audience, purpose, existing constraints, and any relevant history. The difference between a prompt with context and one without is roughly the difference between getting usable output on the first try and spending an hour iterating. Constraints: You define what the model must not do. Negative constraints are harder for models to follow than positive ones, so I learned to phrase them carefully. Instead of "don't use jargon," I write "use plain language that a non-technical project manager could understand." The model handles re-framed constraints better than literal negatives.

Output Format: You specify the exact structure of the response. JSON, markdown table, numbered list, prose paragraph. If you don't specify format, the model chooses based on what looks most probable, and that choice is almost never what you want. I've seen outputs split across five formats within a single response when the prompt didn't enforce one. Examples: You include one or two few-shot examples of the desired output. This is the single highest-impact component in the framework. A well-chosen example does more work than three paragraphs of explanation because it demonstrates rather than describes. I usually include an example that shows the exact format and one that shows an edge case I want handled correctly. Chain-of-Thought Prompting: You ask the model to think through its reasoning before producing the final answer. This is where Plus 10 diverges from simpler templates. For complex tasks, forcing the model to articulate its reasoning step by step before committing to an answer reduces hallucination rates noticeably. You add "think through this step by step before responding" to the prompt structure.

How to Use Plus 10 Step by Step

I don't write these templates from scratch every time. I keep a master version in a text file and fill in the components for each use case. The process takes about ninety seconds once you're familiar with the structure, and it usually cuts the revision cycle from three or four attempts down to one. Start with "You are a [specific role] with expertise in [relevant domain]. Your experience includes [concrete credential or achievement]." Vague roles produce vague outputs. "You are an expert" is worthless. "You are a senior DevOps engineer who has migrated fifty-plus production workloads from on-prem infrastructure to AWS" gives the model a tight probability cone to work within. One sentence. One verb. One clear object. If you need more than one sentence to describe the task, you probably have multiple tasks and should split them into separate prompts. Compound prompts compound confusion.

Bullet points work better than prose for context because they force you to enumerate rather than summarize. The model parses structured input more reliably. Include: audience, purpose, constraints you're already aware of, and anything that would be obvious to a human but isn't stored in the model's weights. List what the output must not include. Word limits, banned topics, style restrictions, format prohibitions. I usually put this section right after context because it frames the boundaries before the model starts generating. Show the format you want, don't just describe it. A template with placeholders is more effective than a verbal description. If you want a markdown table with columns A, B, and C, include a header row with those column names and one example row.

This is where most people shortcut and regret it. A single good example is worth more than a paragraph of format description. I keep a running library of examples from past successful prompts and reuse them when the task type matches. The example should match the difficulty and complexity of what you're actually asking for. Add "Before producing the final output, think through your reasoning step by step" at the end of the prompt. For simple factual queries this is unnecessary overhead. For analysis, comparison, debugging, or anything that requires multi-step reasoning, it meaningfully improves output quality. I measure this roughly—anecdotal but consistent across hundreds of prompts. Early on I tried using Plus 10 for a prompt that asked the model to analyze logs and identify the root cause of a production incident. The framework worked perfectly on paper. The output was detailed, well-formatted, and looked authoritative. It was also wrong in a specific and expensive way: the model confidently identified the wrong service as the source of the cascade failure, and because the reasoning chain was so clearly articulated, I almost acted on it without verifying.

The workaround was adding a "source verification" step to the chain-of-thought section. I revised the prompt to require the model to explicitly cite which log entries supported each claim in its reasoning, then added a constraint that said "if a claim cannot be directly supported by provided log data, mark it as uncertain rather than stating it as fact." This changed the output from confident but incorrect to cautiously accurate with explicit confidence markers. The model now flags uncertainty properly instead of covering it up with plausible-sounding reasoning. This is the main limitation of Plus 10 that nobody talks about enough: it makes bad reasoning look good. A well-structured prompt with strong chain-of-thought instruction will produce outputs that are internally coherent and highly persuasive even when factually wrong. The framework amplifies confidence, not accuracy. Always verify critical claims independently, especially when the model is working with data you provide rather than accessing external sources.

When Plus 10 Doesn't Help (And What to Use Instead)

Plus 10 assumes the task has a definable structure with clear inputs and expected outputs. It breaks down for open-ended creative work where the objective is genuinely exploratory. If you're asking a model to generate marketing copy, brainstorm product names, or write fiction, the rigid template structure adds friction without proportional benefit. In those cases, a lighter framework or even a minimal prompt with a strong few-shot example works better. The framework also doesn't help when the underlying model capability is insufficient for the task. No amount of prompt engineering will make a smaller model produce output that matches a larger model on complex reasoning. If you're hitting the ceiling of what your model can do, Plus 10 won't lift you over it. You'd be better off upgrading the model or breaking the task into smaller sub-tasks that each fall within the model's capability range. Another limitation: the template gets long fast. A fully specified Plus 10 prompt can easily exceed eight hundred tokens of input, which matters when you're paying per token or working within context window constraints. I learned to strip the template down to its essential components for routine tasks and only use the full version for high-stakes or complex prompts. A stripped version with just role, task, constraints, and format still captures most of the benefit at a fraction of the token cost.

Alternative Frameworks Worth Knowing

If Plus 10 feels too rigid for your workflow, there are other options. RACE (Role, Action, Context, Example) is simpler and faster to fill out. CREATE (Context, Response, Example, Action, Tune, Evaluate) is more iterative and better for refinement loops. None of them solve the fundamental problem of model non-determinism, but they each optimize for different use cases. I use Plus 10 for production tasks where consistency matters, RACE for quick one-off prompts, and CREATE when I'm refining a prompt that needs to handle edge cases. The practical takeaway is that you should treat prompt structure as part of your engineering process, not as an afterthought. Plus 10 gives you a repeatable process for that. It won't eliminate iteration, but it will make each iteration more productive. That's the actual value proposition, and it's undersold by people who present it as a solution to problems that don't have solutions.