monitoring-database-health
Monitor use when you need to work with monitoring and observability. This skill provides health monitoring and alerting with comprehensive guidance and automation. Trigger with phrases like "monitor system health", "set up alerts", or "track metrics".
43
45%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/database/database-health-monitor/skills/monitoring-database-health/SKILL.mdQuality
Discovery
40%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 description is too vague about its actual capabilities, relying on buzzwords like 'comprehensive guidance and automation' without specifying concrete actions. While it includes some useful trigger phrases, the lack of specific actions and the generic nature of the description would make it difficult for Claude to confidently select this skill over others in a large skill library.
Suggestions
Replace 'comprehensive guidance and automation' with specific concrete actions, e.g., 'Configure health checks, set up alerting rules, create monitoring dashboards, define SLOs/SLIs, and integrate with tools like Prometheus, Grafana, or Datadog.'
Expand trigger terms to include common variations like 'observability', 'uptime monitoring', 'alerting rules', 'dashboards', 'logging', 'APM', and specific tool names users might mention.
Strengthen the 'when' clause with a proper 'Use when...' statement that covers specific scenarios, e.g., 'Use when the user needs to set up or configure monitoring infrastructure, create alerting pipelines, or troubleshoot observability gaps.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'health monitoring and alerting with comprehensive guidance and automation' without listing concrete actions. It doesn't specify what kind of monitoring, what metrics, what alert mechanisms, or what systems are involved. | 1 / 3 |
Completeness | It has a weak 'what' (health monitoring and alerting) and does include trigger phrases, but the 'what' is too vague to be truly useful. The 'when' is present via the trigger phrases but the overall description lacks substance about actual capabilities. | 2 / 3 |
Trigger Term Quality | It includes some relevant trigger phrases like 'monitor system health', 'set up alerts', and 'track metrics', which are natural terms users might say. However, it misses common variations like 'observability', 'dashboards', 'uptime', 'logging', 'Prometheus', 'Grafana', 'notifications', or specific monitoring tool names. | 2 / 3 |
Distinctiveness Conflict Risk | The term 'monitoring and observability' provides some domain specificity, but the description is broad enough that it could overlap with infrastructure management, DevOps, logging, or performance optimization skills. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides genuinely useful database monitoring guidance with concrete SQL queries and clear alert thresholds, which are its main strengths. However, it suffers from being monolithic (mixing three database engines inline), lacking executable monitoring script examples for the key deliverables (steps 9-10), and missing validation/verification checkpoints for what is essentially a multi-step deployment workflow. The content would benefit from being split across engine-specific files and including a complete, executable monitoring script template.
Suggestions
Provide a complete, executable monitoring script (shell or Python) for at least one database engine rather than just directing Claude to 'compile all health checks into a single script'—this is the core deliverable and should be concrete.
Add validation checkpoints: after creating the monitoring script, verify it runs successfully; after configuring alerts, test alert delivery; after setting up cron, confirm the schedule is active.
Split engine-specific queries into separate reference files (e.g., POSTGRESQL.md, MYSQL.md, MONGODB.md) and keep SKILL.md as a concise overview with cross-references, improving progressive disclosure.
Include a concrete alert template example (e.g., a Slack webhook payload or PagerDuty event JSON) rather than just listing 'Alert notification templates' as an output.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is fairly dense with useful information, but it's verbose in places—listing queries for multiple database engines inline makes it long. The examples section describes scenarios narratively rather than showing executable code, and some explanations (like what RAG status means) are unnecessary for Claude. However, most content is genuinely informative rather than padding. | 2 / 3 |
Actionability | The individual SQL queries are concrete and executable, which is good. However, steps 9 and 10 are vague directives ('compile all health checks into a single monitoring script') without providing the actual script or template. The output section lists deliverables but doesn't show concrete examples of the monitoring script, alert templates, or dashboard query. The skill describes what to produce more than it shows how. | 2 / 3 |
Workflow Clarity | Steps are clearly numbered and sequenced with specific thresholds, which is helpful. However, there are no validation checkpoints or feedback loops—no step says 'verify the monitoring script works before deploying to cron' or 'test alert delivery before relying on it.' For a monitoring setup involving cron jobs and alerting integrations, missing verification steps is a notable gap. | 2 / 3 |
Progressive Disclosure | The content is a monolithic document with all details inline. Multi-engine queries for PostgreSQL, MySQL, and MongoDB are all mixed together rather than being split into separate reference files per engine. With no bundle files, there's no progressive disclosure structure. The Resources section links to external docs but doesn't organize the skill's own content across files. | 2 / 3 |
Total | 8 / 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
6e9558f
- 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.