Conciseness

The body is mostly efficient, but there is noticeable duplication and padding: the tool-path check ("verify the CLI with `neon --version`, and fall back to MCP only if the CLI isn't usable") is repeated three times; the Beta feedback links (console.neon.tech modal + discord) appear twice; and the hard-coded timestamp `--expires-at 2026-12-15T18:02:16Z` is repeated in four commands — time-sensitive information placed inline rather than in a deprecated/context section. Explanatory asides like "Real production-like data can expose edge cases your seed or data migration scripts miss..." add tokens Claude does not need. This sits between the 2 and 4 anchors, and the duplication is more than 'minor instances', so 3.

Actionability

Mostly executable, copy-paste-ready guidance: complete `neon branches create` / `neon branches reset` / `neon connection-string` / `neon set-context` commands with flags and placeholders, plus a full runnable neon.ts config example. Minor gaps keep it below 5: the MCP flow is vague ("Use branch tools (for example, `create_branch`)" with no parameter details), the REST API fallback is only a link, and the duplicated literal `--expires-at` date is a stale-prone example rather than a relative placeholder.

Workflow Clarity

Sequencing is strong — a numbered decision rule, a 5-step tool-selection order with `neon --version` / `neon projects list` checkpoints, and per-branch-type step lists. However the destructive reset-from-parent flow has no explicit validation or verification step after the operation (no post-reset check equivalent to the MCP flow's `describe_branch` validation), and the guideline caps destructive-operation workflows without validation at 3. It is above the 2 anchor because pre-flight constraints (only child branches, blocked if the target has children, 24-hour restore window) and a rollback path (`--preserve-under-name`) are clearly documented.

Progressive Disclosure

The body has clear, well-signaled sections and one-level-deep navigation: it defers the Neon overview to the parent `neon` skill ("see the `neon` skill for the full reference") and links external docs per topic rather than nesting references. There are no bundle files, so structure is judged on the body itself. It is not a 5 because sizable sections (the full neon.ts IaC example, CI/CD patterns, the Examples section) are inlined in a ~290-line SKILL.md where a references/ file split would fit the 'appropriately split' top anchor.

Specificity

The description names the domain and 1-2 concrete actions — "Choose and create the right Neon branch type for testing and development" — but the additional items (reset, expiration, CI/CD lifecycles) are framed as trigger scenarios rather than actions the skill performs. It matches the 'names domain and 1-2 concrete actions, but not comprehensive' anchor; it is not a 4 because it does not enumerate several specific actions like 'reset a branch', 'set branch expiration', or 'manage branch lifecycles' as capabilities.

Completeness

It explicitly answers both: what — "Choose and create the right Neon branch type for testing and development" — and when — an explicit "Use when users ask about..." clause plus a dedicated "Triggers include" list with concrete phrases. It clearly matches the top anchor, and nothing is missing for the 'what' or 'when'.

Trigger Term Quality

Explicit trigger phrases include "Neon branch", "test migrations safely", "branch production data", "schema-only branch", "reset branch", "branch per PR" and "sensitive data testing" — natural terms a user would say. Not a 5 because common variations like "database branch", "preview database/environment", "copy production data", or "isolated test environment" as a standalone phrase are absent from the trigger list.

Distinctiveness Conflict Risk

The niche is clear (Neon Postgres branch management) and every trigger is Neon-branch-specific, so overlap with sibling skills like a general 'neon' overview or unrelated Postgres skills is minimal. This matches the 'clear niche with distinct triggers' anchor.