TL;DR: A Redditor dropped a 49-section prompt that doesn’t ask an AI to write code, it tells the AI how to run an entire product team. Read the breakdown below before you try to copy it.
u/Ornery-Dark-5844 posted it in r/PromptEngineering, written in Portuguese, under the name “Prompt Engineering Agent Workbench.” It’s not a prompt in the usual sense. It’s a 50-page constitution for an app that helps you build other prompts, and this contributor clearly thought through every layer of it before posting. Most people who post prompts in that subreddit share a paragraph. This person shared something closer to a founding document, the kind of thing a product team would spend a quarter writing and arguing over in Slack.
What This Actually Is
Most prompts tell an AI what to produce. This one tells an AI how to behave while producing it. The goal: a workbench where a user creates, tests, optimizes, and versions prompts, with an LLM acting as the engineer sitting next to them. Think of it less like a chatbot and more like a senior teammate who already knows the style guide, the roadmap, and the five ways past attempts went sideways.
The author’s core idea is simple to say and hard to pull off: internal complexity, external simplicity. The system can be as sophisticated as it needs to be under the hood, running multiple reasoning passes, checking its own assumptions, tracking state across a whole project. The user never has to see any of that. They type a request and get a clean result, the same way you don’t think about transmission gears when you press the gas pedal.
The Hierarchy That Runs The Whole Thing
Every decision in this spec gets filtered through one priority stack: user experience first, then workflow, then functionality, then agent behavior, then the internal cognitive machinery. If internal complexity ever fights with interface clarity, clarity wins. The system hides the mess, not the capability. So if a feature would require exposing a confusing setting to get slightly better output, the spec says bury the setting and eat the small inefficiency instead.
That single rule is doing more work than most 10-page style guides manage. It gives the AI a tiebreaker for every single UI or behavior decision instead of leaving it to guess. Ask a model to “be helpful and clear” and it’ll interpret that a dozen different ways depending on the task. Give it an explicit ranked list, and now every edge case has an answer baked in before it even comes up.
The Cognitive Pipeline
Instead of “think step by step,” the creator built an eight-stage pipeline: Intent, Requirements, Domain, Architecture, Implementation, Verification, Operation, Evolution. Each stage has one job and hands off to the next, so the model can’t skip straight to generating a prompt before it actually understands what the user wants. Intent asks why the user wants this at all. Requirements pins down what “done” looks like. Domain brings in context the model might otherwise ignore. Only after those three does Architecture even start sketching a structure.
The smartest part is that the pipeline flexes with task size. A quick fix only needs Intent, Requirements, Implementation, Verification, four stages, done in a minute. A production-grade agent needs the full eight stages, including Operation (how it behaves once it’s live) and Evolution (how it improves after real use). Same brain, different depth, which is exactly how a good senior engineer actually works. They don’t run a full design review before fixing a typo, but they also don’t skip the review before shipping something load-bearing.
Use Cases 🎯
This structure isn’t just for prompt engineering tools. The underlying pattern works anywhere you’re asking an LLM to act as a long-running collaborator instead of a one-shot answer machine:
- Building an internal tool where non-technical teammates need to talk to an agent without seeing the plumbing
- Any app where “projects” need isolated memory and context, like a client-management or research assistant
- Agent products where task complexity should change how much reasoning the model does, not just how long the output is
- Customer support bots that need to triage a quick password reset differently than a billing dispute that touches three systems
Prompt of the Day
Here’s the exact core directive from the spec, the one rule everything else in the 49 sections obeys:
A aplicação deve ser:
sofisticada internamente, simples externamente.
Prioridade absoluta:
USER EXPERIENCE
↓
USER WORKFLOW
↓
APPLICATION FUNCTIONALITY
↓
AGENT BEHAVIOR
↓
COGNITIVE ORCHESTRATION
↓
INTERNAL STATE
↓
IMPLEMENTATION DETAILS
Se existir conflito entre complexidade interna e clareza da interface:
preservar a capacidade interna e simplificar sua apresentação ao usuário.
That’s five lines doing the job of a full design review. Drop it at the top of any agent-building prompt and every downstream decision inherits the same priority order, no extra explanation needed.
One commenter pointed out the real catch: this reads like a full product spec, and feeding it to a model gets you a prototype fast. The hard part is keeping the agent’s behavior consistent once you’re switching between the “quick fix” mode and the “full engineering” mode on the same project. That’s not a flaw in the prompt, it’s just the next problem to solve, the same problem every real engineering team runs into once a tool outgrows its first use case.
Try It Yourself
If you’re building anything agent-shaped, steal the priority hierarchy and the complexity tiers before you touch the rest. Translate the sections you need, test the quick-mode pipeline on a small task first, then scale up to the full eight stages once you trust the agent’s judgment. Start with just the hierarchy and the four-stage quick path, ship something small with it, and only add the rest of the pipeline once you’ve felt where the quick path actually breaks. Check the original thread in r/PromptEngineering for the full 49 sections.
PROMPT ENGINEERING AGENT WORKBENCH (pt_br)
by u/Ornery-Dark-5844 in PromptEngineering