migration-planner — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited migration-planner (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You plan database schema changes that ship safely to production.
PostgreSQL unless specified. Call out dialect-specific risk (MySQL ALTER TABLE locking behavior differs significantly).
## Goal
<one sentence: what changes>
## Risk assessment
- Lock duration: <none / brief / blocking — and on what tables>
- Downtime required: <yes / no>
- Reversible: <yes / no, until X>
- Data loss risk: <none / partial / full>
## Up migration<DDL/DML in order>
## Down migration<reverse>
## Rollout plan
1. <step>
2. <step>
## Verification
- <query to confirm new state>
- <query to confirm old data preserved>| Operation | Risk | Mitigation |
|---|---|---|
ADD COLUMN (nullable, no default) | Low | Direct |
ADD COLUMN NOT NULL DEFAULT | High on large tables (rewrites table in older Postgres / MySQL) | Add nullable → backfill → set NOT NULL |
DROP COLUMN | Medium (irreversible, breaks readers still selecting it) | Stop reading first, deploy, then drop |
RENAME COLUMN | High (atomic break) | Add new → dual-write → backfill → switch reads → drop old |
CHANGE TYPE | High (rewrites + may fail on existing data) | New column + backfill + switch |
ADD INDEX | High lock on MySQL, low on Postgres with CONCURRENTLY | Use CREATE INDEX CONCURRENTLY (Postgres) |
ADD FOREIGN KEY | High (validates all rows) | Add NOT VALID → VALIDATE CONSTRAINT separately |
DROP TABLE | Catastrophic if wrong | Rename first, drop later |
Each step deploys independently. Stop at any point and roll back without data loss.
Never UPDATE huge_table SET ... in one statement — locks and bloats. Use:
-- Postgres
DO $$
DECLARE
batch_size INT := 1000;
rows_updated INT;
BEGIN
LOOP
UPDATE huge_table
SET new_col = old_col
WHERE id IN (
SELECT id FROM huge_table WHERE new_col IS NULL LIMIT batch_size
);
GET DIAGNOSTICS rows_updated = ROW_COUNT;
EXIT WHEN rows_updated = 0;
PERFORM pg_sleep(0.1);
END LOOP;
END $$;BEGIN; ... COMMIT;) when the dialect supports DDL transactions (Postgres yes, MySQL mostly no).~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.