bmrc-migrations

Guides safe Firestore migrations, backfills, and schema changes against production data.

2|Updated Dec 24, 2025
One-click install
npx skills add https://github.com/iv-zhang/BMRC-Logistics --skill bmrc-migrations-iv-zhang
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: bmrc-migrations
Source: https://github.com/iv-zhang/BMRC-Logistics/tree/main/.claude/skills/bmrc-migrations
Command: npx skills add https://github.com/iv-zhang/BMRC-Logistics --skill bmrc-migrations-iv-zhang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Firestore migrations in this project run directly against production data for an active EMS corps, with no staging copy or point-in-time restore. This Skill enforces the discipline needed to write and run migration scripts, backfills, and data fixes without corrupting live inventory records. ## Core Features & Use Cases - Dry-run-first workflow: All migration npm scripts default to dry-run mode, requiring explicit flags and user approval before any live write executes. - Migration script standards: New scripts must be idempotent, log every change with before/after values, batch writes under the 500-op Firestore limit, and preserve audit trails in inventory_logs and auditEvents. - Emulator rehearsal: Changes are rehearsed against the local Firestore emulator with seeded legacy fixtures before any production dry-run is proposed. - Use Case: When renaming a field across inventory documents, use this Skill to write an idempotent migration script, rehearse it on the emulator, review the dry-run output, and only then execute the live write with validation checkers. ## Quick Start Ask the AI to write a dry-run-first Firestore migration script that backfills a missing field on inventory documents and rehearse it on the emulator before touching production.

Frequently Asked Questions about bmrc-migrations

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a Firestore migration script safely against production data?▼

Run the npm migration scripts, which default to dry-run mode, and review every reported change before enabling writes. Live writes require an explicit apply flag and explicit user approval for that specific run.

How to write an idempotent Firestore migration script?▼

Select documents by the condition being fixed rather than a precomputed list, so a second run is a no-op. Log every change with document ID, field, and before/after values, and batch writes in chunks under the 500-operation WriteBatch limit.

Can I test Firestore migrations on an emulator before production?▼

Yes, start the emulator with npm run emulator, seed it with npm run seed including legacy-shape fixtures, and point the script at it via FIRESTORE_EMULATOR_HOST. Inspect results in the emulator UI before proposing a production dry-run.

When should I migrate data versus using tolerant readers in Firestore?▼

Prefer tolerant readers that handle legacy document shapes at the hydration layer. Migrate only when tolerance would spread conditionals across many call sites, and keep readers tolerant until verification shows zero legacy documents remain.

Why does Firestore reject writes with undefined field values?▼

Firestore rejects undefined values on write, so new fields need safe defaults at the read or hydration layer. The codebase uses a removeUndefined() helper in app/lib/audit.ts to strip undefined values before writing.