deepgram-observability
Set up comprehensive observability for Deepgram integrations. Use when implementing monitoring, setting up dashboards, or configuring alerting for Deepgram integration health. Trigger: "deepgram monitoring", "deepgram metrics", "deepgram observability", "monitor deepgram", "deepgram alerts", "deepgram dashboard".
77
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/deepgram-pack/skills/deepgram-observability/SKILL.mdQuality
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 solid skill description with excellent trigger term coverage and clear completeness, explicitly answering both what and when. Its main weakness is that the capability description is somewhat generic in terms of specific actions — it could benefit from listing more concrete deliverables beyond the high-level 'monitoring, dashboards, alerting' triad. The Deepgram-specific focus gives it strong distinctiveness.
Suggestions
Add more specific concrete actions to improve specificity, e.g., 'Tracks API latency, transcription accuracy, error rates; configures Prometheus/Grafana dashboards; sets up PagerDuty alerts for Deepgram service degradation.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Deepgram observability) and mentions some actions like 'implementing monitoring', 'setting up dashboards', and 'configuring alerting', but these are fairly generic observability concepts rather than deeply specific concrete actions (e.g., no mention of specific metrics tracked, specific tools used, or specific integration patterns). | 2 / 3 |
Completeness | The description clearly answers both 'what' (set up comprehensive observability for Deepgram integrations) and 'when' (explicit 'Use when' clause with triggers for monitoring, dashboards, alerting, plus explicit trigger terms). Both components are present and explicit. | 3 / 3 |
Trigger Term Quality | The description explicitly lists natural trigger terms like 'deepgram monitoring', 'deepgram metrics', 'deepgram observability', 'monitor deepgram', 'deepgram alerts', 'deepgram dashboard' — these are terms users would naturally say and cover good variations of the concept. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of 'Deepgram' + 'observability/monitoring/dashboards/alerting' creates a very specific niche that is unlikely to conflict with other skills. The Deepgram-specific qualifier makes it clearly distinguishable from generic monitoring or other integration skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides highly actionable, executable code covering a comprehensive Deepgram observability stack. However, it suffers from being a monolithic document that would benefit greatly from splitting code into separate bundle files, and it lacks validation/verification steps between the setup stages to confirm each pillar is working before moving to the next.
Suggestions
Split the large code blocks (instrumented client, OTel setup, Grafana dashboard JSON, AlertManager rules) into separate bundle files and reference them from SKILL.md with brief descriptions.
Add validation checkpoints after key steps, e.g., 'After Step 1, curl /metrics and verify deepgram_requests_total appears' and 'After Step 3, check traces in your OTLP backend'.
Remove or relocate the cost-per-minute pricing map to a clearly marked configuration section noting it may become outdated.
Trim the Output section which merely restates what the steps already cover, and consolidate the overview table with the step headers.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~250 lines of code) and could be significantly tightened. The overview table and output summary section are somewhat redundant. However, the code itself is mostly necessary and not padded with explanations of basic concepts. The cost-per-minute pricing data is time-sensitive and could become stale. | 2 / 3 |
Actionability | All code examples are fully executable TypeScript with proper imports, concrete metric names, real PromQL queries, and complete AlertManager YAML. The instrumented client, tracing setup, logging configuration, and dashboard panels are all copy-paste ready. | 3 / 3 |
Workflow Clarity | Steps are clearly numbered 1-6 and logically sequenced, but there are no validation checkpoints — no instructions to verify metrics are being collected, test that traces appear, confirm alerts fire correctly, or validate the dashboard loads. For an observability setup involving multiple interconnected systems, verification steps are important. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of code with no bundle files to offload detailed implementations. The Grafana dashboard JSON, AlertManager rules, and full instrumented client code could each be separate referenced files, keeping the SKILL.md as a concise overview. Everything is inline in one massive document. | 1 / 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
3a2d27d
- 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.