Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →langfuse/clickhouse-best-practices
MUST USE when reviewing ClickHouse schemas, queries, or configurations. Contains 28 rules that MUST be checked before providing recommendations. Always read relevant rule files and cite specific rules in responses.
Passed 21 of 23 test cases with the skill, and 3 of 23 without it.
and 27 more in the full report
18 fixed3 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 18 test cases the skill fixed. Same model, same prompt, with and without the skill.
We need to enrich clickstream events with target product titles from a product catalog. Each product ID in the right table is unique, and we only need to match the first corresponding product record per event row. Which JOIN modifier should be used?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends using ANY JOIN instead of a standard ALL JOIN. | Missed | Passed |
| Explains that ANY JOIN stops searching after finding the first matching row, saving memory and processing execution time. | Passed | Passed |
| Cites rule query-join-use-any. | Missed | Passed |
The instructions your model reads when the skill loads.
Comprehensive guidance for ClickHouse covering schema design, query optimization, and data ingestion. Contains 28 rules across 3 main categories (schema, query, insert), prioritized by impact.
Official docs: ClickHouse Best Practices
Before answering ClickHouse questions, follow this priority order:
rules/ directoryrule-name..."Why rules take priority: ClickHouse has specific behaviors (columnar storage, sparse indexes, merge tree mechanics) where general database intuition can be misleading. The rules encode validated, ClickHouse-specific guidance.
packages/shared/src/server/queries/clickhouse-sql/event-query-builder.ts
for queries against the events table. Do not hand-roll events SQL unless
you first confirm the query builder cannot express the query.FINAL on the events table; it is designed so FINAL is not
required and the keyword hurts performance.system.query_log.log_comment as
JSON from packages/shared/src/server/clickhouse/queryTags.ts. Parse it with
JSONExtractString(log_comment, 'surface'),
JSONExtractString(log_comment, 'route'), and
JSONExtractString(log_comment, 'projectId'). Known surface values are
trpc, publicapi, worker, mcp, and unknown; ClickhouseWriter inserts
use projectId = "MULTI_PROJECT".contextWithLangfuseProps(...) from
packages/shared/src/server/headerPropagation.ts, setting ClickHouse
surface, optional route, and optional projectId. The ClickHouse
repository layer then reads baggage via normalizeClickHouseQueryTags(...)
and writes it to log_comment. Prefer setting attribution at entry points
rather than passing tags through every repository call.packages/shared/clickhouse/migrations/canonical/** is the single canonicaltest cases passed, vs 3 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.