jpskill.com
🛠️ 開発・MCP コミュニティ

firebase-development-validate

Firebaseのコードをセキュリティモデルやベストプラクティスに照らしてレビューし、設定、ルール、アーキテクチャ、セキュリティなどを検証することで、Firebase開発における安全性を高めるSkill。

📜 元の英語説明(参考)

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のコードをセキュリティモデルやベストプラクティスに照らしてレビューし、設定、ルール、アーキテクチャ、セキュリティなどを検証することで、Firebase開発における安全性を高めるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o firebase-development-validate.zip https://jpskill.com/download/16719.zip && unzip -o firebase-development-validate.zip && rm firebase-development-validate.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/16719.zip -OutFile "$d\firebase-development-validate.zip"; Expand-Archive "$d\firebase-development-validate.zip" -DestinationPath $d -Force; ri "$d\firebase-development-validate.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して firebase-development-validate.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → firebase-development-validate フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Firebase コードの検証

概要

このサブスキルは、既存の Firebase コードを、実績のあるパターンとセキュリティのベストプラクティスに照らして検証します。構成、ルール、アーキテクチャの一貫性、認証、テスト、および本番環境への準備状況をチェックします。

主な原則:

  • 選択されたアーキテクチャパターンに対して検証する
  • セキュリティルールを徹底的にチェックする
  • テストカバレッジが存在することを確認する
  • 本番環境への準備状況をレビューする

このサブスキルが適用される場合

  • Firebase プロジェクトのコードレビューを実施する場合
  • セキュリティ実装を監査する場合
  • 本番環境へのデプロイを準備する場合
  • ユーザーが「review firebase」、「validate」、「audit firebase」、「check firebase code」と言う場合

以下には使用しないでください:

  • 初期設定 → firebase-development:project-setup
  • 機能の追加 → firebase-development:add-feature
  • アクティブなエラーのデバッグ → firebase-development:debug

TodoWrite ワークフロー

次の9つのステップでチェックリストを作成します。

ステップ 1: firebase.json の構造をチェックする

必要なセクションを検証します。

  • hosting - 配列またはオブジェクトが存在する
  • functions - ソースディレクトリ、ランタイム、predeploy hooks
  • firestore - ルールとインデックスファイル
  • emulators - ローカル開発構成

hosting パターンが実装と一致することを確認します (site:, target:, または single)。

参考資料: docs/examples/multi-hosting-setup.md

ステップ 2: エミュレータの構成を検証する

重要な設定:

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

使用中のすべてのサービスにエミュレータのエントリがあることを確認します。

参考資料: docs/examples/emulator-workflow.md

ステップ 3: Firestore ルールをレビューする

以下を確認します。

  • 上部のヘルパー関数 (isAuthenticated(), isOwner())
  • 一貫したセキュリティモデル (server-write-only OR client-write-validated)
  • クライアント書き込み用の diff().affectedKeys().hasOnly([...])
  • collectionGroup() クエリを使用している場合は、コレクション グループ ルール
  • 下部のデフォルト拒否ルール

参考資料: docs/examples/firestore-rules-patterns.md

ステップ 4: Functions のアーキテクチャを検証する

使用中のパターンを特定します。

  • Express: middleware/, tools/, CORS、ヘルスエンドポイントをチェックします
  • Domain-Grouped: exports、ドメイン境界、shared/ をチェックします
  • Individual: ファイル構造ごとに 1 つの関数をチェックします

重要: パターンを混在させないでください。全体を通して一貫性を確認してください。

参考資料: docs/examples/express-function-architecture.md

ステップ 5: 認証の実装をチェックする

API キーの場合:

  • ミドルウェアは、プロジェクトのプレフィックスを使用してキーの形式を検証します
  • collectionGroup('apiKeys') クエリを使用します
  • active: true フラグをチェックします
  • userId をリクエストにアタッチします

Firebase Auth の場合:

  • 関数は request.auth.uid をチェックします
  • ロールのルックアップは Firestore ユーザー ドキュメントを使用します
  • クライアントは開発時に認証エミュレータに接続します

参考資料: docs/examples/api-key-authentication.md

ステップ 6: ABOUTME コメントを確認する

すべての .ts ファイルは以下で始まる必要があります。

// ABOUTME: Brief description of what this file does
// ABOUTME: Second line with additional context
grep -L "ABOUTME:" functions/src/**/*.ts  # Find missing

ステップ 7: テストカバレッジをレビューする

以下を確認します。

  • ユニットテスト: functions/src/__tests__/**/*.test.ts
  • 統合テスト: functions/src/__tests__/emulator/**/*.test.ts
  • vitest.config.tsvitest.emulator.config.ts が存在する
  • カバレッジのしきい値が満たされている (60%+)
npm test && npm run test:coverage

ステップ 8: エラー処理を検証する

すべてのハンドラーは以下を行う必要があります。

  • try-catch ブロックを使用する
  • { success: boolean, message: string, data?: any } を返す
  • 適切な HTTP ステータス コード (400, 401, 403, 500) を使用する
  • console.error でエラーをログに記録する
  • 処理する前に入力を検証する

ステップ 9: セキュリティと本番環境のレビュー

セキュリティチェック:

  • コードにシークレットがない (grep -r "apiKey.*=" functions/src/)
  • .env ファイルが .gitignore にある
  • ルールに allow read, write: if true; がない
  • 機密フィールドがクライアントの書き込みから保護されている

本番環境チェック:

  • npm audit がクリーンである
  • ビルドが成功する: npm run build
  • テストに合格する: npm test
  • .firebaserc のプロジェクトが正しい
  • 複雑なクエリに対してインデックスが定義されている

検証チェックリスト

Hosting パターン

  • [ ] パターンが firebase.json 構成と一致する
  • [ ] サイト/ターゲットが Firebase コンソールに存在する
  • [ ] リライトが有効な関数を参照する
  • [ ] エミュレータポートが構成されている

認証パターン

  • [ ] 認証方法がセキュリティモデルと一致する
  • [ ] ミドルウェア/チェックが正しく実装されている
  • [ ] 環境変数が文書化されている
  • [ ] エミュレータ接続が構成されている

セキュリティモデル

  • [ ] Server-write-only: すべて allow write: if false;
  • [ ] Client-write: diff().affectedKeys() 検証
  • [ ] デフォルト拒否ルールが存在する
  • [ ] ヘルパー関数が一貫して使用されている

よくある問題

問題 修正
singleProjectMode がない エミュレータ構成に追加する
デフォルト拒否ルールがない match /{document=**} { allow: if false; } を追加する
アーキテクチャが混在している 一貫したパターンに移行する
ABOUTME がない すべての .ts ファイルに 2 行のヘッダーを追加する
統合テストがない ワークフローのエミュレータテストを追加する
応答形式が一貫していない {success, message, data?} に標準化する
エラー処理がない すべてのハンドラーに try-catch を追加する
コードにシークレットがある 環境変数に移動する

Superpowers との統合

Firebase パターンを超えた一般的なコード品質レビューについては、superpowers:requesting-code-review を呼び出してください。

出力

検証後、以下を提供します。

  • 調査結果の概要
  • 重大度別に分類された問題 (重大、重要、あると良い)
  • 改善のための推奨事項
  • ベストプラクティスへの準拠の確認

パターンの参考資料

  • 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
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

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