Detailed instructions and examples for developing metrics view resources in Rill
36
32%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/rill-metrics-view/SKILL.mdQuality
Discovery
22%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is too vague and lacks both concrete actions and explicit trigger guidance. While it mentions the specific tool 'Rill' and the concept of 'metrics view resources,' it fails to enumerate what actions the skill performs or when Claude should select it. It reads more like a section heading than a functional skill description.
Suggestions
List specific concrete actions the skill covers, e.g., 'Defines measures, dimensions, and time grains in Rill metrics view YAML files, configures aggregations, and sets up explore dashboards.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks about creating or editing Rill metrics views, defining measures, configuring dimensions, or writing .yaml model files for Rill dashboards.'
Include common file types or keywords users might mention, such as '.yaml', 'metrics_view', 'Rill Developer', 'OLAP', or 'dashboard configuration' to improve trigger term coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'detailed instructions and examples' without listing any concrete actions. It does not specify what developing metrics view resources actually entails (e.g., defining measures, configuring dimensions, writing YAML configs). | 1 / 3 |
Completeness | The description weakly addresses 'what' (developing metrics view resources) but completely lacks any 'when' clause or explicit trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also too vague to merit a 2. | 1 / 3 |
Trigger Term Quality | It includes 'metrics view' and 'Rill' which are relevant domain-specific keywords a user might mention, but misses common variations and natural terms like 'dashboard', 'measures', 'dimensions', 'OLAP', '.yaml', or 'data modeling'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'Rill' and 'metrics view resources' provides some specificity to a particular tool, but 'developing metrics view resources' could overlap with other Rill-related skills or general metrics/dashboard skills without clearer scoping. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is highly actionable with excellent concrete YAML examples covering the full range of metrics view features, but it is severely over-long and poorly structured. The inlined JSON schema reference alone accounts for nearly half the content and should be extracted. The document lacks a clear creation workflow with validation steps and would benefit greatly from being split into a concise overview with references to detailed sub-documents.
Suggestions
Extract the full JSON schema reference into a separate REFERENCE.md file and link to it from the main skill, reducing the body by ~50%.
Remove explanatory prose that Claude already knows (e.g., what a semantic layer is, what dimensions/measures conceptually are) and lead with the YAML syntax directly.
Add a clear step-by-step workflow section at the top: 1) Create the file, 2) Define model/timeseries, 3) Add dimensions, 4) Add measures, 5) Validate with `rill start`, 6) Verify the auto-generated explore dashboard.
Split advanced features (security policies, annotations, cache, rollups, dialect notes) into a separate ADVANCED.md to keep the main skill focused on the core creation workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~400+ lines. It explains basic concepts Claude already knows (what a semantic layer is, what dimensions and measures are, what format presets do). The full JSON schema reference at the end is massive and largely redundant given the examples already provided. Much of this could be cut by 60-70% while preserving all actionable content. | 1 / 3 |
Actionability | The skill provides fully concrete, copy-paste ready YAML examples throughout, including a complete annotated metrics view example. Code snippets are executable and specific, covering dimensions, measures, security policies, caching, and dialect-specific SQL expressions. | 3 / 3 |
Workflow Clarity | The skill covers what to include in a metrics view and provides best practices, but lacks a clear step-by-step workflow for creating one from scratch. There are no validation checkpoints (e.g., how to verify the metrics view is valid after creation, how to test it). The content reads more like reference documentation than a guided process. | 2 / 3 |
Progressive Disclosure | The entire skill is a monolithic wall of text with no references to external files. The full JSON schema (~200 lines) is inlined rather than referenced. There's no separation between quick-start content and advanced/reference material. With no bundle files, all content is crammed into one document with no navigation structure. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (705 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
65ccd1f
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.