Conciseness

The body is lean and assumes Claude's competence—'Do not restate the procedure from memory. Follow the recipe.' and 'Keep the skill focused on orchestration and verification, not duplicating the full runbook.'—with every line earning its place and no padding. It is a 5 rather than 4 because there is no over-explanation to trim; it deliberately offloads detail to the recipe.

Actionability

Guidance is concrete in intent (names the canonical recipe, lists specific sub-tasks like 'URL rewriting', 'extension precreation', 'restore verification', and names a specific file 'docker-compose.restore-test.yaml') but provides no executable commands or copy-paste steps in-body. It is a 3 because the actionable specifics live in the external recipe rather than here, and not a 4 (which requires mostly executable code/commands) since the body is explicitly instruction-only with the actual commands deferred.

Workflow Clarity

A clear orchestration sequence is present: canonical recipe handles proxy/URL rewrite/pg_dump/pg_restore/extension precreation/restore verification/startup, with an explicit ordering constraint ('Use docker-compose.restore-test.yaml only after the recipe has created the restored database container') and a verification reference plus an escalation callout. It is a 4 rather than 5 because the in-body feedback-loop/validation detail is referenced rather than spelled out, and a 4 rather than 3 because checkpoints (restore verification, post-container ordering) are explicitly named.

Progressive Disclosure

Well-structured single-level reference: a concise overview points to one canonical recipe via a clearly signaled markdown link, with the body retaining only orchestration/navigation guidance in labeled sections. It is a 4 rather than 5 because the skill keeps all detail behind one external path outside the bundle and the recipe is not a bundled file under references/, leaving minor navigation gaps; it is a 4 rather than 3 because structure and signaling are clear and references are not buried.

Specificity

Names the domain (Fly Managed Postgres) and several concrete actions—'pg_dump or pg_restore from a proxied production database', 'testing app/backfill behavior on a restored local copy of prod'—with only minor gaps in coverage (proxy setup, extension precreation are referenced in the body but not the description). It is not a 5 because actions like proxy setup and restore verification are implied rather than enumerated, and not a 3 because it lists multiple specific actions beyond a single pair.

Completeness

Explicitly answers 'when' via the 'Use when working with...' clause and 'what' via the enumerated operational targets (backups, proxy access, pg_dump/pg_restore, testing on a restored local copy). It is a 5 because both what and when are present with concrete trigger phrases, and not a 4 because the 'when' is as explicit and specific as the 'what'.

Trigger Term Quality

Includes the natural terms a user would say—'Fly Managed Postgres backups', 'Fly MPG proxy access', 'pg_dump or pg_restore', 'restored local copy of prod'—covering synonyms and tool-specific extensions comprehensively. It is a 5 rather than 4 because it spans the tool names, the managed-service name, and the operational outcome rather than leaving common variations out.

Distinctiveness Conflict Risk

The Fly MPG / proxied-production-Postgres niche is highly specific with distinct triggers (Fly Managed Postgres, MPG proxy, pg_dump/pg_restore from a proxied prod DB), giving minimal conflict risk with other skills. It is a 5 rather than 4 because the combination of managed-service name, proxy access, and restore-to-local context carves a clear niche unlikely to misfire.