clay-policy-guardrails
Implement credit spending limits, data privacy enforcement, and input validation guardrails for Clay pipelines. Use when enforcing spending caps, blocking PII enrichment, or adding pre-enrichment validation rules. Trigger with phrases like "clay policy", "clay guardrails", "clay spending limit", "clay data privacy rules", "clay validation", "clay controls".
78
75%
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-policy-guardrails/SKILL.mdQuality
Discovery
100%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-crafted skill description that clearly defines its scope within Clay pipeline policy enforcement. It excels across all dimensions by listing specific capabilities, providing explicit 'Use when' and 'Trigger with' clauses, and maintaining a distinct niche that minimizes conflict risk with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'credit spending limits', 'data privacy enforcement', 'input validation guardrails', 'spending caps', 'blocking PII enrichment', and 'pre-enrichment validation rules'. These are clearly defined capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement credit spending limits, data privacy enforcement, input validation guardrails) and 'when' (enforcing spending caps, blocking PII enrichment, adding pre-enrichment validation rules) with explicit trigger phrases. | 3 / 3 |
Trigger Term Quality | Provides explicit trigger phrases like 'clay policy', 'clay guardrails', 'clay spending limit', 'clay data privacy rules', 'clay validation', 'clay controls'. These are natural terms a user would say and cover multiple variations. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with the 'Clay' domain qualifier and specific niche of policy/guardrails for Clay pipelines. The trigger terms are all prefixed with 'clay' and the capabilities (spending limits, PII blocking, validation) are narrowly scoped, making conflicts with other skills unlikely. | 3 / 3 |
Total | 12 / 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 comprehensive, executable TypeScript implementations for Clay policy guardrails across four domains, which is strong on actionability. However, it is far too verbose for a SKILL.md — the full implementations should live in referenced files with the skill body providing concise patterns, decision criteria, and integration guidance. The workflow lacks explicit validation checkpoints and error recovery loops for what are essentially batch data operations.
Suggestions
Move full TypeScript implementations to separate referenced files (e.g., credit-policy.ts, privacy-policy.ts) and keep only concise usage patterns and key configuration values in SKILL.md.
Add an integration workflow showing how to chain these policies together before a Clay enrichment run, with explicit validation checkpoints (e.g., 'Run privacy check → if violations, halt and report → Run credit check → if over budget, reduce batch size → proceed').
Replace verbose lists (BLOCKED_ENRICHMENT_FIELDS, PERSONAL_EMAIL_DOMAINS) with a brief representative sample and a note that the full list is in the referenced file.
Add a quick-start section showing the minimal code to enforce all four guardrails on a single batch, so Claude can see the end-to-end pattern before diving into details.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~250 lines of TypeScript code. Much of this is boilerplate that Claude could generate from a concise specification. The blocked field lists, domain lists, and full class implementations could be condensed to patterns/rules with a brief example, trusting Claude to implement the details. | 1 / 3 |
Actionability | The code is fully executable TypeScript with complete interfaces, type definitions, and implementations. Each policy area has copy-paste ready code with clear file paths and concrete examples of validation logic, credit enforcement, and export filtering. | 3 / 3 |
Workflow Clarity | Steps are numbered and sequenced (credit → privacy → validation → export), but there are no validation checkpoints or feedback loops between steps. There's no guidance on how to integrate these policies into an actual Clay pipeline execution flow, or what to do when a check fails beyond the return values. | 2 / 3 |
Progressive Disclosure | The content is largely monolithic — all four policy implementations are fully inline rather than being summarized with references to separate files. The single reference to 'clay-architecture-variants' in Next Steps is good, but the massive code blocks should be in referenced files with the SKILL.md providing an overview and usage patterns. | 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.