kopai/create-dashboard
Create observability dashboards from OTEL metrics, logs, and traces using Kopai. Use when building metric visualizations, monitoring views, KPI panels, or when the user wants to see their telemetry data in a dashboard — even if they don't say "dashboard" explicitly. Also use when other skills or workflows need to present telemetry data visually (e.g. after root cause analysis).
79
99%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%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 an excellent skill description that clearly defines what the skill does (creates observability dashboards from OTEL data using Kopai), when to use it (with explicit and implicit trigger scenarios), and how it relates to other skills. It uses third-person voice, includes rich natural trigger terms, and occupies a distinct niche that minimizes conflict risk.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple concrete actions: 'Create observability dashboards from OTEL metrics, logs, and traces using Kopai' along with specific use cases like 'metric visualizations, monitoring views, KPI panels'. Names the tool (Kopai) and data types (OTEL metrics, logs, traces). | 3 / 3 |
Completeness | Clearly answers both 'what' (create observability dashboards from OTEL metrics/logs/traces using Kopai) and 'when' with an explicit 'Use when...' clause covering multiple trigger scenarios including implicit ones and cross-skill handoffs. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'dashboard', 'metric visualizations', 'monitoring views', 'KPI panels', 'telemetry data', 'OTEL', 'observability'. Also explicitly handles the case where users don't say 'dashboard' but want to visualize telemetry data, and mentions cross-skill triggers like 'after root cause analysis'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: OTEL-based observability dashboards via Kopai. The combination of the specific tool (Kopai), data domain (OTEL metrics/logs/traces), and output type (dashboards/visualizations) makes it very unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
92%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, well-structured skill that provides concrete, executable guidance for creating Kopai dashboards. The dynamic shell commands for schema and metrics discovery are an excellent pattern that keeps the skill current without hardcoding. The main weakness is the somewhat unclear rules reference at the bottom, where the bundle structure isn't available to verify the referenced files exist.
Suggestions
Clarify the rules reference: list all available rule files explicitly (e.g., 'See [rules/workflow.md](rules/workflow.md) for detailed tree structure and error handling rules') rather than using the generic pattern.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It doesn't explain what OTEL, dashboards, or metrics are. Every section serves a purpose — schema discovery, workflow, example, component table, and rules reference. The dynamic shell commands for schema/metrics are a smart use of tokens. | 3 / 3 |
Actionability | Provides fully executable CLI commands at every step, a complete copy-paste-ready bash example with real JSON structure, and a concrete component compatibility table. Claude can immediately execute the workflow without guessing. | 3 / 3 |
Workflow Clarity | The 4-step workflow is clearly sequenced with an explicit validation checkpoint (step 4) that includes a feedback loop: on error, re-run metrics discover, fix the tree, and retry. This covers the validate -> fix -> retry pattern appropriately. | 3 / 3 |
Progressive Disclosure | The skill references `rules/<rule-name>.md` for detailed rules, which is good progressive disclosure. However, no bundle files were provided to verify the reference exists, and the reference format ('Read `rules/<rule-name>.md` for details') is somewhat vague — it lists only one rule name ('workflow') but uses a generic pattern. The dynamic schema/metrics commands effectively serve as external references, which is clever but unconventional. | 2 / 3 |
Total | 11 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents