Something in a developer’s workflow was broken. Every single day, a carefully written 900-line prompt was falling apart, producing inconsistent results, requiring manual fixes. That’s when u/trirsquared, a contributor on r/PromptEngineering, decided to stop patching and start rebuilding.
The solution the author proposed: a new prompting standard called SLOP. That stands for Simple Language of Prompting. The acronym is intentional. Yes, only the author is laughing. But stay with it, because the concept is actually solid.
What SLOP Is
The core argument behind SLOP is this: AI models are nondeterministic, but that doesn’t mean prompts have to be vague. You can apply rules, logic, and structure to make prompts behave more predictably.
Most prompts today look like instructions you’d leave for a house-sitter. “Handle things the usual way. Use your judgment.” SLOP looks more like a decision tree: if condition X, do step A. If condition Y, do step B. Return result in this format. Think of it like replacing a paragraph of loosely written instructions with a flowchart. The information is the same. The ambiguity is gone.
The author took that broken 900-line prompt and told Claude to rewrite it in SLOP syntax. It worked on the first run. Every time after that too.
The Twist
Here’s what’s actually interesting: this isn’t about simplifying prompts. It’s about structuring them. The name says “simple language” but what it really means is unambiguous language.
Natural language has a lot of wiggle room. “Handle exceptions gracefully” means different things to different models, on different days, with different temperatures. SLOP removes the wiggle. You define what “gracefully” means. You define the exception types. You define the output format. The model stops guessing and starts executing.
This is closer to how developers write spec docs or unit tests than how most people write prompts. And that’s the whole point. If you’ve ever written acceptance criteria for a software feature, you already know how to think in SLOP. You’re just applying it to a different audience.
🛠 How to Test SLOP on Your Own Prompts
You don’t need any special tool to start. Here’s a simple workflow:
- 📋 Pick a prompt that fails inconsistently or needs daily hand-holding
- Feed it to Claude or GPT with this instruction: “Rewrite this prompt using explicit rules, conditions, and numbered sequential steps. Each step should be unambiguous.”
- Run both versions five times. Note where each one breaks.
- For the structured version, find any step where the model still has to guess. Add a decision rule to remove that guess. Be specific about edge cases you’ve seen before.
- ✅ Keep iterating until the prompt runs clean, every time.
Pro Tips
- Prompts with multiple conditions and branching logic benefit most from this approach. If your prompt has an “it depends” buried in it somewhere, that’s your starting point.
- Don’t just restructure the instructions. Also define the output format explicitly. “Return a JSON object with these exact keys” is more reliable than “respond in a helpful way.”
- SLOP doesn’t fix bad logic. It exposes it. If the structured version still fails, you’ll now see exactly which rule is wrong instead of getting a vague, inconsistent mess. That alone is worth the rewrite.
- Once a prompt is stable, document the decision rules separately. When the model gets upgraded or swapped, you’ll know exactly what to retest.
Why This Matters
One commenter in the thread put it simply: most people overcomplicate prompting when direct and simple gets better results. SLOP agrees with that, but takes it further. Simple doesn’t mean short. Simple means precise.
For anyone running AI-powered automation, building agents, or maintaining prompts that power anything business-critical, this is the direction things are heading. The era of hoping the model figures it out is being replaced by structured prompting that tells the model exactly what to do. Teams that nail this early will spend a lot less time babysitting their pipelines.
The author admits SLOP might feel complex for casual use. But for systematic, multi-step workflows, that complexity is the point. You want a spec, not a sticky note.
A Standard Worth Watching
The full SLOP framework is linked in the original Reddit post. The author published a detailed breakdown on Substack with syntax examples and the reasoning behind the structure.
It’s early. The community is still poking at the edges. But the results the author is reporting, a 900-line prompt that stopped breaking entirely, are hard to argue with!
Head to the r/PromptEngineering thread by u/trirsquared. 🚀 The debate is open and the author is actively responding to questions.
Frequently Asked Questions
Q: What is SLOP and what problem does it solve?
SLOP (Simple Language of Prompting) is a proposed standard for structuring AI prompts with clear rules and logic. Instead of fragile, ad-hoc prompts that break regularly, SLOP gives you a consistent syntax so your prompts behave predictably. The creator converted a chaotic 900-line prompt into SLOP and it worked reliably every time thereafter.
Q: Isn’t SLOP just another way of saying “write simpler prompts”?
While people confirm that simple, direct prompting gets better results, SLOP adds a layer of standardization. Instead of just being brief, SLOP is a defined standard with syntax and rules that prevent haphazard approaches. So yes, simplicity is part of it, but the real value is structure, SLOP codifies what works.
Q: How is SLOP different from just writing clearer prompts?
SLOP is a standard with defined syntax and rules, not just vague advice to “be clear.” Most people overcomplicate prompting without realizing it, SLOP forces you into a disciplined format that prevents haphazard approaches that break when you change a word. It’s the difference between trying to be clear versus following a reliable blueprint.
SLOP = Simple Language of Prompting
by u/trirsquared in PromptEngineering