groq-debug-bundle
Collect Groq debug evidence for support tickets and troubleshooting. Use when encountering persistent issues, preparing support tickets, or collecting diagnostic information for Groq problems. Trigger with phrases like "groq debug", "groq support bundle", "collect groq logs", "groq diagnostic".
64
77%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/groq-pack/skills/groq-debug-bundle/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 well-structured skill description with strong trigger terms, clear 'when' guidance, and a distinct niche. Its main weakness is that the 'what' could be more specific about the concrete actions performed (e.g., what types of logs, configs, or diagnostics are collected). Overall it's a solid description that would perform well in skill selection.
Suggestions
Add specific concrete actions describing what evidence is collected, e.g., 'Gathers system logs, API error traces, configuration snapshots, and runtime metrics for Groq debug evidence.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Groq debug evidence) and a general action (collect debug evidence for support tickets and troubleshooting), but doesn't list multiple specific concrete actions like what types of evidence are collected (logs, configs, metrics, etc.). | 2 / 3 |
Completeness | Clearly answers both 'what' (collect Groq debug evidence for support tickets and troubleshooting) and 'when' (encountering persistent issues, preparing support tickets, collecting diagnostic information) with explicit trigger phrases listed. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'groq debug', 'groq support bundle', 'collect groq logs', 'groq diagnostic', plus contextual phrases like 'support tickets', 'troubleshooting', and 'diagnostic information'. These are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Very distinct niche — Groq-specific debug evidence collection is unlikely to conflict with other skills. The trigger terms are highly specific to this particular use case. | 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 is a solid, actionable debug bundle skill with fully executable code for both bash and TypeScript approaches. Its main weaknesses are the lack of validation checkpoints between steps (e.g., bail early if API key is unset or connectivity fails) and some content duplication between the bash and TypeScript approaches that inflates token usage. The workflow would benefit from explicit conditional checks and the TypeScript section could be split into a separate file.
Suggestions
Add an early validation gate after Step 1 or before Step 2: check that GROQ_API_KEY is set and curl can reach api.groq.com, and abort with a clear message if not — this prevents wasting API calls on Steps 3-4.
Move the TypeScript diagnostic to a separate referenced file (e.g., `groq-diagnostic.ts`) to reduce the main skill's token footprint and improve progressive disclosure.
Add a feedback loop: if Step 2 connectivity fails, provide specific troubleshooting (check proxy, DNS, firewall) before proceeding to rate limit and latency tests.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with executable code, but includes some unnecessary elements like the 'Current State' dynamic commands at the top (which duplicate what the script collects), the TypeScript diagnostic section that largely duplicates the bash approach, and the Bundle Contents table which restates what's already evident from the script. Could be tightened by ~30%. | 2 / 3 |
Actionability | Fully executable bash scripts and TypeScript code throughout. Every step has copy-paste ready commands with specific curl endpoints, jq processing, proper headers, and concrete model names. The redaction patterns use specific regex for gsk_ keys. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (1-6) and logically ordered, but there are no validation checkpoints between steps. There's no error handling guidance if connectivity fails at Step 2 (which would make Steps 3-4 pointless). No feedback loop for 'if API key is not set, stop here' or 'if curl fails, check DNS/proxy'. The final 'Review before sharing' is a weak validation step. | 2 / 3 |
Progressive Disclosure | The skill references external resources (Groq Error Codes, Status Page) and another skill (groq-rate-limits), which is good. However, the content is quite long with both a full bash bundle script AND a full TypeScript diagnostic — the TypeScript section could be a separate reference file. No bundle files are provided to offload the detailed scripts. | 2 / 3 |
Total | 9 / 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
a04d1a2
- 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.