change-data-safely
Skill1 starsChanged 2 days agoMITView on GitHub
Change a database schema or stored data without breaking running code or losing data. Use this for any migration, new or changed column, backfill, bulk update, delete, index, or change to a stored format, including in small projects. Data mistakes are often impossible to undo.
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Read the current state: Read the schema and existing migrations.
- Distinctive: line 41
Test it: Run the migration on a copy of the schema with realistic old rows.
- Distinctive: line 42
Run all migrations from empty too.
- Distinctive: line 44
Plan recovery: Write down how to undo each step.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Change data safely
Code can be rolled back, but lost data often cannot. During a deploy, old and new code run against the same data at the same time, so each step must work for both.
When to use
Any change to stored data or its shape.
Steps
- Read the current state. Read the schema and existing migrations. Find every reader and writer of the affected data.
- Ask what already exists. Think about rows with nulls, duplicates, old formats and very large tables. Test against these, not only fresh data.
Split risky changes into stages.
Stage Action Safe because Expand Add the new column or table, nullable Old code ignores it Write both New code writes old and new Either version can read Backfill Copy old rows in small batches Can stop and resume Read new Switch reads to the new field Old data is still there Contract Remove the old field, in a later release Nothing uses it now Renaming a column in place breaks whichever code version is not expecting it.
- Make each step safe to rerun. A migration or backfill can stop halfway. Running it twice must not corrupt data.
- Consider locks and size. Adding an index or rewriting a large table can block production. Use the database's online option, and process rows in batches.
- Test it. Run the migration on a copy of the schema with realistic old rows. Run all migrations from empty too. Confirm that row counts and values are right.
- Plan recovery. Write down how to undo each step. If a step cannot be undone, say so. Confirm that a recent backup exists and can be restored.
- Get approval before production. Show the exact statements, the affected row count and the recovery plan. Do not run them against production without explicit approval for that specific action.
- Check the result. Compare counts and sample rows. Then follow
verify-and-report.
Stop and ask when
- The change deletes or overwrites data, or removes a column or table.
- You are unsure which environment a connection points to.
- There is no tested backup.
Common mistakes
| Tempting move | Why it fails | Do this instead |
| Rename a column in one step | Breaks old or new code | Expand, migrate, contract |
Add NOT NULL with no default | Fails on existing rows | Add nullable, backfill, then constrain |
UPDATE or DELETE without a preview | Can hit every row | Run a SELECT with the same filter first |
| Update one huge batch | Locks the table | Use small batches |
| Test only on an empty database | Misses real data | Include old-format rows |
| Edit a migration that already ran | Environments drift apart | Add a new migration |
Report
Change: <schema or data change>
Affected: <tables and row counts>
Compatibility: <how old and new code both work during deploy>
Tested on: <data used, and the result>
Recovery: <how to undo, or why it cannot be undone>
Production: <not run / run with approval, and the result>Other versions2 projects use a version of this.
Word for word · 2
- Remote-Arc/remote-arc★ 5100% same
- yaohuangguan/remote-arc★ 5100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- audit-test-suiteSkill
- debug-failureSkill
- fix-flaky-testSkill
- hand-off-workSkill
- implement-changeSkill
- orient-in-codebaseSkill
- refactor-safelySkill
- review-codeSkill
- secure-changeSkill
- use-external-apiSkill
- verify-and-reportSkill
- write-pull-requestSkill
- write-testsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.