Firebase Code Validation

Overview

This sub-skill validates existing Firebase code against proven patterns and security best practices. It checks configuration, rules, architecture consistency, authentication, testing, and production readiness.

Key principles:

• •Validate against chosen architecture patterns
• •Check security rules thoroughly
• •Verify test coverage exists
• •Review production readiness

When This Sub-Skill Applies

• •Conducting code review of Firebase project
• •Auditing security implementation
• •Preparing for production deployment
• •User says: "review firebase", "validate", "audit firebase", "check firebase code"

Do not use for:

• •Initial setup → firebase-development:project-setup
• •Adding features → firebase-development:add-feature
• •Debugging active errors → firebase-development:debug

TodoWrite Workflow

Create checklist with these 9 steps:

Step 1: Check firebase.json Structure

Validate required sections:

• •hosting - Array or object present
• •functions - Source directory, runtime, predeploy hooks
• •firestore - Rules and indexes files
• •emulators - Local development config

Check hosting pattern matches implementation (site:, target:, or single).

Reference: docs/examples/multi-hosting-setup.md

Step 2: Validate Emulator Configuration

Critical settings:

{
  "emulators": {
    "singleProjectMode": true,
    "ui": { "enabled": true }
  }
}

Verify all services in use have emulator entries.

Reference: docs/examples/emulator-workflow.md

Step 3: Review Firestore Rules

Check for:

• •Helper functions at top (isAuthenticated(), isOwner())
• •Consistent security model (server-write-only OR client-write-validated)
• •diff().affectedKeys().hasOnly([...]) for client writes
• •Collection group rules if using collectionGroup() queries
• •Default deny rule at bottom

Reference: docs/examples/firestore-rules-patterns.md

Step 4: Validate Functions Architecture

Identify pattern in use:

• •Express: Check middleware/, tools/, CORS, health endpoint
• •Domain-Grouped: Check exports, domain boundaries, shared/
• •Individual: Check one function per file structure

Critical: Don't mix patterns. Verify consistency throughout.

Reference: docs/examples/express-function-architecture.md

Step 5: Check Authentication Implementation

For API Keys:

• •Middleware validates key format with project prefix
• •Uses collectionGroup('apiKeys') query
• •Checks active: true flag
• •Attaches userId to request

For Firebase Auth:

• •Functions check request.auth.uid
• •Role lookups use Firestore user document
• •Client connects to auth emulator in development

Reference: docs/examples/api-key-authentication.md

Step 6: Verify ABOUTME Comments

All .ts files should start with:

// ABOUTME: Brief description of what this file does
// ABOUTME: Second line with additional context

grep -L "ABOUTME:" functions/src/**/*.ts  # Find missing

Step 7: Review Test Coverage

Check for:

• •Unit tests: functions/src/__tests__/**/*.test.ts
• •Integration tests: functions/src/__tests__/emulator/**/*.test.ts
• •vitest.config.ts and vitest.emulator.config.ts exist
• •Coverage threshold met (60%+)

npm test && npm run test:coverage

Step 8: Validate Error Handling

All handlers must:

• •Use try-catch blocks
• •Return { success: boolean, message: string, data?: any }
• •Use proper HTTP status codes (400, 401, 403, 500)
• •Log errors with console.error
• •Validate input before processing

Step 9: Security and Production Review

Security checks:

• •No secrets in code (grep -r "apiKey.*=" functions/src/)
• •.env files in .gitignore
• •No allow read, write: if true; in rules
• •Sensitive fields protected from client writes

Production checks:

• •npm audit clean
• •Build succeeds: npm run build
• •Tests pass: npm test
• •Correct project in .firebaserc
• •Indexes defined for complex queries

Validation Checklists

Hosting Pattern

• • Pattern matches firebase.json config
• • Sites/targets exist in Firebase Console
• • Rewrites reference valid functions
• • Emulator ports configured

Authentication Pattern

• • Auth method matches security model
• • Middleware/checks implemented correctly
• • Environment variables documented
• • Emulator connection configured

Security Model

• • Server-write-only: All allow write: if false;
• • Client-write: diff().affectedKeys() validation
• • Default deny rule present
• • Helper functions used consistently

Common Issues

Integration with Superpowers

For general code quality review beyond Firebase patterns, invoke superpowers:requesting-code-review.

Output

After validation, provide:

• •Summary of findings
• •Issues categorized by severity (critical, important, nice-to-have)
• •Recommendations for remediation
• •Confirmation of best practices compliance

Pattern References

• •Hosting: docs/examples/multi-hosting-setup.md
• •Auth: docs/examples/api-key-authentication.md
• •Functions: docs/examples/express-function-architecture.md
• •Rules: docs/examples/firestore-rules-patterns.md
• •Emulators: docs/examples/emulator-workflow.md