databricks-observability
Set up comprehensive observability for Databricks with metrics, traces, and alerts. Use when implementing monitoring for Databricks jobs, setting up dashboards, or configuring alerting for pipeline health. Trigger with phrases like "databricks monitoring", "databricks metrics", "databricks observability", "monitor databricks", "databricks alerts", "databricks logging".
80
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/databricks-pack/skills/databricks-observability/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-structured skill description that clearly communicates its purpose and when to use it. It excels in completeness and trigger term coverage with explicit 'Use when' and 'Trigger with' clauses. The main weakness is that the capability description could be more specific about the concrete actions performed (e.g., which monitoring tools, what types of dashboards).
Suggestions
Add more specific concrete actions to the first sentence, e.g., 'configure Spark metrics collection, set up Grafana/Datadog dashboards, define alert rules for job failures and SLA breaches' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Databricks observability) and mentions some actions (metrics, traces, alerts, dashboards, alerting), but the actions are somewhat high-level rather than listing multiple concrete specific operations like 'configure Prometheus exporters, set up Grafana dashboards, define alert thresholds'. | 2 / 3 |
Completeness | Clearly answers both 'what' (set up comprehensive observability with metrics, traces, and alerts) and 'when' (implementing monitoring for Databricks jobs, setting up dashboards, configuring alerting for pipeline health), with explicit trigger phrases listed. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including 'databricks monitoring', 'databricks metrics', 'databricks observability', 'monitor databricks', 'databricks alerts', 'databricks logging' — these are phrases users would naturally say. Also includes contextual terms like 'dashboards', 'pipeline health', and 'jobs'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — the combination of 'Databricks' with 'observability/monitoring' creates a clear niche that is unlikely to conflict with general monitoring skills or general Databricks skills. The trigger terms are specific to this intersection. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, highly actionable skill with executable SQL and Python code covering multiple observability dimensions. Its main weaknesses are the lack of validation checkpoints between steps (e.g., verifying system table access before proceeding) and the length of inline content that could be better organized with progressive disclosure. The error handling table is a nice addition but doesn't compensate for missing in-workflow verification steps.
Suggestions
Add a validation step at the beginning (e.g., 'Step 0: Verify Access') with a simple query like `SELECT 1 FROM system.lakeflow.job_run_timeline LIMIT 1` and guidance on what to do if it fails, before proceeding to the monitoring queries.
After Step 5 (alert creation), add a verification step to confirm the alert was created successfully (e.g., `w.alerts.get(alert.id)`) and test the notification destination.
Move the detailed query catalog (Steps 2-4, 7) into a separate QUERIES.md reference file, keeping SKILL.md focused on the core workflow (job health check, alert setup, external export) with links to the full query library.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with executable SQL and Python, but includes some redundancy—the 'Daily Standup Dashboard' example largely duplicates Step 1's job health query, and the Output section restates what the steps already cover. Some tightening is possible. | 2 / 3 |
Actionability | Every step provides fully executable SQL queries or Python code with specific table names, column references, and concrete examples. The alert creation includes SDK code with actual parameters. All code is copy-paste ready with minimal adaptation needed. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced and numbered, but there are no validation checkpoints between steps—no guidance on verifying that system tables are accessible before running queries, no feedback loop for handling query failures, and no explicit verification that alerts are working after creation. | 2 / 3 |
Progressive Disclosure | The skill has good section structure and links to external Databricks docs, but the content is quite long (~150 lines of queries) and could benefit from splitting detailed query catalogs into a separate reference file while keeping SKILL.md as a concise overview with the most essential queries. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Commit
70e9fa4
- Reviewed
Table of Contents
Is this your skill?
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.