TL;DR: A Redditor built a “dispatcher” prompt that assigns a specialist role before ChatGPT writes a word, so messy requests get one focused answer. Picture a request that’s part writing, part troubleshooting, part planning, all packed into a single message. This Redditor, who posts as RhinoCK301 in r/ChatGPTPromptGenius, kept watching the model try to answer all three at once. The result was broad, uneven, and never quite as useful as a request that stayed in one lane. So the fix wasn’t better prompting. It was a routing step that runs before the actual answer. 🧭
How the Dispatcher Works
The prompt turns the model into an operator first and a specialist second. Before it drafts anything, it works through four moves:
- Reads the message and figures out the primary intent, the thing the user actually wants
- Matches that intent to one role from an editable list, covering ten specialties from Software Engineering to Marketing
- Notes any secondary needs so they don’t get lost once the model picks a lane
- Asks only the clarifying questions that would actually change the response, not a checklist for its own sake
Then it answers in that role’s voice. One detail matters more than the framework itself. The author’s first version stopped after printing the intent and the chosen role, a tidy summary that still needed a second message before anything useful happened. Fixing that meant telling the prompt explicitly to execute the task after routing, not just describe the route. Route first, answer second, in the same reply. There’s also a volume knob. Showing the routing breakdown is handy when you’re debugging a tangled prompt, but it’s clutter on a quick rewrite or a factual question. The author made that section optional so simple asks don’t drag a routing report behind them.
Why It Works
This is role assignment with a gate in front of it. Instead of hoping the model infers the right persona from context, the prompt forces an explicit intent check before any drafting starts. That’s the same instinct behind chain-of-thought prompting: separate the reasoning step from the output step so neither gets rushed. The editable role list in Section 6 is the part worth stealing even if you skip everything else. Swap in the specialties you actually work in and drop the rest. A shorter, accurate list routes better than a long one built to look comprehensive.
Use Cases
The author has run variations of this dispatcher across:
- Planning: breaking a vague goal into a scoped task under the Project Management role
- Writing and editing: routing tone and structure requests away from technical roles that would flatten them
- Troubleshooting: keeping a debugging thread from turning into a rewrite of your whole approach
- Technical questions: pulling a request into Data Analysis or Software Engineering instead of a generalist answer
One commenter, u/zhongzhir, added a guardrail worth borrowing: have the model state the chosen role and its single next action before drafting. It keeps the routing useful without turning a one-line request into a meta-analysis.
Prompt of the Day
You are a dispatcher/operator AI assistant. Your job is to listen to the user’s request and route it to the most appropriate specialized role.
1. Inputs
You will receive a user message containing a problem, question, or task.
Optionally, you may receive context such as goals, constraints, prior attempts, or preferences.
2. Core Task (Routing)
1. Read the user’s message and determine the primary intent (what the user is trying to accomplish).
2. Identify required expertise (e.g., coding, writing, analysis, troubleshooting, planning, tutoring, etc.).
3. Choose the best matching role specialization from the available set.
4. If multiple roles are relevant, pick the highest-priority one and briefly note secondary needs.
5. If the user’s request is ambiguous or missing key details, ask the minimum necessary clarification questions before routing.
3. Role Selection Rules
Prefer the role whose specialty most directly addresses the user’s intent.
If the user asks for something that spans multiple domains, route to the role best suited for the primary objective and request any missing cross-domain details.
If the user request is out of scope for all known roles, respond with what you can do and suggest the most suitable alternative.
4. Output Format
Always respond in the following structure:
A) Detected Intent (One concise sentence describing what the user wants.)
B) Chosen Specialized Role (Role name from the available set.)
C) Routing Instructions for That Role
– (Bullet points)
– The key requirements, constraints, and success criteria extracted from the user message.
– Any assumptions you are making.
D) Clarifying Questions (If Needed)
– Only include questions if required to route correctly or to complete the task.
5. Style and Safety
Be concise and directive.
Do not fabricate capabilities or role names.
If user asks for disallowed or unsafe content, refuse and offer a safe alternative.
6. Specialized Roles Available
Use the following role names as the routing targets:
Software Engineering Specialist
Data Analysis Specialist
Writing & Editing Specialist
Customer Support & Troubleshooting Specialist
Tutoring & Study Planner Specialist
Project Management & Planning Specialist
Design & UX Specialist
Legal & Compliance Guidance Specialist
Marketing & Growth Specialist
General Knowledge / Q&A Specialist
7. Start Here
Given the user message, follow sections 2, 4 and produce the routing response. Drop this at the top of a fresh chat, or paste it as a system message where that option exists. Then send your actual request. It routes first, answers second, and it doesn’t need you to explain yourself twice.
Two changes are worth making before you lean on it. Tell it explicitly to execute the task after routing, not just summarize the route. And trim Section 6 down to the roles you actually use, not the ten listed here. I was surprised how much cleaner the output got just from forcing that routing step. It’s not magic, and it won’t make the model smarter than it already is. It just stops one message from trying to be five different assistants at once. Head over to the original thread in r/ChatGPTPromptGenius for the full discussion, including which models people have tested it against.
Frequently Asked Questions
Q: Which models work best with this dispatcher?
Both ChatGPT and DeepSeek have tested well with this prompt, and it should work with most modern models. The key is testing it with your primary model to see whether it handles mixed-domain requests cleanly. If you find consistency issues, you can adjust the role list or routing instructions to match how that specific model responds.
Q: Won’t the routing step add overhead or turn simple requests into lengthy meta-analysis?
It could if left unchecked, but there’s a simple fix: ask the model to state which role it’s choosing and its single next action before drafting. This keeps routing focused and transparent without turning straightforward requests into analysis paralysis. For simple, single-intent requests, most models route quickly and efficiently.
Q: Can I customize the roles for my own work?
Absolutely. The role list is deliberately editable, swap the examples in Section 6 for specialties that fit your workflow, whether that’s design review, customer support, marketing analysis, or anything else. Keep the core routing logic the same; it’s the role definitions that adapt to your needs.
Q: When does this approach actually help?
It shines with complex, multi-part requests that span different domains (like “write a plan, then troubleshoot a code issue, then suggest improvements”). For straightforward, single-intent requests, the routing adds minimal value. It’s most useful when you’re working with loosely written or ambiguous requests that benefit from a focusing step first.
I use this “dispatcher” prompt to stop AI models from trying to solve every part of a request at once
by u/RhinoCK301 in ChatGPTPromptGenius