How Bluesky Starter Packs Work Under the Hood: Three Records, One Key Pitfall

Bluesky starter packs, which appear as a single shareable page in the app, are actually composed of three separate AT Protocol records: a list, individual membership items, and the pack record itself. Developers building automated pipelines must create each of these records independently using standard repo calls against their own PDS, with no batch operations available for adding members. A critical non-idempotency trap exists at creation: running a pack-creation script twice silently produces two distinct, live packs with different URLs, since the protocol assigns a fresh record key each time with no title-based deduplication. To avoid this, engineers recommend treating pack creation as a one-time, human-confirmed step, while member additions and metadata updates are handled through separate, dedupe-aware maintenance paths. Partial failures during member additions should be reported rather than raised as exceptions, so that retries remain safe and already-created records are not duplicated.