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".

Quality

45%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

Securityby

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.md

Quality

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.

The description is generic and lacks specificity about what concrete actions the skill performs. While it includes some useful trigger phrases, the core capability description reads as vague fluff ('comprehensive guidance and automation') without detailing specific monitoring tasks, supported tools, or output types. It needs significantly more concrete detail to help Claude distinguish it from related skills.

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 users would naturally say, such as 'uptime monitoring', 'alerting rules', 'dashboards', 'observability stack', 'logging', 'APM', or specific tool names.

Add a clearer 'Use when...' clause that distinguishes this from related DevOps or infrastructure skills, e.g., 'Use when the user needs to set up, configure, or troubleshoot monitoring systems, alerting pipelines, or observability tooling.'

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 includes trigger phrases that serve as a partial 'when' clause. However, the 'what' is too vague to be truly useful, and the trigger guidance feels formulaic rather than providing clear selection criteria.	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	'Monitoring and observability' is a recognizable domain, and the trigger terms help narrow it somewhat. However, 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, concrete SQL queries for database health monitoring with clear thresholds and good error handling coverage. Its main weaknesses are that the later steps (9-10) become vague directives rather than executable guidance, the examples are narrative rather than code, and the document is long enough to benefit from splitting into per-engine reference files. Adding validation checkpoints and providing the actual monitoring script skeleton would significantly improve it.

Suggestions

Provide an actual executable monitoring script (shell or Python skeleton) for step 9 rather than just directing Claude to 'compile all health checks into a single script'

Add validation checkpoints: e.g., 'Test each query individually before combining; verify cron job runs successfully by checking the first output; confirm alert channel receives a test notification'

Split per-engine queries into separate reference files (e.g., POSTGRESQL.md, MYSQL.md, MONGODB.md) to reduce the main skill's token footprint and improve progressive disclosure

Replace narrative examples with executable code blocks showing the actual monitoring script output format and dashboard query results

Dimension	Reasoning	Score
Conciseness	The content is fairly dense with useful information, but includes some redundancy across database engines that could be consolidated. The examples section describes scenarios narratively rather than showing executable code, adding length without proportional value. Some explanatory text (e.g., 'indicates shared_buffers or innodb_buffer_pool_size needs increasing') is unnecessary for Claude.	2 / 3
Actionability	Individual health check queries are concrete and executable SQL, which is strong. However, steps 9 and 10 are vague directives ('compile all health checks into a single monitoring script') without providing the actual script or even a skeleton. The examples section describes outcomes narratively rather than showing executable code or concrete output formats. The monitoring script and dashboard query promised in the Output section are never actually provided.	2 / 3
Workflow Clarity	Steps are clearly numbered and sequenced with specific thresholds, which is good. However, there are no validation checkpoints or feedback loops — no guidance on what to do if a health check itself fails mid-sequence, no verification that the monitoring script is working correctly after setup, and no explicit 'validate then proceed' pattern. For a monitoring setup involving scheduled jobs and alerting, missing verification steps are notable.	2 / 3
Progressive Disclosure	The content is well-structured with clear sections (Overview, Prerequisites, Instructions, Output, Error Handling, Examples, Resources), but it's a monolithic document with no bundle files. The multi-engine coverage (PostgreSQL, MySQL, MongoDB) and the error handling table could be split into separate reference files. External resource links are provided but there's no internal file decomposition for what is a lengthy skill.	2 / 3
	Total	8 / 12 Passed

Validation

81%

Warnings & errors only

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

Repository: jeremylongshore/claude-code-plugins-plus-skills
Commit: 3a2d27d

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.