What this prompt does
This prompt casts the AI as a senior front-end engineer building real-time clinical UIs, and it asks for working component code for a telehealth video consultation screen rather than pseudocode. It specifies a main video with picture-in-picture self-view and a connection-quality indicator, a side panel of patient info, vitals, and medications, in-call chat plus file share, controls including escalation/handoff, distinct patient vs provider layouts driven by a role prop, and a low-bandwidth fallback. The [views] placeholder sets which roles are designed, and [panel_data] decides the side-panel contents.
The structure works because video consults are unforgiving: a dropped track mid-appointment is a clinical problem, not a cosmetic glitch. The prompt forces the fallback path to be a first-class deliverable, including audio-only mode, reconnect handling, and degraded-state messaging tuned to the [network_target]. A single role prop drives both layouts so patient and provider views stay in sync, and the [stack] variable produces a component tree, props, and the WebRTC track event hooks to wire. Driving both roles from one prop avoids the common trap of maintaining two diverging screens, so a fix to the call controls or the connection indicator lands for patient and provider at once rather than drifting out of parity over time.
When to use it
- Building a telehealth or video consultation screen
- Designing distinct patient and provider
[views]from one role prop - You need a side panel of
[panel_data]like patient info, vitals, and medications - Supporting a challenging
[network_target]with an audio-only fallback - Adding in-call chat, file share, and an escalation/handoff control
- Generating WebRTC track event hooks alongside the component tree
Example output
You get a component tree, props/types, and the WebRTC track event hooks you need to wire. The main video includes picture-in-picture self-view and a connection-quality indicator; the side panel renders patient info, vitals, and medications; controls cover mute, camera, end call, and escalation; and a single role prop switches between patient and provider layouts. The low-bandwidth fallback spells out audio-only mode, reconnect handling, and degraded-state messaging.
Pro tips
- Set
[views]to the roles you actually ship; the prompt drives both from one role prop, so naming them keeps the layouts aligned - Tailor
[panel_data]to the clinical context; the side panel renders exactly what you list - Treat the fallback as primary: ask the model to build the
[network_target]audio-only and reconnect path first, since that keeps the call alive - Keep
[stack]accurate so the WebRTC track hooks match your RTC library - If the connection-quality indicator is vague, ask for explicit degraded-state messaging thresholds
- Request that escalation/handoff define what state transfers, since a clinical handoff needs continuity
