Apply production-ready patterns for integrating with Clay via webhooks and HTTP API. Use when building Clay integrations, implementing webhook handlers, or establishing team coding standards for Clay data pipelines. Trigger with phrases like "clay SDK patterns", "clay best practices", "clay code patterns", "clay integration patterns", "clay webhook patterns".
74
70%
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/clay-pack/skills/clay-sdk-patterns/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 that clearly identifies its niche (Clay integration patterns), provides explicit trigger guidance with both a 'Use when' clause and specific trigger phrases, and is distinctive enough to avoid conflicts with other skills. The main weakness is that the specific capabilities could be more concrete—listing actual actions like 'parse webhook payloads', 'authenticate API requests', or 'transform Clay table data' would strengthen the specificity dimension.
Suggestions
Add more concrete actions beyond 'apply patterns'—specify what the skill actually does, e.g., 'parse Clay webhook payloads, authenticate HTTP API requests, transform Clay table data, handle error responses'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Clay integrations) and mentions some actions like 'integrating via webhooks and HTTP API', 'implementing webhook handlers', and 'establishing team coding standards', but these are somewhat general and don't list multiple concrete specific actions like parsing webhook payloads, formatting API responses, or handling authentication. | 2 / 3 |
Completeness | The description clearly answers both 'what' (apply production-ready patterns for Clay webhooks and HTTP API integration) and 'when' (explicit 'Use when' clause with triggers, plus a 'Trigger with phrases' section listing specific activation terms). | 3 / 3 |
Trigger Term Quality | The description includes a good set of natural trigger terms: 'clay SDK patterns', 'clay best practices', 'clay code patterns', 'clay integration patterns', 'clay webhook patterns', plus contextual terms like 'webhook handlers' and 'Clay data pipelines'. These cover variations a user would naturally say. | 3 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to Clay as a platform, with distinct triggers like 'clay SDK patterns' and 'clay webhook patterns' that are unlikely to conflict with generic webhook or API skills. The niche is clearly defined. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
50%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, production-ready code for Clay integrations in both TypeScript and Python, which is its main strength. However, it is excessively verbose — duplicating the same patterns across two languages inline rather than splitting them into referenced files. The workflow framing (Step 1-4) is misleading since these are independent code modules, not sequential steps, and batch operations lack validation checkpoints.
Suggestions
Move the full TypeScript and Python client implementations into separate referenced files (e.g., `clay-client-ts.md` and `clay-client-py.md`) and keep only a concise overview with usage examples in the main SKILL.md.
Pick one language as the primary example inline and reference the other, rather than duplicating all patterns in both TypeScript and Python.
Add a validation checkpoint for batch operations — e.g., 'After sendBatch completes, verify results.failed === 0 before proceeding' or a step to check Clay table row counts.
Reframe the 'Steps' as independent patterns/modules rather than a sequential workflow, since they don't depend on each other sequentially.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~200+ lines, with duplicated logic across TypeScript and Python clients that serve the same purpose. The retry logic, batch sending, and enrichment methods are repeated in both languages without justification. Much of this could be condensed significantly or split into separate reference files. | 1 / 3 |
Actionability | The code is fully executable and copy-paste ready with complete TypeScript and Python implementations. Concrete patterns include retry with backoff, batch sending, rate limit handling, and typed interfaces — all directly usable. | 3 / 3 |
Workflow Clarity | Steps are labeled (Step 1-4) but the sequence is more of a code catalog than a true workflow. There are no explicit validation checkpoints — for batch operations that could send many records to a production Clay table, there's no verification step to confirm data was received correctly or to validate inputs before sending. | 2 / 3 |
Progressive Disclosure | The skill has some structure with sections and a resources section linking to external docs, but the massive inline code blocks (TypeScript client, types, Python client) should be in separate referenced files. The content is essentially a monolithic wall of code with thin section headers. | 2 / 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 | |
c8a915c
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.