firebase-development-validate

name	firebase-development-validate
description	This skill should be used when reviewing Firebase code against security model and best practices. Triggers on "review firebase", "check firebase", "validate", "audit firebase", "security review", "look at firebase code". Validates configuration, rules, architecture, and security.

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

Issue	Fix
Missing singleProjectMode	Add to emulators config
No default deny rule	Add match /{document=**} { allow: if false; }
Mixed architecture	Migrate to consistent pattern
Missing ABOUTME	Add 2-line header to all .ts files
No integration tests	Add emulator tests for workflows
Inconsistent response format	Standardize to {success, message, data?}
No error handling	Add try-catch to all handlers
Secrets in code	Move to environment variables

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