What this prompt does
This prompt makes the model a senior front-end engineer building real-time control dashboards and asks it to specify a robotics fleet dashboard tightly enough to build, returning working component code rather than pseudocode. It defines six deliverables: a fleet map with status-colored robot pins, a per-robot panel showing telemetry, task, and alerts, a command queue with pending/sent/acknowledged states, an error log with severity, filtering, and acknowledge, OTA update status across the fleet, and an emergency-stop control with confirmation and a clearly visible stopped state. The structure works because it treats real-time supervision as unforgiving — a laggy or ambiguous status pin can mean a robot keeps moving when an operator thinks it stopped.
Four variables shape it. [stack] sets the framework (default Next.js + WebSocket). [telemetry] lists the per-robot fields like battery, location, task, and alerts that the panel renders. [transport] defines the real-time channel, such as WebSocket with reconnect, which drives the live update wiring. [fleet_size] sets the expected scale, up to 200 robots, informing how pins and panels are rendered at volume. The emergency stop is the most important control: the prompt insists it be impossible to miss and impossible to mis-fire, since the e-stop is the one action that must never be ambiguous.
When to use it
- You are building a real-time dashboard to supervise a fleet of autonomous robots or vehicles.
- A human operator monitors machines live and needs unambiguous status at a glance.
- You need a command queue that distinguishes pending, sent, and acknowledged states.
- An error log with severity, filtering, and acknowledge is part of the workflow.
- You want OTA update status visible across the whole fleet with version and progress.
- A safety-critical emergency stop with confirmation and a visible stopped state is required.
Example output
Expect components in your [stack], props/types, and the WebSocket event/message shapes to wire. The fleet map colors robot pins by status (active, idle, charging, error); a per-robot panel shows [telemetry], current task, and active alerts; a command queue tracks pending/sent/acknowledged; an error log offers severity, filtering, and acknowledge; OTA status spans the fleet with version and progress; and an emergency-stop control includes confirmation and a clearly visible stopped state. It targets [fleet_size] scale and gives you a buildable scaffold over your [transport], not a finished system.
Pro tips
- List the exact
[telemetry]fields you receive so the per-robot panel renders real data, not placeholders. - Set
[transport]to your true channel — WebSocket with reconnect behaves differently from polling for live status. - Use a realistic
[fleet_size]so the model considers rendering and performance at your actual scale. - Make the emergency stop impossible to miss and impossible to mis-fire; it is the one control that must never be ambiguous.
- Verify the command queue distinguishes sent from acknowledged, since an unconfirmed command is a real safety gap.
- If status pins feel laggy in concept, re-run asking how stale telemetry is detected and reflected on the map.
