Most prompt engineering advice tells you to just write better prompts. This Reddit post from r/PromptEngineering does the opposite: it makes you design the prompt before you’re allowed to write it. The framework is called FUP-1 (Framework Universal para Planejamento e Engenharia de Prompts) and it treats every prompt like a piece of software you’d actually want to maintain, not a one-off message you’ll never look at again.
TL;DR
FUP-1 turns any request into a full engineering spec first (goals, scope, constraints, risks, validation) and only generates the final prompt after that spec survives its own review. Think blueprint before building, not building while you figure out the blueprint.
What FUP-1 Actually Does
The system prompt casts the model as a “Prompt Architect” with one hard rule: never write a prompt immediately. Design first. Validate second. Generate last. That single constraint is the whole point of the framework, and it’s also the part most people will want to skip. Don’t skip it. The temptation to jump straight to wording is exactly the habit FUP-1 is built to break.
From there it runs through 13 stages: understanding the request, modeling objectives and constraints, architecting 15 separate attributes (persona, scope, inputs, outputs, tone, depth, and more), applying general rules like modularity and traceability, checking for missing information, running a cognitive process, validating against a checklist, handling uncertainty, resolving conflicts by priority, predicting risks with mitigation plans, logging version and authorship, and finally doing a critical self-review before the prompt ever gets generated. Each stage produces its own small artifact, so by the time you reach stage 13 you’re not reviewing a vague idea, you’re reviewing a document with a paper trail.
The delivery format is 16 numbered sections, ending with the actual usable prompt, built entirely from placeholders like {{objetivo}}, {{contexto}}, and {{restricoes}} so it’s reusable across projects. Swap the placeholders and the same architected prompt works for a different client, a different dataset, or a different month without you rebuilding the logic from scratch.
Why This Matters
Most people write prompts the way they write first drafts: start typing, see what happens, patch it later. That works fine for a one-off question. It falls apart the moment you need a prompt that ten different people on your team will reuse for months, across different clients, contexts, or data. Patch-later prompts accumulate silent inconsistencies. One teammate adds a tone tweak, another adds a length constraint, and six months later nobody remembers which version is the “real” one.
FUP-1 forces the separation between fact, inference, hypothesis, and recommendation before the prompt even exists. That distinction sounds academic until you’ve watched a model confidently blend a guess with a fact in the same sentence and hand it to a client as one clean answer. Separating those categories at the design stage means the final prompt actually instructs the model to flag which is which, instead of hoping it does.
It also builds in a priority order for conflicts: safety and compliance first, truth second, main objective third, and format preferences dead last. That ordering alone solves a problem most prompt authors never think about until something breaks in production. Picture a prompt that asks for a punchy one-liner and also asks for full legal disclaimers. Without a stated priority, the model guesses which one wins. With FUP-1’s ordering baked in, the disclaimer wins every time, and nobody has to debug why the output changed between runs.
Use Cases 🎯
- Building prompt libraries for a team where consistency across authors matters more than speed, especially when five or six people are all writing prompts that need to sound like one voice
- Client work where you need to document assumptions and risks, not just deliver a prompt, so if something goes wrong later you can point to exactly which assumption broke
- Any prompt you expect to reuse for months and will regret not versioning properly, the kind that quietly becomes load-bearing infrastructure without anyone planning for it
Prompt of the Day
You don’t need the full 16-section ceremony every time. Steal the core discipline instead: “Before answering, tell me what’s fact, what’s inference, what’s a hypothesis, and what’s a recommendation in your response. Flag any assumption you’re making that I haven’t confirmed.” That one line catches more silent errors than most people’s entire prompt review process, and it costs you nothing more than pasting it in.
Try This Today
Next time you write a prompt you plan to reuse, spend two minutes writing down its objective, scope, and one thing that could go wrong before you touch the actual wording. That’s FUP-1 in miniature, and it costs you almost nothing. Do it three or four times and you’ll start catching the gaps in your prompts before they ever reach a teammate or a client, which is a much cheaper place to catch them than after the fact.
Prompt: Framework Universal para Planejamento e Engenharia de Prompts (FUP-1)
by u/Ornery-Dark-5844 in PromptEngineering