Create isolated Neon Postgres branches for testing

Helps choose and create the right Neon branch type for testing and development, then execute the creation via MCP or CLI. The decision rule is simple: pick a normal branch for realistic migration, performance, or behavior testing against production-like data, or a schema-only branch (Beta) when production rows must not be copied for compliance or privacy reasons - asking one clarifying question if the request is ambiguous. Tool selection follows a fixed order: use Neon MCP tools first if available and authenticated, otherwise verify the Neon CLI (neon --version, neon projects list), guide the user through installation or neon auth if needed, and fall back to the Neon REST API only if both paths fail. A normal branch is created with neon branches create --name <name> --parent <parent> --expires-at <timestamp>, optionally followed by neon connection-string <branch-name>; a schema-only branch adds --schema-only (and --project-id when multiple projects exist). Because schema-only branching is Beta, unexpected behavior should be routed to the Neon Console feedback modal or the Neon Discord. A separate reset-from-parent flow fully replaces a child branch's schema and data with the parent's current state (not a merge - local child changes are lost, though connection details stay the same aside from a brief interruption) via neon branches reset <id|name> --parent --preserve-under-name <backup-name>; it only applies to child branches (not root or schema-only-root branches), is blocked while the target has its own children, and can be unavailable for up to 24 hours after the parent was restored from a snapshot. Beyond imperative creation, neon.ts's branch property lets teams declare branch policy as code - a function of a read-only branch descriptor (name, exists, isDefault, parentId) returning settings like parent, ttl, protected, and postgres.computeSettings - so every preview/* or dev-* branch created via neon checkout comes up already TTL-bound and scaled to zero, without repeating --expires-at by hand. Common workflow patterns the skill recommends on request: one branch per PR, one branch per test run, one branch per developer, PII-aware branching from an anonymized or schema-only source, and ephemeral lifecycle hygiene via expiration. After creating a branch, it asks whether to update the local .env DATABASE_URL to the new connection string, never overwriting an existing key without explicit confirmation.

Use it when a user asks about Neon branching, needs to test a migration against real data, wants an isolated test environment, needs a schema-only workflow to avoid copying sensitive data, or wants to create a branch via the Neon CLI or MCP server. It's also the right skill for CI/CD branch patterns - per-PR preview deployments, migration testing in CI, or schema-diff visibility on a PR.

Input is a branching goal (migration testing, sensitive-data isolation, a stale branch needing a refresh) plus a parent branch and optional expiry. Output is a created (or reset) Neon branch, its connection string, and - when relevant - an updated local .env file.

Supports both the Neon MCP server and the Neon CLI, preferring whichever the user already has installed and authenticated, with the Neon REST API and Console as fallbacks; branch policy can also be declared in neon.ts for automatic application on neon checkout.

Developers and teams setting up isolated Neon Postgres environments for migration testing, per-PR previews, or compliance-constrained development who want the right branch type chosen for them and consistent lifecycle policy applied automatically.