skills/team/alembic-migration-manager/SKILL.md
Manages the full Alembic migration lifecycle with safety checks and rollback planning. Python analog of ef-migration-manager. Use when creating, reviewing, or applying database migrations in Python projects using SQLAlchemy and Alembic.
npx skillsauth add michaelalber/ai-toolkit alembic-migration-managerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
"Every migration is a one-way door. Make sure you know what's on the other side. The database is the last line of defense — treat every schema change as if it cannot be undone."
Database migrations are the most dangerous routine operation in software development. A bad
deployment can be rolled back; a bad migration that drops a column or corrupts data cannot be undone
without a backup restore — and restores take time production systems do not have. This skill manages
the Alembic lifecycle with the same safety philosophy as ef-migration-manager and
sqlx-migration-manager: review the generated SQL before applying, verify the rollback first, and
keep each migration to one concern.
Non-Negotiable Constraints:
alembic upgrade head --sql before alembic upgrade head.upgrade() has a downgrade() tested on a dev database before applying upstream.Full principle table, KB lookups, command sequences, anti-patterns, discipline rules, and error
recovery live in references/conventions.md.
PLAN Identify the model change; assess data-loss risk; identify zero-downtime needs; plan
the downgrade; decide one migration or several (schema vs. data backfill).
Run: alembic current · alembic history · alembic check (must be clean).
GENERATE alembic revision --autogenerate -m "descriptive_name" (or empty for manual/data).
STOP and review the generated file — autogenerate misses views/triggers, equivalent
type changes, custom-named indexes, sequences (see conventions.md).
REVIEW SQL alembic upgrade head --sql AND alembic downgrade -1 --sql. Verify: matches intent,
no unexpected DROP/data loss, acceptable locks. (Lock detail: dangerous-operations.md.)
TEST ROLLBACK On dev only: upgrade head → verify → downgrade -1 → verify returns to prior state →
upgrade head again. (Checklists: migration-safety-checklist.md.)
APPLY alembic upgrade head → alembic current to confirm. Roll back with downgrade -1 if needed.
Exit criteria: alembic check clean before generate; generated file and upgrade/downgrade SQL
reviewed; rollback tested on dev; applied and confirmed via alembic current; the revision chain
remains linear.
<alembic-migration-state>
phase: PLAN | GENERATE | REVIEW_SQL | TEST_ROLLBACK | APPLY | COMPLETE
migration_name: [descriptive name]
data_loss_risk: none | low | medium | high
zero_downtime_required: true | false
sql_reviewed: true | false
rollback_tested: true | false
current_revision: [revision ID or "head"]
target_revision: [revision ID or "head"]
last_action: [description]
next_action: [description]
</alembic-migration-state>
references/output-templates.md.references/dangerous-operations.md.references/migration-safety-checklist.md.references/conventions.md.| Skill | Relationship |
|-------|-------------|
| python-feature-slice | When a feature needs schema changes, use this skill for the migration lifecycle. |
| python-architecture-checklist | May identify schema design issues before migrations are generated. |
| python-security-review | Migration files may carry sensitive defaults/seed data — review for CUI and credentials. |
| ef-migration-manager / sqlx-migration-manager | Cross-references for .NET and Rust stacks — identical safety philosophy, different tooling. |
development
Interviews the user relentlessly about a plan, decision, or idea — one question at a time, each with a recommended answer. Shared engine behind "grill-me" and "grill-with-docs". Use on any "grill" trigger phrase or to stress-test thinking. Do NOT use to build the plan; it ends at shared understanding, not implementation.
testing
Runs a relentless interview to sharpen a plan or design, capturing the decisions as ADRs and a glossary along the way. Use when the user wants to be grilled AND wants the session to leave durable domain documentation behind. Do NOT use for a throwaway stress-test with no artifacts; use grill-me instead.
tools
OWASP-based security review of Vue/TypeScript front-ends. Detects framework (Vite/Vue CLI/Nuxt), entry points, and data flows; scans the OWASP Top 10 (2025) mapped to Vue client-side risks (raw-HTML XSS via v-html, URL/protocol injection, bundled secrets, insecure token storage, dependency CVEs, missing CSP, open redirects, router guard bypass); emits an exec summary plus graded findings. Use to audit Vue for vulnerabilities. Not for architecture grading (vue-architecture-checklist).
tools
Analyzes legacy Vue codebases and produces actionable modernization plans. Primary migration paths include Options API to Composition API, Vue 2 to Vue 3, Vue CLI to Vite, JavaScript to TypeScript, Vue Test Utils/Karma/Mocha to Vitest + Vue Testing Library, legacy Vuex to Pinia, and removed-in-Vue-3 pattern cleanup (filters, event bus, `$listeners`). Does NOT perform the migration — assesses, quantifies risk, and plans.