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本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
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
$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. 下の青いボタンを押して
firebase-development-validate.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
firebase-development-validateフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
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 hooksfirestore- ルールとインデックスファイル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.tsとvitest.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 presentfunctions- Source directory, runtime, predeploy hooksfirestore- Rules and indexes filesemulators- 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: trueflag - Attaches
userIdto 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.tsandvitest.emulator.config.tsexist- 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/) .envfiles in.gitignore- No
allow read, write: if true;in rules - Sensitive fields protected from client writes
Production checks:
npm auditclean- 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