A developer sat down to build an AI dating tool. Eight modules, slash commands, and 24 kilobytes of system prompt later, EROS was born: a skill file that turns any LLM into a dating coach with commands like /opener, /reply, /decode, and /profile-review. Each command does one thing, routes to one module, and returns output in a format that is actually usable by a human being trying not to embarrass themselves on a first date.
The dating angle is funny. The prompt engineering underneath is genuinely good.
🧠 Why This Matters
Most people building complex system prompts hit the same wall: the bigger the prompt gets, the messier the outputs. Modules start bleeding into each other. You ask for a date idea and get unsolicited personality analysis. You ask for an opener and the AI somehow loops back to attachment theory. The AI just kind of wanders.
This is not a model problem. It is a structure problem. And it gets worse fast. Each new capability you add creates new surface area for the model to misroute, misinterpret, or cross-contaminate. By the time you hit 15KB of instructions, you are basically herding cats. At 24KB, this project had to solve that problem or it would be completely useless. Here is how it did.
📐 Five Lessons From the Architecture
1. Isolate modules with explicit headers and scope definitions. Every module in EROS has a name, a scope, and activation triggers. Slash commands route directly to one specific module. This alone cut context bleed significantly. No wandering. Think of it like giving each part of your system its own door and locking the others. The model does not get to wander the halls.
2. Output templates beat vague instructions. Telling the AI to “analyze her message” gives inconsistent garbage. Telling it to “analyze on three layers: SURFACE (literal content), STRATEGIC (subtext and intent), EMOTIONAL (what she is probably feeling)” gives the same useful structure every single time. Rigid format equals reliable output. This is especially important when you are handing results to a user who needs to act on them quickly. A consistent format they can scan beats a thoughtful paragraph they have to decode.
3. Give calibrated options, not a single best answer. The /reply command returns three responses: Conservative, Balanced, Bold. Each one includes a risk level and an explanation of the psychology behind it. Users match the option to their comfort zone. That is coaching, not an oracle. It also removes the awkward moment where the AI confidently hands you something you would never actually say. Giving three options with context puts the human back in control of the final call.
4. Bake ethics into the structure, not just the instructions. Saying “do not help with manipulation” does not work. The model has no reliable way to classify what counts as manipulation without more context. EROS defines manipulation with specific examples (negging, guilt-tripping, love-bombing), routes those requests to a dedicated ethics module, and explains why those tactics fail long-term. Structural constraints hold. Instructional ones do not. This principle applies well beyond dating tools. Any system handling sensitive output needs guardrails built into the architecture, not bolted on as afterthoughts.
5. Always explain the why, not just the what. Every response in EROS includes the reasoning behind it. The explicit goal is to make users understand principles well enough that they stop needing the tool. That is the difference between a coach and a dependency machine. It also happens to make the outputs more trustworthy. When the AI shows its work, users can evaluate whether the logic holds instead of just accepting the result.
💡 Tips and Tricks
Build and isolate one module at a time. Get one command working cleanly before adding the next. Mixing everything into one block from the start is how you get context contamination baked in from day one. Start narrow, verify behavior, then expand.
Define what you do not want as precisely as what you do. Vague negative constraints fail. Specific examples hold. If you want to prevent a certain type of output, describe that output concretely rather than gesturing at it abstractly. The more concrete you get, the less the AI has to guess.
Test each command independently. If your modules share a long context window, run isolated tests per command to catch bleed-through before it compounds into something hard to trace. A ten-minute test session per module saves hours of debugging later when everything is tangled together.
Version your prompts like code. When a module starts misbehaving after edits elsewhere, you want to be able to diff what changed. Prompt files in version control is not overkill. It is just good practice once your system crosses a few thousand words.
🚀 Go Build Something
The EROS repo is MIT licensed and free. The dating use case is niche, but the prompt architecture is worth an hour of your time if you are building anything with multiple modes, command routing, or modules that need to stay in their lane. Study the structure first. The content is almost beside the point.
The real takeaway here: complexity in AI prompts is not managed by writing more instructions. It is managed by better structure. Less wandering. More walls.
I engineered a comprehensive dating coach system prompt (24KB, 8 modules, slash commands). Here’s the architecture and what I learned about complex prompt design.
by u/AbrocomaAny8436 in PromptEngineering