firebase-ops

name	firebase-ops
description	Plan, configure, implement, verify, and operate Firebase for React/Vite web apps. Use when Codex needs to handle Firebase Hosting, Auth, Firestore, Security Rules, Cloud Functions for Firebase, Local Emulator Suite, Firebase CLI, Google Analytics, Remote Config, A/B Testing, env config, GitHub Actions deploys, launch checklists, or human Firebase setup tasks.

Firebase Ops

Freshness

These instructions are based on official Firebase documentation reviewed on 2026-06-24. The referenced Firebase docs pages used for this skill showed "Last updated 2026-06-22 UTC" for Web setup, CLI, Hosting GitHub integration, Cloud Functions, Remote Config, A/B Testing, and Local Emulator Suite. Re-check official Firebase docs before changing production deployment, billing, IAM, security rules, or CLI behavior.

Goal

Make Firebase work boringly and safely for a small web app: explicit setup tasks, env-driven config, emulator-first development, least-privilege rules, repeatable deploys, clear docs, and verifiable production readiness.

Default Stack

Assume a React app running on Vite unless the repo shows otherwise. Prefer:

• Firebase Hosting for static SPA hosting.
• Firebase Auth for identity.
• Firestore for app data.
• Cloud Functions for trusted server work, webhooks, scheduled tasks, and privileged mutations.
• Firebase Analytics / Google Analytics for event measurement.
• Remote Config for runtime flags and copy/variant changes.
• Firebase A/B Testing for experiments backed by Analytics.
• Local Emulator Suite for local Auth, Firestore, Functions, Hosting, and rules testing.
• Firebase CLI for project initialization, emulators, deploys, and CI integration.
• GitHub Actions deploys for preview channels and production deploy on merge to main.

Workflow

1. Inspect the repo. Identify framework, package manager, build output directory, existing Firebase files, CI config, environment handling, tests, and docs. Do not overwrite user config without reading it.

2. Classify the task. Use references/task-routing.md to decide whether this is setup, implementation, security, testing, deployment, analytics, or operations.

3. Separate human setup from code work. Human setup includes Firebase project creation, billing plan choice, domain ownership, Google Analytics property decisions, service account or workload identity setup, GitHub secrets, auth provider enablement, production data changes, and legal/compliance decisions.

4. Implement with env-driven config. Keep Firebase web config values in environment variables exposed through the app's build system. For Vite, prefer VITE_FIREBASE_* values read by a small firebase.js or firebase.ts module. Do not commit .env files containing real values.

5. Use emulators before production. Add or update emulator config when touching Auth, Firestore, Functions, Hosting, or rules. Prefer repeatable scripts and document the local workflow.

6. Protect data with rules and server boundaries. Treat client code as untrusted. Put privileged mutations, payment/webhook handling, admin actions, email sending, and secret-bearing integrations in Cloud Functions.

7. Make deployment repeatable. Add GitHub Actions only after repo build/test commands are known. Use preview deployments for pull requests when useful and production deploys only from main.

8. Verify and document. Run available tests/builds. Update docs/firebase.md, docs/env.md, or relevant docs with setup, local development, deploy, and rollback notes.

Reference Files

• Read references/task-routing.md for selecting the right Firebase workflow.
• Read references/setup-checklist.md before planning a new Firebase project or human setup tasks.
• Read references/config-and-security.md before editing config, rules, functions, secrets, or env docs.
• Read references/deploy-and-ci.md before creating Firebase Hosting or GitHub Actions deploy work.
• Read references/analytics-experiments.md before planning Analytics, Remote Config, or A/B Testing.

Operating Rules

• Never put Firebase Admin credentials, service account JSON, API secrets, Stripe secrets, Resend secrets, or CI tokens in committed files.
• Do not assume Firebase web config values are secret, but still keep them environment-specific and documented.
• Do not deploy to production unless the user explicitly asks and required credentials are available.
• Do not change live rules, data, indexes, Remote Config, experiments, domains, or auth providers without making the impact explicit.
• Prefer Firebase Functions v2 patterns for new Cloud Functions unless the repo already standardizes on v1.
• Prefer small single-purpose files: one Firebase initialization module, one service module per product area, one function per operation or tightly related group.
• Add acceptance criteria and verification notes for every Firebase issue or task.

Outputs

For planning tasks, produce:

• Firebase architecture summary.
• Human setup checklist.
• Repo changes required.
• Environment variables and secrets list.
• Emulator and test strategy.
• Deployment plan.
• Risks and rollback notes.

For implementation tasks, produce:

• Scoped code/config changes.
• Updated docs.
• Tests/build verification.
• Any manual Firebase Console steps that remain.