neondatabase/examples-.agents-neon-postgres-branches
>- Choose and create the right Neon branch type for testing and development. Use when users ask about Neon branching, migration testing with real data, isolated test environments, schema-only branch workflows for sensitive data, resetting a branch from its parent, branch expiration and CI/CD branch lifecycles, or branch creation via Neon CLI or Neon MCP. Triggers include "Neon branch", "test migrations safely", "branch production data", "schema-only branch", "reset branch", "branch per PR" and "sensitive data testing".
This is a copy. The original lives at neondatabase/examples-neon-postgres-branches.
npx skills add https://github.com/neondatabase/examples --skill neon-postgres-branchesFIRST: Use the parent neon skill for a Neon overview, getting started with Neon, Neon development best practices, and more.
If the neon skill is not installed, fetch it from https://neon.com/docs/ai/skills/neon/SKILL.md or install it with:
npx skills add neondatabase/agent-skills --skill neon
Outcome: a created Neon branch — or a clear, actionable next step if creation cannot proceed. Choose the correct branch type, then execute branch creation with the CLI (or MCP where the CLI isn't usable).
Use this decision rule first:
If the request is ambiguous, ask one clarifying question:
"Do you need realistic data for testing, or only schema structure because the data is sensitive?"
Support both the Neon CLI and the Neon MCP server, but default to the CLI. Use MCP only when the CLI is unavailable or blocked in your environment, cannot be authenticated, or the user explicitly asks for MCP.
neon --version to confirm the CLI is installed.neon projects list to confirm auth/context.neon auth (or API key auth), then continue.create_branch) to create the branch.describe_branch).Use this when the user needs realistic testing conditions.
Real production-like data can expose edge cases your seed or data migration scripts miss, which helps catch migration issues before going live.
Link: https://neon.com/docs/introduction/branching.md
neon --version, and fall back to MCP only if the CLI isn't usable.neon set-context --project-id <your-project-id>) or include --project-id on commands. neon branches create \
--name <branch-name> \
--parent <parent-branch-id-or-name> \
--expires-at 2026-12-15T18:02:16Z
neon connection-string <branch-name>
Use this when users must not copy production rows into the test branch.
Link: https://neon.com/docs/guides/branching-schema-only.md
neon --version, and fall back to MCP only if the CLI isn't usable. neon branches create \
--name <schema-only-branch-name> \
--parent <parent-branch-id-or-name> \
--schema-only \
--expires-at 2026-12-15T18:02:16Z
If multiple projects exist, include --project-id:
neon branches create \
--name <schema-only-branch-name> \
--parent <parent-branch-id-or-name> \
--schema-only \
--project-id <your-project-id> \
--expires-at 2026-12-15T18:02:16Z
Schema-only branching is in Beta. If users report unexpected behavior, errors, or missing capabilities:
Use this when a child branch has drifted and the user wants a clean refresh from the parent branch's latest schema and data.
Link: https://neon.com/docs/guides/reset-from-parent.md
neon branches reset <id|name> --parent --preserve-under-name <backup-branch-name>
If project context is not already set, include the project ID:
neon branches reset <id|name> --parent --preserve-under-name <backup-branch-name> --project-id <project-id>
--preserve-under-name keeps the pre-reset state as a backup branch for rollback, but adds one extra branch to clean up later.
Optional context setup to avoid repeating --project-id:
neon set-context --project-id <project-id>
source_branch_id to the parent branch ID.If the user asks for process recommendations (not just a single command), suggest these:
After branch creation, ask whether the user wants to update local environment credentials to point at the new branch.
.env DATABASE_URL to this new branch connection string?"neon.ts)Beyond creating branches imperatively (CLI / MCP / API above), you can program what configuration new branches receive declaratively in neon.ts — Neon's infrastructure-as-code file (see the neon skill for the full reference). The branch property is a function of the branch being evaluated that returns its settings, so every branch born from your project gets a consistent lifecycle and compute profile without per-branch flags.
npm i @neon/config
// neon.ts
import { defineConfig } from "@neon/config/v1";
export default defineConfig({
branch: (branch) => {
if (branch.exists) return {}; // never reconcile existing branches
if (branch.isDefault) return { protected: true };
if (branch.name.startsWith("preview/") || branch.name.startsWith("dev")) {
return {
parent: "main",
ttl: "7d", // ephemeral: auto-expire 7 days after creation (max 30d)
postgres: {
computeSettings: {
autoscalingLimitMinCu: 0.25, // scale to zero
autoscalingLimitMaxCu: 1, // keep throwaway branches cheap
suspendTimeout: "5m",
},
},
};
}
return {};
},
});
The closure receives a read-only descriptor of the target branch — name, exists, isDefault, parentId, and more — and returns the tuning to apply: parent, ttl (auto-expiry), protected, and postgres.computeSettings. This is the declarative complement to the Ephemeral lifecycle hygiene and per-PR / per-test patterns above: instead of remembering --expires-at on every neon branches create, the TTL and compute profile live in version control and apply to every matching branch.
Because neon checkout applies this policy when it creates a branch, a fresh preview/* or dev-* branch comes up already expiring and scaled-to-zero. Checking out an _existing_ branch doesn't reconcile it — run neon deploy (alias for neon config apply) to apply changes to a branch that already exists.
Common CI/CD use cases for Neon branches:
DATABASE_URL into the deployed app is hosting-provider-specific — see preview-branches-with-cloudflare, preview-branches-with-vercel, or preview-branches-with-fly for tested patterns.User input: "I need to test a risky migration against production-like data."
Agent output shape:
neon --version; MCP only if the CLI isn't usable).neon branches create --name migration-test --parent main --expires-at 2026-12-15T18:02:16Zneon connection-string migration-testUser input: "We cannot copy production data because of compliance."
Agent output shape:
neon --version; MCP only if the CLI isn't usable).neon branches create --name compliance-dev --parent main --schema-only --project-id <your-project-id> --expires-at 2026-12-15T18:02:16ZTake neondatabase/examples-.agents-neon-postgres-branches from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.
The instructions reference npm, npx.
Without those the skill loads but fails at the first command.