Firebase backend expert across Authentication, Firestore, Realtime Database, Cloud Functions, Cloud Storage, Hosting, and security-rule design for denormalized read-heavy data. USE WHEN building or securing an app on Firebase/Firestore.
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.
A direct command skips the review prompt. Inspect the source before running it.
Firebase backend expert across Authentication, Firestore, Realtime Database, Cloud Functions, Cloud Storage, Hosting, and security-rule design for denormalized read-heavy data. USE WHEN building or securing an app on Firebase/Firestore.
cluster
ai-agents-meta
version
1.0.0
origin
antigravity-awesome-skills (MIT)
risk
unknown
source
vibeship-spawner-skills (Apache 2.0)
date_added
"2026-02-27T00:00:00.000Z"
Firebase
Firebase gives you a complete backend in minutes - auth, database, storage,
functions, hosting. But the ease of setup hides real complexity. Security rules
are your last line of defense, and they're often wrong. Firestore queries are
limited, and you learn this after you've designed your data model.
;
}
This skill covers Firebase Authentication, Firestore, Realtime Database, Cloud
Functions, Cloud Storage, and Firebase Hosting. Key insight: Firebase is
optimized for read-heavy, denormalized data. If you're thinking relationally,
you're thinking wrong.
2025 lesson: Firestore pricing can surprise you. Reads are cheap until they're
not. A poorly designed listener can cost more than a dedicated database. Plan
your data model for your query patterns, not your data relationships.
Principles
Design data for queries, not relationships
Security rules are mandatory, not optional
Denormalize aggressively - duplication is cheap, joins are expensive
Batch writes and transactions for consistency
Use offline persistence wisely - it's not free
Cloud Functions for what clients shouldn't do
Environment-based config, never hardcode keys in client
"""
Rules are your last line of defense. Every read and write
goes through them. Get them wrong, and your data is exposed.
"""
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Helper functions
function isSignedIn() {
return request.auth != null;
}
function isOwner(userId) {
return request.auth.uid == userId;
}
function isAdmin() {
return request.auth.token.admin == true;
}
// Users collection
match /users/{userId} {
// Anyone can read public profile
allow read: if true;
// Only owner can write their own data
allow write: if isOwner(userId);
// Private subcollection
match /private/{document=**} {
allow read, write: if isOwner(userId);
}
}
// Posts collection
match /posts/{postId} {
// Anyone can read published posts
allow read: if resource.data.published == true
|| isOwner(resource.data.authorId);
// Only authenticated users can create
allow create: if isSignedIn()
&& request.resource.data.authorId == request.auth.uid;
// Only author can update/delete
allow update, delete: if isOwner(resource.data.authorId);
}
// Admin-only collection
match /admin/{document=**} {
allow read, write: if isAdmin();
}
}
}
Data Modeling for Queries
Design Firestore data structure around query patterns
When to use: Designing Firestore schema
FIRESTORE DATA MODELING:
"""
Firestore is NOT relational. You can't JOIN.
Design your data for how you'll QUERY it, not how it relates.
"""
// WRONG: Normalized (SQL thinking)
// users/{userId}
// posts/{postId} with authorId field
// To get "posts by user" - need to query posts collection
// RIGHT: Denormalized for queries
// users/{userId}/posts/{postId} - subcollection
// OR
// posts/{postId} with embedded author data
// Document structure for a post
const post = {
id: 'post123',
title: 'My Post',
content: '...',
When to use: Multiple document updates that must succeed together
BATCH WRITES AND TRANSACTIONS:
"""
Batches: Multiple writes that all succeed or all fail.
Transactions: Read-then-write operations with consistency.
Max 500 operations per batch/transaction.
"""
// GOOGLE
const googleProvider = new GoogleAuthProvider();
googleProvider.addScope("email");
googleProvider.setCustomParameters({ prompt: "select_account" });
async function signInWithGoogle() {
try {
const result = await signInWithPopup(auth, googleProvider);
return result.user;
} catch (error) {
if (error.code === "auth/account-exists-with-different-credential") {
return handleAccountConflict(error);
}
throw error;
}
}
// GITHUB
const githubProvider = new GithubAuthProvider();
githubProvider.addScope("read:user");
// APPLE (Required for iOS apps!)
const appleProvider = new OAuthProvider("apple.com");
appleProvider.addScope("email");
appleProvider.addScope("name");
if (methods.includes("google.com")) {
alert("Sign in with Google to link accounts");
const result = await signInWithPopup(auth, new GoogleAuthProvider());
await linkWithCredential(result.user, pendingCred);
return result.user;
}
}
// Link new provider
await linkWithPopup(auth.currentUser, new GithubAuthProvider());
// Unlink provider (keep at least one!)
await unlink(auth.currentUser, "github.com");
Auth State Persistence
Control session lifetime
When to use: Managing user sessions
import { setPersistence, browserLocalPersistence, browserSessionPersistence } from "firebase/auth";
// LOCAL: survives browser close (default)
// SESSION: cleared on tab close
