Firebase Platform

"Auth is the front door; security rules are the lock; cost is the rent." — platform lens [INFERENCE]

TL;DR

Implements and operates applications on Firebase — the GCP-managed serverless stack — across capabilities: Authentication, Cloud Functions, Firestore security rules, Firestore query/index optimization, Hosting, Cloud Storage, scheduled jobs, the local emulator suite, and cost control. Use when the target platform is Firebase; for the sibling platforms use vercel-platform or hostinger-platform. [EXPLICIT]

When to use

• Standing up or extending a Firebase project: Auth providers, Firestore, Functions, Hosting, Storage. [EXPLICIT]
• Writing or auditing Firestore security rules (the Firebase-specific authorization DSL). [EXPLICIT]
• Optimizing Firestore queries and indexes, or cutting Firestore/Functions/Storage cost. [EXPLICIT]
• Wiring the emulator suite for deterministic local dev and CI. [EXPLICIT]
• NOT for raw GCP IAM/networking outside Firebase's surface, and NOT for data modeling — that is database-design (this skill consumes the model). [INFERENCE]

Sub-capabilities (resource map)

Read exactly the playbook you need — each is a self-contained, evidence-tagged reference. Do not load the whole set at once. [INFERENCE]

Procedure

1. Resolve the capability from the request; open the one matching references/*.md. [EXPLICIT]
2. Discover current project shape: firebase.json, firestore.rules, firestore.indexes.json, Functions runtime. [CONFIG]
3. Apply the playbook's decision tables; pick persistence/trigger/index strategy explicitly. [EXPLICIT]
4. Validate with the emulator before deploying; never set custom claims client-side; confirm rules deny-by-default. [DOC]
5. Cost-check any new read/write/listener pattern against references/cost-optimization.md. [INFERENCE]

Quality Criteria

• Security rules are deny-by-default and enforce custom claims server-side. [DOC]
• Every Firestore query has a supporting index; listeners are detached on unmount. [DOC]
• Custom claims propagation lag (~1h / token refresh) is handled explicitly. [DOC]
• Emulator covers Auth + Firestore + Functions before any deploy. [DOC]
• All claims tagged with evidence markers. [EXPLICIT]

Anti-Patterns

• Setting custom claims from the client (must be Admin SDK in a Function). [DOC]
• Security rules that get() documents on every check without cost awareness. [INFERENCE]
• Unbounded onSnapshot listeners leaking reads and memory. [INFERENCE]

Contract

• Aceptación: capability resuelta a un playbook; rules deny-by-default; queries indexadas; validado en emulador; costo revisado. [EXPLICIT]
• Límites: construye sobre la superficie Firebase; no GCP IAM/networking crudo; no modela datos (eso es database-design). [EXPLICIT]
• Casos borde: claims >1000 bytes → mover a Firestore role doc; propagación de claims ~1h → forzar getIdToken(true). [DOC]
• Supuestos: proyecto Firebase ya inicializado (firebase.json presente). [SUPUESTO]
• Trade-off: serverless gestionado (cero-ops, escala) a cambio de lock-in y costo por-operación que exige diseño cost-aware. [EXPLICIT]

Related Skills

• vercel-platform, hostinger-platform — sibling target platforms (Platform Lens). [EXPLICIT]
• database-design — produces the data model this skill implements. [EXPLICIT]
• application-security — cross-cutting auth/RBAC/headers beyond Firebase rules. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · assets/ recursos estáticos.