Menu
When to use deterministic server-side WebSocket signals instead of client-side heuristics for UI state transitions
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | deterministic-ws-signals |
| description | When to use deterministic server-side WebSocket signals instead of client-side heuristics for UI state transitions |
When the client needs to know about server-side state transitions (e.g., new sampling turn, new message bubble), always use a deterministic server-emitted WebSocket event rather than client-side heuristics (time gaps, content analysis).
The server knows exactly when state changes occur. Client-side heuristics — time-based gap detection, content-based analysis — are fragile and produce inconsistent behavior across different network conditions and workloads.
Emit a lightweight event (e.g., agent:response_start) synchronously before the async operation begins. WebSocket in-order delivery guarantees the event arrives before any data from the new state.
// Server-side: emit signal before starting new turn
ws.emit('agent:response_start', { agentId, turnId });
await agent.processNextTurn(); // data follows the signal
How the multi-backend adapter system works — AgentAdapter interface, ACP protocol, session resume, and how to add new provider adapters
When debugging why an agent has the wrong provider/model, or when modifying agent creation or delegation flows.
How to get agents to use group chats for peer coordination in flightdeck-based crews. Covers hub-and-spoke anti-pattern, auto-grouping triggers, and file-lock-linked groups. Use when setting up multi-agent crews with 3+ agents or diagnosing why agents aren't collaborating directly.
When fetching from the `/coordination/activity` API and you only need specific action types (e.g., `progress_update`, `task_completed`, `delegated`).
When fetching activity data for UI display, or debugging why activity-based features show empty/stale data.
Architecture decisions and patterns from Flightdeck development (Phases 2–4). Covers feature architecture, state management, component patterns, and API design.