WebSocket prompts need a message contract and a lifecycle, not just a handler that receives strings. A live dashboard must decide when displayed data becomes stale. A chat client must decide whether retrying a send creates a duplicate. A collaboration tool must decide how to recover after missed updates. These prompts help make those application decisions explicit before an agent adds reconnect loops or message processing code.
Describe the connection and delivery expectations
Provide client and server code, the message envelope, authentication method and a sanitized event timeline. State what should happen when a tab sleeps, a network disappears or a credential expires. Separate the transport connection from application acknowledgement. Receiving a message on the server and completing the requested business action may be different milestones.
The WHATWG WebSockets standard defines the browser interface and its events. It does not choose your product's replay or conflict policy. The prompts below therefore ask you to supply or decide those semantics instead of assuming the transport provides them.
Specify a message envelope that can evolve
A useful envelope identifies the event, the version and how it relates to a request or stream position. Only add fields that serve a real need. Ask the agent to distinguish malformed messages from recognized messages that cannot be applied. Include a response for an unsupported version so older clients fail predictably.
Design the application message contract for {{live_feature}}.
Current messages: {{examples}}. Constraints: {{delivery_requirements}}.
Define event types, payload validation, correlation, versioning and any
sequence or deduplication identifiers we actually need. Explain error
responses and unknown-event behavior. Give valid and invalid examples.
Do not assume exactly-once business processing from the transport alone.
Plan reconnect and stale-state behavior
A reconnect plan should include the interface, not only the backoff timer. Decide whether the person can keep editing and how unsent changes are represented. Ask when a full refresh is necessary instead of replay. A sequence gap must have a resolution path, especially if the server no longer retains the missing messages.
Review reconnect behavior in {{client_path}} and {{server_path}}.
Use this interruption timeline: {{timeline}}.
Define retry limits, backoff, credential renewal, pending sends and stale
UI states. Explain replay versus full resync after a sequence gap.
Test disconnect before acknowledgement, duplicate delivery and a sleeping
tab. State which outcomes require an explicit product decision.
Test authorization beyond the initial connection
A connected socket may outlive the permissions that opened it. Provide rules for account revocation, room membership and resource ownership. Ask the agent to check subscription changes and each sensitive message type. Test two identities, including a previously authorized user whose access changes while the connection remains open.
Review authorization for {{websocket_feature}} using {{access_rules}}.
Trace connection setup, subscription changes and sensitive messages.
Test user B requesting user A's stream and an active user's access being
revoked. Define the expected close or error behavior and client recovery.
Keep credentials out of URLs and logs in the proposed examples.
Measure recovery as a user outcome
After implementing a repair, verify that a fresh connection returns to the correct state without duplicate actions. Keep a short event timeline with message identifiers and observable results. Avoid logging entire payloads when identifiers and event types provide enough diagnostic context.
Save your WebSocket review prompt in Kipt with variables for protocol, interruption timeline and access rules. Use the observability prompts to decide which connection symptoms should become metrics or actionable alerts.