Lists multiple specific concrete actions: 'build data enrichment workflows,' 'score leads against ICP,' 'set up Clay waterfalls,' 'improve contact data quality,' plus mentions lead enrichment waterfalls, ICP scoring frameworks, and contact verification systems.

Clearly answers both 'what' (build data enrichment workflows, score leads against ICP, set up Clay waterfalls, improve contact data quality) and 'when' (explicit 'Use when' clause with trigger terms, plus a 'Do NOT use' exclusion boundary). Both are explicit and well-defined.

Excellent coverage of natural trigger terms users would say: 'enrichment,' 'data enrichment,' 'Clay,' 'waterfall enrichment,' 'ICP scoring,' 'lead scoring,' 'intent data,' 'contact verification,' 'Apollo,' 'ZoomInfo,' 'data quality.' These are terms a user in this domain would naturally use.

Highly distinctive with a clear niche in data enrichment/lead scoring workflows. The explicit exclusion of 'technical implementation, code review, or software architecture' further reduces conflict risk with engineering-focused skills. Domain-specific tool names like Clay, Apollo, and ZoomInfo make it very unlikely to trigger incorrectly.

This is extremely verbose at 400+ lines. It explains concepts Claude already knows (what a waterfall is, what catch-all domains are, what GDPR requires), includes extensive provider comparison tables with pricing that will become stale, and provides benchmark data that could be in a reference file. The ratio of novel, actionable instruction to general knowledge is low.

The skill provides highly concrete, specific guidance: exact scoring formulas with weights, detailed provider selection tables by use case, specific Clay table column structures, credit math calculations, confidence thresholds with exact actions, and a complete ROI calculation framework. A user could follow these instructions to build a working enrichment system.

The waterfall flow is clearly sequenced with explicit validation checkpoints (pre-qualification filter, verification step with confidence thresholds, catch-all segmentation). The deliverability protection checklist serves as a final validation gate. The Clay workflow has a clear column-by-column build order. Credit governance rules include monitoring and alerting thresholds.

This is a monolithic wall of text with nearly all content inline. The provider comparison matrices, pricing tables, compliance details, and benchmarks should be in reference files. There's only one reference at the very end ('references/quick-reference.md') but the SKILL.md itself contains far more detail than a quick reference would. The content that's inline dwarfs what's delegated.