managing-database-migrationslisted

# Managing database migrations PostgreSQL-first, Supabase-aware — not a generic skill for any database. If the project's detected persistence layer (see `references/stack-detection.md`) isn't PostgreSQL or Supabase, say so explicitly and state the scope limitation; never invent an equivalent for a different engine. See [enforcing-safety-baseline](../enforcing-safety-baseline/SKILL.md): the safety levels below are this skill's specific application of that policy to database execution, not a separate or weaker gate. ## Workflow 1. **Detect the database.** Read package manifests, environment variable *names* only (never values), `supabase/`, `migrations/` or equivalent directories, schema files, ORM config, Docker/CI config. Identify the engine, the migration framework in use, the migration directory, and whether RLS is in use. Never assume — if the evidence doesn't support a conclusion, say so. When target-environment evidence is needed for a LEVEL 3 classification (see below), sanitized non-secret connection metadata — host, port, database name, or local/container identity, from safe tooling or config (e.g. `docker ps`, `supabase status`, a config file's non-secret fields) — may be derived and stated; raw `.env` contents, full connection URLs, passwords, or tokens are never printed or logged to establish it. If disposability can't be shown without exposing a secret, that's insufficient evidence, not a reason to expose one — classify as LEVEL 4. 2. **Inspect current state.**