Use when planning or reviewing Go SDK work for Deepgram conversational STT / Flux v2. This repo does not currently ship a first-class v2 listen client, so route supported v1 transcription to deepgram-go-speech-to-text and document raw WebSocket fallback honestly when v2 is requested.
78
66%
Does it follow best practices?
Impact
99%
1.15xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/deepgram-go-conversational-stt/SKILL.mdQuality
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 is well-targeted for a niche use case with a clear 'Use when' clause and strong distinctiveness. Its main weaknesses are that the concrete actions could be more explicitly enumerated (it focuses more on routing decisions and limitations than on specific capabilities) and trigger terms could include a few more natural variations a developer might use.
Suggestions
List more concrete actions the skill performs, e.g., 'Generates v1 listen client code, provides WebSocket connection examples, reviews SDK integration patterns.'
Add additional natural trigger terms like 'speech-to-text', 'real-time transcription', 'streaming audio', or 'Go Deepgram client' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a specific domain (Go SDK for Deepgram conversational STT / Flux v2) and mentions some actions like 'route supported v1 transcription' and 'document raw WebSocket fallback,' but the actions are more about routing/documenting limitations than listing concrete capabilities the skill performs. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (route v1 transcription to the Go SDK, document raw WebSocket fallback for v2) and 'when' ('Use when planning or reviewing Go SDK work for Deepgram conversational STT / Flux v2'). The 'Use when' clause is present and specific. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'Go SDK', 'Deepgram', 'STT', 'Flux v2', 'WebSocket', and 'transcription' which are natural for developers in this domain. However, it misses common variations like 'speech-to-text', 'real-time transcription', 'streaming audio', or 'deepgram-go-speech-to-text' as a trigger (though the repo name appears in the body). | 2 / 3 |
Distinctiveness Conflict Risk | This is highly specific to a particular SDK (Deepgram Go), a particular protocol version (Flux v2), and a particular language (Go). It is very unlikely to conflict with other skills given its narrow, well-defined niche. | 3 / 3 |
Total | 10 / 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.
This skill does a good job of being honest about the SDK's current limitations and routing users to appropriate alternatives, with well-structured references. However, it falls short on actionability — the raw WebSocket fallback path is mentioned but never demonstrated with executable code, which is the primary gap. The content could be tightened by consolidating the repeated 'not implemented' messaging.
Suggestions
Add a minimal executable Go code example showing how to establish a raw WebSocket connection to the v2 endpoint using the shared plumbing in pkg/client/common/v1/websocket.go, even if marked as unsupported.
Consolidate the 'Key parameters' section into 'Quick start' since they largely repeat the same information about v2 not being implemented.
Add a brief step-by-step workflow for the raw integration path: configure client options → establish WS connection → send audio → handle responses → validate output, with explicit checkpoints.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but includes some redundancy — the 'Key parameters' section largely restates what's already in 'Quick start', and the 'Central product skills' section at the bottom is boilerplate that adds marginal value. The repeated emphasis on 'not implemented' could be consolidated. | 2 / 3 |
Actionability | The skill is honest about what doesn't exist and points to specific file paths for raw integration, but it provides no executable code examples — no WebSocket connection snippet, no concrete fallback pattern. The guidance is directional rather than copy-paste ready. | 2 / 3 |
Workflow Clarity | The skill clearly sequences the decision (v1 vs raw v2 fallback) and lists relevant files, but there's no step-by-step workflow for the raw WebSocket integration path — no validation checkpoints, no error handling guidance, just file pointers. For a skill that acknowledges a manual integration path, concrete steps would be expected. | 2 / 3 |
Progressive Disclosure | The API reference section is well-layered (in-repo → OpenAPI → AsyncAPI → Context7 → product docs) with clear one-level-deep references. The skill appropriately delegates to other skills (deepgram-go-speech-to-text, deepgram-go-voice-agent) and the central product skills bundle. Navigation is clear and well-signaled. | 3 / 3 |
Total | 9 / 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.
b7c92f4
Table of Contents
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.