Conciseness

The body is lean: 16 compact, comment-light code examples, a quick-reference table, and terse directive bullets with no explanation of concepts Claude already knows. Minor trimmable material keeps it below 5: the 'Since' column embeds time-sensitive version numbers ('DBR 16.3+', 'GA') outside any deprecated/old-patterns section, and the 'Reference Files' table duplicates the reference column of the Quick Reference table. It is noticeably above the anchor-3 midpoint (no unnecessary explanations, just minor redundancy), so 4.

Actionability

Every pattern is a complete, copy-paste-ready SQL block covering the common case: a full procedure with EXIT HANDLER and CALL invocation, a scheduled materialized view, pipe-syntax rewrite, ai_query with returnType, an H3 join with ST_Distance filter, a CREATE CONNECTION plus http_request, read_files with schemaHints, and a concrete CLI test command ('databricks experimental aitools tools query') with an env-var fallback. This matches anchor 5; anchor 4 would imply minor gaps in the examples themselves, which are absent.

Workflow Clarity

The body is a pattern catalog rather than a sequenced procedure, and the multi-step flows it does contain (e.g. create connection then call http_request, or MERGE-based upserts that mutate data) have no inline validation checkpoints — the only verification guidance is one final bullet ('Test SQL via CLI ... before deploying'), with no fix-and-retry loop. Per the rubric's cap for database operations without feedback loops, workflow clarity cannot exceed 3; a score of 4 would require checkpoints embedded at each risky step.

Progressive Disclosure

The body is a clear overview: a feature-to-reference routing table, one worked example per feature kept inline, and a 'Reference Files' table with an explicit 'When to Read' column. All five referenced files exist and contain only internal anchor links, so references are exactly one level deep with no nesting — matching anchor 5's clear overview with well-signaled one-level-deep references.

Specificity

The 'what' is a generic domain statement ('Databricks SQL (DBSQL) advanced features and SQL warehouse capabilities') with no concrete action verbs, but the enumerated trigger terms ('stored procedure', 'materialized view', 'recursive CTE', 'collation', 'http_request') do convey concrete capabilities. It matches anchor 3 (domain plus some concrete items but not framed as specific actions); anchor 4 requires several specific action statements ('Extracts...', 'Fills...') which are absent, while anchor 2 would require the trigger list to be generic jargon, which it is not.

Completeness

Both parts are explicitly present: a 'what' ('Databricks SQL advanced features and SQL warehouse capabilities') and an unusually explicit 'when' ('This skill MUST be invoked when the user mentions: ... SHOULD also invoke when...'). The 'when' exceeds anchor 4's bar, but the 'what' is vague ('advanced features and capabilities' rather than named actions like the anchor-5 example's 'Extract text and tables from PDF files, fill forms, merge documents'), keeping it below 5.

Trigger Term Quality

Comprehensive natural-term coverage including synonyms and exact syntax users would type: 'DBSQL' and 'Databricks SQL', 'recursive CTE' and 'WITH RECURSIVE', 'temp table' and 'temporary view', 'pipe syntax', '|>' and 'pipe operator', plus specific function names ('ai_query', 'http_request', 'read_files'). This matches the anchor-5 example's coverage breadth (synonyms, exact operators, function identifiers); anchor 4 would leave noticeable natural terms missing, which is not the case.

Distinctiveness Conflict Risk

Mostly distinct: the majority of triggers are Databricks-specific tokens ('DBSQL', 'ai_query', 'h3'/'H3', 'remote_query') with minimal conflict risk. A few broad terms ('AI function', 'temp table', 'SQL best practices, data modeling patterns') could overlap with generic SQL or sibling Databricks skills (note 'parent: databricks-core'), which is the minor overlap of anchor 4 rather than the clear niche of anchor 5.