Every AI interface ships the same input: a blank field. No structure, no guidance, no opinion about what a good prompt looks like. The result is predictable. People type the first thing that comes to mind, get a mediocre response, spend three more messages fixing it, and blame the model.
The model is usually fine. The prompt is the problem. And the prompt is the problem because the interface doesn't care about it.
Omo: build it, use it, learn what's wrong
This started as a tool called Omo. Structured prompting, eight input fields, every feature I could think of. I used it enough to learn which parts mattered and which parts I was pretending to need.
The core insight held up: even light structure improves prompt quality noticeably. The execution didn't. The things I kept skipping told me everything the spec couldn't.
Nobody went back to previous versions. Cut. The clickable recommendations re-triggered compilation on every click, creating a feedback loop pretending to be a feature. Cut. Output format had its own field, but I always just wrote it into the task. Cut. Same with input/examples. Cut. Reasoning nudge existed because it sounded useful. Actual usage: zero. Cut.
The submit button was the last to go. It felt like the one thing you're supposed to have. But if the tool already knows when you've stopped typing, what's the button for?
What remained: the core idea (structure produces better prompts), the three-panel layout, and a list of everything that was wrong with the first attempt. That's the best possible starting point for a v2.
Omo. Used it long enough to know exactly what to throw away.
Planning: start from the sibling
Rei has an older sibling called Ordos, a local-first PRD generator built a few months earlier. Same philosophy, same stack. The first real decision was to mirror Ordos's design system rather than start fresh. Its visual language, its state machine pattern, its local model integration. All reusable. All tested.
This prevented the thing that kills most personal projects: spending three weeks picking colors and redesigning buttons instead of solving the actual problem. Everything in Rei that looks like a deliberate aesthetic choice is borrowed. The originality budget went entirely to what the tool does.
The PRD came next. Written before any code, partly to clarify thinking, partly because the developer was going to be Claude Code, and a model implementing a spec needs the spec to be precise. Every handwave becomes a bug. Every "you know what I mean" becomes a guess. Writing for that audience turned out to be excellent discipline for writing specs in general.
The spec. Written for a developer that takes everything literally.
Building: three fields and no button
The build followed the PRD closely. The interesting decisions were already made; the work was execution and the inevitable surprises.
Three fields. Task and context. Persona. Constraints. If something matters, it fits in one of these. If it doesn't fit, question whether it matters.
Continuous compilation. You type, the compiled prompt updates on the right. No button. A short debounce so it doesn't fire on every keystroke, an abort mechanism so new input cancels stale requests. The practical details are boring. The effect is not: the tool stops feeling like a form and starts feeling like it's thinking alongside you.
Personas instead of role labels. "Analyst" tells the model nothing. "Product manager who keeps a list of features they're proud they cut" gives it a voice, a disposition, implicit constraints. 33 of these in a shuffleable pool, or overwrite with your own. Writing them took longer than most of the interface work. Each one has to be specific enough to shift model behavior, human enough to feel like a person, and short enough to read in one line. Copywriting disguised as a settings menu.
Passive recommendations. The engine scores your prompt and tells you what's weak. You can't click to fix. You read, you decide, you adjust. Less clever than Omo's version. More honest about who's in charge.
Local only. Ollama, your machine, your models. Nothing hits a server, nothing requires an account. The honest reason: I already pay for model access through subscriptions. Paying again for API calls to build a personal tool felt absurd.
Eight fields became three. The output got better.
Refining: what the screen taught me
This was the most painful part of the process. Claude Code can build architecture and logic reliably, but pixel-level polish is a different story. It couldn't read the designs accurately enough, and since I was on a free Figma plan there was no Developer MCP to bridge the gap. I tried providing CSS snippets alongside screenshots. Claude ignored about half of them. Most of the refinement was a loop of inspecting what it built, describing what was wrong, and watching it fix two things while breaking a third.
Most of the polish happened in the inspector, not the editor.
The result
It does one thing, locally, without asking you to create an account. That's the product. The process behind it was simpler than it looks: build it, use it, notice what you never touch, cut that, repeat. Every feature Rei doesn't have is a feature Omo had that I ignored. Prompting is a design problem. A blank field produces careless input. A little structure fixes that. Nobody needs a tutorial. They need a better form.