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 strong skill description that clearly defines specific capabilities (spending limits, PII blocking, validation rules) within the Clay pipeline domain. It includes explicit 'Use when' guidance and well-crafted trigger phrases that are both natural and distinctive. The description is concise, uses third-person voice correctly, and would allow Claude to confidently select this skill from a large pool.
| 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 for Clay pipelines) and 'when' (explicit 'Use when' clause with specific triggers plus a 'Trigger with phrases' section). | 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 throughout, combined with specific policy/guardrail concepts. The trigger terms are all prefixed with 'clay' making conflicts with generic policy or validation 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, which is its main strength. However, it is significantly over-verbose—most of the implementation detail (blocked field lists, domain lists, full class bodies) could be expressed as concise rules/patterns that Claude would implement on demand. The workflow lacks explicit validation checkpoints for what are essentially safety-critical operations (spending limits, PII handling).
Suggestions
Condense each policy section to a brief specification (rules, thresholds, field lists) with one short code example, trusting Claude to generate full implementations. This could cut the skill to ~80 lines.
Add explicit validation/testing checkpoints: e.g., 'After implementing credit policy, test with a mock batch exceeding limits to verify enforcement' and 'Run privacy check against sample data before deploying to production'.
Split detailed implementations into separate referenced files (e.g., credit-policy.md, privacy-policy.md) and keep SKILL.md as a concise overview with navigation links.
Remove the error handling table—it merely restates what each step already covers and adds no new information.
| 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 limits, 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. For a system dealing with PII and spending limits, there should be explicit verification steps (e.g., 'run privacy audit before deploying', 'test credit enforcer with mock data before production'). | 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 'Next Steps' reference to clay-architecture-variants is good, but the main body would benefit from being an overview with links to detailed implementation files for each policy type. | 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 | |
70e9fa4
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.