Conciseness

The body is dense, terse, and assumes Claude's competence — every bullet carries a concrete recommendation (e.g., "Prefer TIMESTAMPTZ for event time; NUMERIC for money", TOAST strategies with exact ALTER syntax) rather than explaining concepts. Not a 5 because there is noticeable redundancy: the "Do not use the following data types" section and parts of "Core Rules" restate guidance already given in "Data Types".

Actionability

Guidance is fully executable throughout: exact DDL ("BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY", "CREATE INDEX ON tbl (user_id) WHERE status = 'active'", "EXCLUDE USING gist (room_id WITH =, booking_period WITH &&)"), three complete copy-paste CREATE TABLE examples, and concrete query patterns for JSONB indexing. Specific examples cover the common cases (users, orders, JSONB profiles).

Workflow Clarity

The content is a well-organized reference catalogue, but there is no explicit design workflow — no sequenced steps (e.g., requirements → access patterns → normalize → types → constraints → indexes) and no verification checkpoints such as using EXPLAIN to confirm index usage. Safe-testing guidance exists ("BEGIN; ALTER TABLE...; ROLLBACK;" for transactional DDL), which keeps it from scoring lower, but checkpoints remain implicit, matching the anchor-3 profile.

Progressive Disclosure

Section structure is clear and consistent (Core Rules, Gotchas, Data Types, Constraints, Indexing, Partitioning, workload-specific sections), but the entire ~200-line reference is inlined in SKILL.md with no bundle files or pointers — detail-heavy sections like Extensions, JSONB Guidance, and the type-by-type catalogue are prime candidates for one-level-deep reference files. This lands between the anchor-2 inlined-content case and better organization, matching anchor 3.

Specificity

The description lists multiple concrete, explicitly stated actions — "Design PostgreSQL tables, schemas, or data models", "Choose data types, constraints, or indexes", "Create user tables, order tables, reference tables, or JSONB schemas", "Design update-heavy, upsert-heavy, or OLTP-style tables" — comprehensively covering the table-design domain. Not a 4 because coverage spans design, type/constraint/index selection, table creation, workload patterns, and best practices with no meaningful gaps.

Completeness

Both "what" and "when" are explicit: "Use this skill for general PostgreSQL table design" backed by "Comprehensive reference covering data types, indexing strategies, constraints, JSONB patterns, partitioning", and an explicit "**Trigger when user asks to:**" list with concrete trigger phrases. Matches the anchor-5 pattern of clearly answering both with concrete triggers.

Trigger Term Quality

The keyword list ("PostgreSQL schema, table design, data types, PRIMARY KEY, FOREIGN KEY, indexes, B-tree, GIN, JSONB, constraints, normalization, identity columns, partitioning, row-level security") plus natural trigger phrases gives good coverage of terms users would say. Not a 5 because common variants like "Postgres" (without the SQL suffix), "DDL", or "CREATE TABLE" are missing.

Distinctiveness Conflict Risk

The niche (PostgreSQL table/schema design) is clear with PostgreSQL-specific triggers (JSONB, partitioning, identity columns). Not a 5 because broad triggers like "Choose data types, constraints, or indexes for PostgreSQL" and "Understand PostgreSQL best practices" could overlap with closely related skills such as query-optimization or general SQL design skills.