Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ericrisco/rsc-harness --skill firebasegit clone --depth 1 https://github.com/ericrisco/rsc-harnessWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ericrisco/rsc-harness/firebase)<a href="https://agentmods.dev/skills/ericrisco/rsc-harness/firebase"><img src="https://agentmods.dev/badge/skills/ericrisco/rsc-harness/firebase.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00077 | $0.03198 |
| Opus 5 | $0.00039 | $0.01599 |
| Sonnet 5 | $0.00015 | $0.00640 |
| Haiku 4.5 | $0.00008 | $0.00320 |
Grade A, and why
firebase scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 238 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Firebase — Firestore, Rules, Auth, Functions, Storage
The Firebase product surface that sits on top of GCP, on the modular Web SDK (v12) and the Admin SDK. The whole skill exists to stop two failure modes: dragging relational/SQL habits into a NoSQL document store, and leaving the database open to the internet.
Two facts drive everything below:
- It is a NoSQL document store, shaped for the read path. No joins, no server-side
ORacross different fields without a composite index, noSELECT *across collections. Denormalize and fan-out so a screen is one cheap query — reads are what you pay for and what users wait on. - Rules ARE the access control. Firestore is reachable directly from untrusted clients. There is
no app server in the trust path by default —
firestore.rules(CEL) is the only thing between a browser and your data. App Check attests the request even came from your app before Rules evaluate.
Not this skill:
| Instead of Firebase | Go to |
|---|---|
| Relational schema, SQL, EXPLAIN, indexing a SQL engine | ../postgresdb/SKILL.md |
| Managed Postgres BaaS (SQL + Postgres RLS + PostgREST) — the most-confused sibling: same "backend-as-a-service" shape, completely different data model and rules language | supabase |
| AWS document/key-value store with its own capacity model | dynamodb |
| Self-hosted Mongo document modeling | mongodb |
| Generic GCP project/IAM/billing not specific to a Firebase product | gcp-essentials |
| React/Next.js component or rendering work that merely calls Firebase | react / ../nextjs/SKILL.md |
Data modeling
Firestore charges and waits on reads. Model so the common screen is one query against one collection.
Collection vs subcollection vs root + denormalized field — decide by access pattern:
| Shape | Use when | Why |
|---|---|---|
Subcollection (rooms/{id}/messages) |
Child list is only ever read inside its parent, can grow unbounded | Subcollections don't bloat the parent doc; deleting a parent does NOT delete them (handle that) |
| Separate root collection + foreign id | Child must be queried across all parents (collection-group query) | A collectionGroup('messages') query needs the docs in same-named subcollections OR a root collection |
| Denormalized field on the parent | A few values are shown alongside the parent and rarely change | Avoids a second read; you accept writing the copy on every change |
What ships with it
6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 238 lines · 77 tokens per session scan A cac859af4fca
firebase is a skill published in the GitHub repository ericrisco/rsc-harness (65 stars, last pushed yesterday), licensed MIT. It adds 77 tokens to every session and 3,198 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
firebase
Operational skill for Firebase: Auth, Firestore/RTDB rules, Cloud Functions, FCM, Emulator Suite, and client SDK security boundaries.
firestore-better-auth
Use Firestore as the database adapter for Better Auth (Firebase Admin SDK). Use when storing Better Auth users, sessions, accounts, and verification tokens in Firestore, migrating from Auth.js/NextAuth Firebase adapter to Better Auth, setting up Better Auth with a Firebase/Firestore backend, upgrading a…
dev-supabase
Backend development with Supabase. Trigger when the user wants to configure auth, the database, or Supabase storage.
traverse-multi-hop
Expresses a multi-hop lineage question as a single variable-length path match against native graph storage, bounded by an explicit hop depth and an explicit relationship-type allowlist, instead of a recursive relational join that grows one level per hop.
transact-graph-write
Wraps every write to a shared graph edge in a transaction tied to the exact row version it was computed against, and retries a rejected write against the row's current state instead of dropping it or blindly reapplying stale values.
attach-receipts
Attaches sourcedoc/extractionrunid/schemaversion receipts to every edge at write time, and refuses to write any edge missing one of the three.