Content
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a reasonable framework for building Snowflake data quality tests and deploying them to Orchestra, with a useful YAML template and concrete MCP tool calls. However, it suffers from apparent copy-paste contamination in the troubleshooting section (references to motherduck, dlt, snapshots, and prod promotion that are irrelevant to a testing pipeline), inconsistent formatting, and missing validation steps between stages. The lack of executable Snowflake inspection queries in Step 1 and the absence of any bundle structure weaken its overall utility.
Suggestions
Remove or replace the Step 5 failure troubleshooting content that references motherduck, dlt, RESTORE snapshots, and prod promotion — these are clearly from a different skill and create confusion.
Add executable SQL queries in Step 1 for inspecting Snowflake tables (e.g., INFORMATION_SCHEMA queries to list tables, columns, and sample data for threshold determination).
Extract the YAML template into a separate reference file (e.g., TEMPLATE.yml) and reference it from the main skill to improve progressive disclosure.
Add an explicit validation checkpoint between Steps 2 and 3 (e.g., validate YAML syntax, confirm test coverage with user) and fix the inconsistency where Step 1 references 'Step 4' for user validation but Step 4 is actually pipeline registration.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill contains a substantial YAML example which is useful as a template, but there's significant verbosity in Step 5's failure troubleshooting section that references irrelevant scenarios (motherduck destinations, dlt requirements, RESTORE from snapshots) that don't apply to a Snowflake testing pipeline. Some content feels copy-pasted from a different skill. | 2 / 3 |
Actionability | Step 1 provides good conceptual guidance on test types but lacks executable code for the Snowflake inspection queries. Steps 4-5 provide concrete MCP tool calls which is good, but Step 3 is vague ('Create a new branch... Push the yml') without specifying how. The YAML template in Step 2 is concrete and copy-paste ready, which helps. | 2 / 3 |
Workflow Clarity | The 5-step sequence is clear and logical, and Step 5 includes a polling loop and failure diagnosis flow. However, there are no explicit validation checkpoints between steps (e.g., validating the YAML before pushing, confirming Snowflake connectivity before building tests). Step 1 mentions 'prompt the user to validate in Step 4' but Step 4 is about registering, not validating test scope. The step numbering is also inconsistent (Steps 3-5 use ### while Steps 1-2 use #). | 2 / 3 |
Progressive Disclosure | Everything is in a single monolithic file with no references to supporting documents. The large YAML example could be in a separate template file. There are no bundle files, and the failure troubleshooting in Step 5 references concepts from an entirely different pipeline type (motherduck/dlt), suggesting content was pasted from another skill without proper adaptation. | 1 / 3 |
Total | 7 / 12 Passed |