clay-sdk-patterns
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
—
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 description with strong completeness and distinctiveness, clearly scoped to Clay integrations. The explicit 'Use when' clause and trigger phrases are well done. The main weakness is that the specific capabilities could be more concrete—listing actual actions like 'parse webhook payloads, authenticate API requests, handle rate limiting' rather than the vaguer 'apply production-ready patterns'.
Suggestions
Replace 'Apply production-ready patterns' with specific concrete actions like 'Parse webhook payloads, authenticate API requests, handle pagination, and transform Clay table data'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (Clay integrations) and mentions some actions like 'integrating via webhooks and HTTP API' and 'implementing webhook handlers', but doesn't list multiple concrete specific actions (e.g., parsing webhook payloads, authenticating requests, transforming data). 'Apply production-ready patterns' is somewhat vague. | 2 / 3 |
Completeness | Clearly answers both 'what' (apply production-ready patterns for Clay webhooks and HTTP API integration) and 'when' (building Clay integrations, implementing webhook handlers, establishing team coding standards for Clay data pipelines), with explicit trigger phrases provided. | 3 / 3 |
Trigger Term Quality | Includes a good set of natural trigger terms: 'clay SDK patterns', 'clay best practices', 'clay code patterns', 'clay integration patterns', 'clay webhook patterns', plus mentions of 'Clay integrations', 'webhook handlers', and 'Clay data pipelines'. These cover variations a user would naturally say. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche targeting Clay as a platform with webhooks and HTTP API patterns. The repeated use of 'Clay' as a qualifier makes it highly unlikely to conflict with generic webhook or API skills. | 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 with solid error handling patterns. However, it is significantly too verbose — providing near-duplicate implementations in two languages inline and lacking validation checkpoints for batch/webhook operations. The content would benefit greatly from splitting into separate files and trimming redundancy.
Suggestions
Split TypeScript and Python implementations into separate referenced files (e.g., `clay-client-ts.md` and `clay-client-py.md`) to reduce the main skill's token footprint by ~60%.
Add explicit validation steps: e.g., 'Send a test record and verify it appears in your Clay table before proceeding to batch operations' — especially important for batch sends.
Remove the Python client from the main body or reduce it to a brief note ('Python equivalent available in clay-client-python.md') since it duplicates the same patterns already shown in TypeScript.
Add a feedback loop for batch operations: 'After sendBatch completes, check results.failed > 0 and retry failed rows or log for manual review.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~200+ lines, with both TypeScript and Python implementations that are largely redundant (same logic in two languages). The Python client duplicates the retry/batch/enrich patterns already shown in TypeScript. The type definitions section could be collapsed. Much of this could be halved without losing information. | 1 / 3 |
Actionability | The code is fully executable and copy-paste ready with complete TypeScript and Python implementations including retry logic, rate limiting, batch operations, error classes, and type definitions. The webhook callback example is concrete and specific. | 3 / 3 |
Workflow Clarity | Steps are labeled sequentially (Step 1-4) but there's no validation checkpoint — no guidance on how to verify the webhook URL works, test the client, or validate that data arrived in Clay. For batch operations that could fail partially, there's no explicit 'check results and retry failures' feedback loop described in the workflow. | 2 / 3 |
Progressive Disclosure | The skill references external resources and a next-step workflow (`clay-core-workflow-a`), but the body itself is monolithic — the TypeScript client, Python client, types, and singleton pattern could all be separate referenced files. No bundle files exist to offload this content, resulting in a very long single document. | 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 | |
- 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.