tdg-personal/dashboard-builder
Build monitoring dashboards that answer real operator questions for Grafana, SigNoz, and similar platforms. Use when turning metrics into a working dashboard instead of a vanity board.
75
75%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
75%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 has a clear 'Use when' clause and targets a distinct niche (monitoring dashboards for observability platforms), which are strong points. However, it lacks specificity in the concrete actions it performs and could benefit from more trigger terms covering common user vocabulary around observability tooling. The phrase 'vanity board' is colorful but not a term users would naturally use as a trigger.
Suggestions
Add specific concrete actions like 'create Grafana panels, write PromQL queries, configure alert thresholds, define SLO dashboards' to improve specificity.
Expand trigger terms to include common variations users would say: 'observability', 'Prometheus', 'PromQL', 'panels', 'time series', 'alerting dashboards', '.json dashboard'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (monitoring dashboards) and mentions specific platforms (Grafana, SigNoz), but the concrete actions are limited to 'build monitoring dashboards' — it doesn't list specific actions like creating panels, configuring alerts, setting up queries, or defining thresholds. | 2 / 3 |
Completeness | Clearly answers both 'what' (build monitoring dashboards that answer real operator questions for Grafana/SigNoz) and 'when' (use when turning metrics into a working dashboard instead of a vanity board), with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some good natural keywords like 'Grafana', 'SigNoz', 'monitoring dashboards', and 'metrics', but misses common variations users might say such as 'observability', 'Prometheus', 'panels', 'alerts', 'dashboard JSON', 'PromQL', or 'time series'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of monitoring dashboards, specific platforms (Grafana, SigNoz), and the operator-focused framing creates a clear niche that is unlikely to conflict with other skills like general data visualization or generic dashboard tools. | 3 / 3 |
Total | 10 / 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 well-organized, concise skill that effectively frames dashboard building as answering operator questions rather than displaying metrics. Its main weakness is the lack of concrete, executable examples—no actual dashboard JSON fragments, no query language examples, and no specific tool commands. The workflow is logical but would benefit from explicit validation steps integrated into the build process.
Suggestions
Add at least one concrete, executable example: a minimal Grafana dashboard JSON snippet or a specific PromQL/ClickHouse query for a common panel like request rate or error rate.
Integrate the quality checklist into the workflow as an explicit validation step (e.g., 'Step 5: Validate against checklist before delivering') to create a feedback loop.
Consider splitting platform-specific panel sets and query examples into separate referenced files (e.g., GRAFANA.md, SIGNOZ.md) to keep the main skill lean while providing depth.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is lean and efficient. It doesn't explain what Grafana or dashboards are, assumes Claude knows these tools, and every section earns its place. The bullet-point style keeps token usage minimal while conveying clear intent. | 3 / 3 |
Actionability | The skill provides good conceptual guidance (operator questions, panel sets, quality checklist) but lacks concrete executable examples—no actual JSON snippets, no specific query examples (PromQL, ClickHouse SQL), no copy-paste-ready panel definitions. It describes what to build rather than showing how to build it. | 2 / 3 |
Workflow Clarity | The four-step workflow is clearly sequenced and logical, but lacks validation checkpoints. There's no explicit step to validate the generated JSON, test the dashboard import, or verify that queries return data. The quality checklist at the end partially compensates but isn't integrated into the workflow as a validation gate. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and references to related skills, but the example panel sets could be linked to separate detailed files rather than inlined. For a skill that covers multiple platforms (Grafana, SigNoz) and multiple domains (Kafka, Elasticsearch, API gateway), more content splitting with clear navigation would be appropriate. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents