Conciseness

Dense tables and rules with zero padding; it never explains what dbt, YAML, or a warehouse is, and every rationale ('Catches the largest classes of ingestion bugs', 'because there are no rows to check') directly justifies a convention. Not 4: no passages of over-explanation were found that could be trimmed.

Actionability

Concrete, executable guidance throughout: exact check names (not_null, unique, accepted_values, relationships), the '2x the expected cadence' threshold with examples (freshness < 2d), naming patterns (not_null_orders_email), owner meta blocks, and 'Land new checks at warn for two cycles, then promote'. Per the rubric's instruction-skill note, the absence of code is not penalized when guidance is this actionable.

Workflow Clarity

A clear implicit sequence exists (pick engine, then column-level key checks, then table-level invariants, then severity tiering, then ownership, then retirement) with a stability checkpoint in the promotion rule. Not 5: no explicit numbered workflow or validation/feedback loop, and the 'auditing an existing one' use case has no verification checklist; not 3: the sequence and several checkpoints (promotion after two stable cycles, retirement criteria) are present.

Progressive Disclosure

Self-contained ~120-line skill (no bundle files exist) with well-organized sections and tables; content is appropriately inlined. Not 5: the skill exceeds the 50-line simple-skill threshold and lacks any one-level-deep reference files (the anti-pattern catalog or engine matrix could live in references/), and companion skills are named but not linked.

Specificity

Enumerates multiple concrete design actions — 'choosing dbt tests vs Great Expectations vs Soda', 'column vs table-level checks', 'severity tiers', 'SLA and freshness conventions', and 'anti-patterns to avoid' — comprehensively covering the skill's scope. Not 4: the only omissions (naming/ownership, check retirement) are minor sub-topics rather than coverage gaps.

Completeness

Explicitly answers 'when' with a concrete 'Use when designing data-quality coverage for a new data product or auditing an existing one' trigger clause, and 'what' via the colon-enumerated scope. Not 4: the 'when' clause is already specific — anchor 4 requires a 'when' that could be more explicit.

Trigger Term Quality

Good natural keyword coverage: 'data-quality coverage', 'data product', 'auditing', 'dbt tests', 'Great Expectations', 'Soda', 'freshness', 'SLA'. Not 5: common user synonyms like 'data validation', 'data testing', or 'data observability' are absent; not 3: the domain's natural vocabulary is well represented.

Distinctiveness Conflict Risk

The design/audit framing carves a clear niche distinct from engine-execution skills, but naming 'dbt tests', 'Great Expectations', and 'Soda' creates minor overlap risk with the closely related engine-specific companion skills. Not 5: those tool names could pull execution requests (e.g. 'write a dbt test') toward this skill.