Content
57%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a rich, actionable pattern catalog with concrete code across GE, dbt, data contracts, and orchestration, but it over-explains known concepts, mixes GX API versions, and inlines ~590 lines with no progressive file-splitting. Tightening Core Concepts, unifying the GX API, and extracting large examples into reference files would lift the lower dimensions.
Suggestions
Trim or remove the 'Core Concepts' Data Quality Dimensions table and Testing Pyramid diagram — these are concepts Claude already knows — and de-duplicate the status enum repeated across multiple patterns.
Unify the Great Expectations API style (legacy ExpectationConfiguration vs. new gx.get_context()/suite.add_expectation) so each snippet is copy-paste runnable against a single GX version.
Extract the large concrete blocks (full data contract YAML, the DataQualityPipeline class, the orders expectation suite) into one-level-deep reference files (e.g. contracts/EXAMPLES.md, pipelines/REFERENCE.md) linked from the body to improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The "Core Concepts" section explains the Data Quality Dimensions table and Testing Pyramid ASCII diagram — concepts Claude already knows — and the status enum ["pending", ...] is repeated across four patterns; the bulk is concrete code so it is mostly efficient, but the unnecessary explanation exceeds the "minor" threshold for a 4. | 3 / 5 |
Actionability | Extensive executable code (pip install, GE expectation suites, dbt YAML, SQL generic/singular tests, data contract YAML, orchestration class) is mostly copy-paste ready, but the snippets mix the legacy fluent GX API (ExpectationConfiguration, ExpectationSuite(...)) with the newer gx.get_context()/suite.add_expectation API — minor version gaps. | 4 / 5 |
Workflow Clarity | The skill is a pattern catalog rather than a guided sequenced workflow, and the batch validation pipeline (Pattern 6) only checks result.success at the very end with no mid-process validation checkpoints; the batch-operation cap at 3 applies. | 3 / 5 |
Progressive Disclosure | No bundle files exist and ~590 lines are inlined in a single SKILL.md with good section headers but no references to separate files (only external doc links); content that could be split (full data contract YAML, pipeline class, GE suite builder) is all inline, so structure is present but content that should be separate is not split out. | 3 / 5 |
Total | 13 / 20 Passed |