clay-debug-bundle
Collect Clay debug evidence for support tickets and troubleshooting. Use when encountering persistent issues, preparing support tickets, or collecting diagnostic information for Clay integration problems. Trigger with phrases like "clay debug", "clay support bundle", "collect clay logs", "clay diagnostic", "clay support ticket".
85
83%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
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 and clear 'what/when' guidance. Its main weakness is that the capabilities could be more specific about exactly what debug evidence is collected (e.g., logs, configs, error states). The explicit trigger phrases and Clay-specific focus make it highly distinctive and easy for Claude to match correctly.
Suggestions
Add more specific concrete actions such as 'captures log files, exports configuration state, records error traces, and packages diagnostic bundles' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Clay debug/support) and mentions some actions like 'collect debug evidence' and 'preparing support tickets', but doesn't list specific concrete actions such as gathering log files, capturing configuration state, exporting error traces, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (collect Clay debug evidence for support tickets and troubleshooting) and 'when' (encountering persistent issues, preparing support tickets, collecting diagnostic information), with explicit trigger phrases provided. | 3 / 3 |
Trigger Term Quality | Excellent trigger term coverage with natural phrases users would say: 'clay debug', 'clay support bundle', 'collect clay logs', 'clay diagnostic', 'clay support ticket'. These are specific and varied enough to capture real user requests. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche around Clay-specific debugging and support evidence collection. The specific product name 'Clay' and debug/diagnostic focus make it very unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%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 executable bash scripts and a clear multi-step workflow. Its main weakness is moderate verbosity — the manual checklist template and summary table add bulk without proportional value. The progressive disclosure is adequate but could benefit from splitting the manual checklist and detailed scripts into separate referenced files.
Suggestions
Move the manual Clay UI checklist (Step 6) into a separate template file (e.g., clay-table-diagnostics-template.md) and reference it from the main skill to reduce inline bulk.
Remove the Error Handling table — it restates what each step already covers and adds no new information.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably focused but includes some unnecessary elements like the manual checklist template (which is quite verbose with blank fields) and the error handling table that mostly restates what was already covered. The environment capture section and the `## Current State` shell commands at the top are useful but the overall content could be tightened. | 2 / 3 |
Actionability | The skill provides fully executable bash scripts with specific commands, proper error handling (set -euo pipefail), concrete curl commands with correct flags, and clear variable handling. The code is copy-paste ready and covers real diagnostic scenarios including webhook testing, API validation, and log collection. | 3 / 3 |
Workflow Clarity | The 7-step workflow is clearly sequenced from setup through packaging, with an explicit validation checkpoint in Step 7 ('BEFORE SUBMITTING: Review for sensitive data!'). The sensitive data handling section provides a clear checklist for review, and the manual steps in Step 6 are clearly separated from automated steps. The feedback loop of review-before-submit is appropriate for this type of operation. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections, but it's somewhat monolithic — the manual checklist template and the detailed bash scripts could potentially be split into referenced files. There's a brief reference to `clay-rate-limits` at the end, but no bundle files exist to support progressive disclosure. For a skill of this length (~150 lines of content), some splitting would improve navigability. | 2 / 3 |
Total | 10 / 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.