菜单
Use this skill when designing, reviewing, or operating Firebase systems across Auth, Firestore, Realtime Database, Storage, Functions, Hosting, App Check, and related security boundaries.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/diegosouzapw/awesome-omni-skills --skill firebase-v2命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Daily Gift workflow skill. Use this skill when the user needs Relationship-aware daily gift engine with five-stage creative pipeline — editorial judgment, synthesis, concept generation, visual strategy, and rendering in H5, image, or video and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
Daily Gift workflow skill. Use this skill when the user needs Relationship-aware daily gift engine with five-stage creative pipeline — editorial judgment, synthesis, concept generation, visual strategy, and rendering in H5, image, or video and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
High-Agency Frontend Skill workflow skill. Use this skill when the user needs building high-agency frontend interfaces with strict design taste, calibrated color, responsive layout, and motion rules and the operator should preserve the upstream workflow, copied support files, and provenance before merging or handing off.
基于 SOC 职业分类
| name | firebase-v2 |
| description | Use this skill when designing, reviewing, or operating Firebase systems across Auth, Firestore, Realtime Database, Storage, Functions, Hosting, App Check, and related security boundaries. |
| version | 0.0.1 |
| category | backend |
| tags | ["firebase-v2","firebase","firestore","authentication","cloud-functions","hosting","security-rules","app-check","api-integration","omni-enhanced"] |
| complexity | advanced |
| risk | caution |
| tools | ["codex-cli","claude-code","cursor","gemini-cli","opencode"] |
| source |
| omni-team |
| author | Omni Skills Team |
| license | Unknown |
| date_added | 2026-04-16 |
| date_updated | 2026-05-10 |
| source_type | omni-curated |
| maintainer | Omni Skills Team |
| family_id | firebase-v2 |
| family_name | Firebase |
| variant_id | omni |
| variant_label | Omni Curated |
| is_default_variant | true |
| derived_from | skills/firebase-v2 |
| upstream_skill | skills/firebase-v2 |
| upstream_author | sickn33 |
| upstream_source | community |
| upstream_pr | 271 |
| upstream_head_repo | diegosouzapw/awesome-omni-skills |
| upstream_head_sha | 93ab394af5645f7127d5003ee02c9566ae5353cd |
| curation_surface | skills_omni |
| enhanced_origin | omni-skills-private |
| source_repo | diegosouzapw/awesome-omni-skills |
| replaces | ["firebase-v2"] |
This skill preserves the upstream Firebase skill identity while curating it into an execution-focused operator guide.
Firebase is fast to start but easy to misapply. Most production issues come from a small set of repeat mistakes:
Use this skill to plan, review, implement, or troubleshoot systems involving:
Use this skill when the user needs to:
Do not default to this skill when the workload is clearly relational, requires complex joins, or needs heavy ad hoc querying. In those cases, evaluate Firebase SQL Connect or Data Connect, or a non-Firebase relational service, before forcing the data model into Firestore.
Clarify the product surface and trust boundaries
Choose the right data and backend model before implementation
Define request, auth, and authorization paths explicitly
Model Firestore collections, documents, and indexes from concrete queries
Test rules and backend behavior locally before deployment
Set production runtime controls deliberately
Review cost, observability, and rollback paths before launch
Input requirement
Users can view their own orders, sorted by createdAt descending.
Support staff can view orders for a specific store and status.
The dashboard updates live for new orders.
Recommended interpretation
collections:
orders:
fields:
userId: string
storeId: string
status: string
createdAt: timestamp
total: number
queries:
- name: user_orders
where:
userId: == auth.uid
order_by:
createdAt: desc
- name: store_status_orders
where:
storeId: == $storeId
status: == $status
order_by:
createdAt: desc
risks:
- live listeners on broad store queries can create sustained read cost
- support-staff access must be role-gated in
Expected operator decision
Scenario
A mobile app writes profile data directly to Firestore.
A backend job updates billing state using the Admin SDK.
The team enabled App Check and assumes billing writes are now protected by rules.
Correct boundary model
Mobile app -> Auth + Security Rules + optional App Check
Backend Admin SDK job -> IAM/service account permissions
Security Rules do not constrain Admin SDK writes
App Check does not replace Auth or IAM
Expected operator action
Open examples/emulator-rules-test-workflow.md when you need a concrete before/deploy validation loop for Firestore rules.
Do design Firestore from required queries, sort orders, and access paths.
Do treat Security Rules, IAM, and App Check as separate layers with different enforcement points.
Do use the emulator for rule and integration testing before production deploys.
Do keep listeners as narrow as possible and measure how often they reconnect or refetch.
Do select Functions 2nd gen region and concurrency intentionally; defaults are not always cost-safe or latency-safe.
Do use custom claims or backend-mediated access for administrative roles rather than broad client-side permissions.
Do consider Firebase SQL Connect or Data Connect when the user is asking for relational behavior.
Do not assume Security Rules filter arbitrary query results; Firestore rules are not a substitute for query design.
Do not use the Admin SDK from semi-trusted environments.
Do not assume App Check proves user identity or authorization.
Do not ship functions, indexes, or rules together without checking migration and rollback order.
Do not ignore composite index creation prompts and then treat the resulting failures as transient bugs.
Do not rely on deprecated email-link flows that depended on Firebase Dynamic Links.
Symptoms: Firestore query fails with a missing index error.
Solution: Capture the exact query shape, create the required index, and verify the query matches your intended data model. If index demands keep growing unexpectedly, revisit the schema and query design rather than layering indexes indefinitely.
Symptoms: A client can read or write data that should be blocked.
Solution: Check whether the access is happening through a client SDK or the Admin SDK. For client SDK access, review Security Rules and auth claims. For Admin SDK access, review IAM and service account usage; Rules do not enforce those requests.
Symptoms: Queries are denied even though documents seem like they should match the rules.
Solution: Re-check the query against Firestore rules semantics. Rules are evaluated against the potential result set, not used as row-level post-filters. Align the query constraints with what the rules allow.
Symptoms: Costs rise sharply after enabling real-time listeners.
Solution: Inspect listener scope, reconnect behavior, and document churn. Reduce broad listeners, paginate where possible, and confirm whether the application is re-subscribing more often than expected.
Symptoms: A Cloud Function works locally but behaves poorly in production.
Solution: Review 2nd gen runtime settings: region, concurrency, memory, timeout, min instances, networking, and secrets. Also verify service account permissions and whether the function is too close to Firestore hot paths.
Symptoms: Email-link authentication stopped working or behaves inconsistently across links.
Solution: Check whether the flow depended on Firebase Dynamic Links. That service shut down on 2025-08-25, so older integration guidance may be invalid. Confirm the current supported email-link auth implementation before patching symptoms.
Symptoms: The team keeps building join-heavy workarounds in Firestore.
Solution: Stop and reassess the product fit. The workload may belong in Firebase SQL Connect, Data Connect, or another relational backend instead of a denormalized Firestore model.
references/firestore-security-and-cost-reference.md — open this for a compact operator reference on security boundaries, read-cost drivers, App Check scope, and common Firestore production traps.examples/emulator-rules-test-workflow.md — open this when you need a concrete local test loop for Firestore rules before deployment.No related local skills were provided in the source context.