clay-observability
Set up comprehensive observability for Clay integrations with metrics, traces, and alerts. Use when implementing monitoring for Clay operations, setting up dashboards, or configuring alerting for Clay integration health. Trigger with phrases like "clay monitoring", "clay metrics", "clay observability", "monitor clay", "clay alerts", "clay tracing".
Install with Tessl CLI
npx tessl i github:jeremylongshore/claude-code-plugins-plus-skills --skill clay-observability78
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
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 with excellent trigger term coverage and clear 'Use when' guidance. The main weakness is that the capabilities could be more specific about concrete actions (e.g., which monitoring tools, what types of dashboards). The Clay-specific focus provides good distinctiveness.
Suggestions
Add more specific concrete actions like 'create Grafana dashboards', 'configure Prometheus metrics', or 'set up PagerDuty alerts' to improve specificity
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Clay integrations observability) and mentions some actions (metrics, traces, alerts, dashboards, alerting), but doesn't list specific concrete actions like 'create Grafana dashboards' or 'configure Prometheus metrics'. The actions are somewhat generic monitoring concepts. | 2 / 3 |
Completeness | Clearly answers both what (set up observability with metrics, traces, alerts) and when (implementing monitoring, setting up dashboards, configuring alerting). Has explicit 'Use when' clause and 'Trigger with phrases' section providing clear guidance. | 3 / 3 |
Trigger Term Quality | Explicitly lists natural trigger phrases users would say: 'clay monitoring', 'clay metrics', 'clay observability', 'monitor clay', 'clay alerts', 'clay tracing'. Good coverage of variations combining the product name with monitoring-related terms. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche combining 'Clay' (a specific product) with observability/monitoring. The Clay-specific triggers make it unlikely to conflict with generic monitoring skills or other integration skills. | 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 skill provides excellent actionable code examples for Clay observability setup with Prometheus, OpenTelemetry, and Grafana. However, it lacks validation checkpoints for verifying the observability stack is working correctly, and the lengthy inline configurations could be better organized into separate reference files for a cleaner main skill document.
Suggestions
Add validation steps after each setup phase (e.g., 'Verify metrics appear at /metrics endpoint', 'Test alert rules with promtool check rules')
Move the detailed AlertManager YAML and Grafana JSON configurations to separate reference files (e.g., ALERTS.yaml, DASHBOARD.json) and link to them
Remove the 'Overview' and 'Output' sections which add little value - the content speaks for itself
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with good code examples, but includes some unnecessary sections like the 'Overview' that adds little value, and the 'Output' section that states obvious outcomes. The prerequisites section could be trimmed. | 2 / 3 |
Actionability | Provides fully executable TypeScript code for metrics, tracing, and logging. Includes copy-paste ready Prometheus alert rules, Grafana panel queries, and a working metrics endpoint. All examples are concrete and complete. | 3 / 3 |
Workflow Clarity | Steps are listed in the 'Instructions' section but lack validation checkpoints. No guidance on verifying metrics are being collected correctly, testing alerts before deployment, or confirming traces are propagating. For an observability setup, validation steps are important. | 2 / 3 |
Progressive Disclosure | Content is reasonably organized with clear sections, but the skill is quite long (~200 lines) and could benefit from splitting detailed configurations (alert rules, dashboard JSON) into separate reference files. The single reference to 'clay-incident-runbook' is appropriate. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
75%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 12 / 16 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
metadata_version | 'metadata' field is not a dictionary | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow | Warning |
Total | 12 / 16 Passed | |
- 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.