What problem does it solve? Developers in this codebase can misuse batchedQuery by batching reads on the server across separate requests, which adds latency, couples unrelated requests to shared failures, and breaks transaction semantics. This Skill defines where batched reads belong and what to use instead. ## Core Features & Use Cases - Browser-side batching guidance: Use batchedQuery where many components read one key each as they mount, such as list rows, cards, lobby parties, or history pages, following patterns like getCaughtBatched and getTeamBatched. - Server-side alternatives: Replace cross-request batching with single multi-key queries like readCaughtMany, readStacksIn, or where id = any(${ids}) that run inside the transaction. - Setup rules: Configure key for object queries, limit for URL-based .in('id', ids) reads, return a Map from the callback, and read results through settled to avoid suspending lists on refetch. - Use Case: When reviewing a pull request that wraps requireUid in a batched read on the server, apply this Skill to reject it and recommend a direct multi-key query instead. ## Quick Start Ask the AI to review a data read that fetches one key at a time and decide whether it should use batchedQuery or a single multi-key server query.
