reversible-bulk-writelisted

Use when about to write in bulk to a live datastore — importing a dataset, backfilling a column, a mass UPDATE, any statement whose blast radius is "lots of rows". Fire before the first write, not after it goes wrong. Also fire when a bulk write has already gone in and needs undoing. Do NOT fire for ordinary single-row writes, for schema migrations (those have their own review and apply path), or for writes to a throwaway or local database.
damson/hard-won-skills · ★ 1 · API & Backend · score 67

Install: claude install-skill damson/hard-won-skills

# Reversible bulk write A bulk write is judged by what you can undo, not by what you intended. ## Procedure 1. **Name the invariant.** One measurable fact this write must NOT change, and its value right now — "`widgets` stays 1,541", "no row leaves `approved`". Record the number before touching anything. Without it, "did that go correctly?" has no answer, only a vibe. - Default when nothing obvious presents itself: `count(*)` on the table the write must NOT reach, and on the constrained subset it should. Two numbers, taken before. 2. **Dry-run every stage before applying any stage.** Multi-step pipelines are where this bites: stage 1 accepts what stage 2 rejects, and applying stage 1 first buys you a write plus a rollback for nothing. Run the whole chain in dry-run, read the projected counts, and only then apply. - Counts that look *too clean* (100%, 0%, exactly N) deserve a second look, and the look is concrete: sample up to five rows from each side the dry run reports — touched and skipped — and check each against the predicate by hand. At exactly 0% or 100% one side is empty, so hand-pick rows that *should* have landed there and confirm the predicate's reason for putting them on the other side; ten rows agreeing is evidence, a round number agreeing with itself is not. 3. **Write the rollback before applying, and prove its columns exist.** Query `information_schema.columns` or read the migration — do no