Firestore

Purpose

Design Firebase databases around access patterns, rules, sync and cost.

When to use

• Modeling Firestore collections or Realtime Database paths.
• Adding queries, listeners, transactions or batch writes.
• Writing or auditing Security Rules.
• Designing caregiver/patient, team, role or ownership access.

Inputs to inspect

• Entities and access patterns.
• Readers, writers and roles.
• Queries, indexes and listener frequency.
• Current firestore.rules/database.rules.json.
• Expected data volume and offline needs.

Required workflow

1. List access patterns before schema.
2. Choose paths/collections and denormalization intentionally.
3. Design rules with schema and roles.
4. Identify indexes and cost-sensitive listeners.
5. Add repository code and emulator allow/deny tests.

Rules

• Rules are part of the feature, not an afterthought.
• Do not trust client-provided owner fields alone.
• Validate required fields, types and immutable fields.
• Use transactions for invariants.
• Mention cost risks for broad listeners.

Related existing skills

Local skills to invoke

• firebase-core
• firestore-costs-quotas
• security-privacy
• firebase-emulator-ci
• testing

External companion skills to use when installed

Do not assume these companion skills are installed. Prefer the local skills above first, then consult [Companion Skills](../../docs/COMPANION_SKILLS.md) for install and verification commands.

• firebase/agent-skills — use for deeper Firebase product, Firestore, Security Rules or emulator workflow guidance when installed.

Files commonly touched

• firestore.rules
• database.rules.json
• indexes config
• repository/data source files
• Firebase emulator tests

Commands to validate

firebase emulators:start
firebase emulators:exec "npm test"
./gradlew test
./gradlew assembleDebug

Common mistakes to avoid

• Open rules.
• Queries that rules cannot authorize.
• Missing indexes.
• Unbounded realtime listeners.
• Denormalization without write strategy.

Checklist

• Access patterns documented.
• Rules least-privilege.
• Indexes considered.
• Offline behavior defined.
• Cost risks mentioned.

Example prompts

• Use $super-android-kotlin-firebase to design Firestore for patients and caregivers.
• Use $super-android-kotlin-firebase to audit these Firestore rules.

Expected response style

Respond with: brief diagnosis, change plan, affected files, code or diff summary, validation commands, tests added or recommended, risks, and next step. For review tasks, lead with findings ordered by severity.

References

• ../../docs/audits/FUENTES_LOCALES.md
• references/firestore-data-modeling.md
• references/security-rules-patterns.md
• templates/firestore-rules-template.md

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: GDvega
• Source: GDvega/super-android-kotlin-firebase-skill
• License: MIT

Install and usage instructions live in the source repository linked above.