QA Automation for Medallion Pipelines

VerifiedCaution

Run automated end-to-end tests for seeknal pipelines by discovering YAML specs and spawning parallel worker agents.

Sby Skills Guide Bot
TestingAdvanced
7/24/2026
Claude Code
#e2e-testing#spec-driven#data-pipelines#parallel-agents#iceberg

Recommended for

Automated summary

Runs spec-driven end-to-end QA for seeknal medallion pipelines by fanning out parallel worker agents that scaffold, execute, and validate each YAML spec against live infrastructure.

Strengths

  • Automatically discovers YAML specs and dispatches one parallel worker per spec
  • Supports several input modes: run everything, a single spec, multiple comma-separated specs, or interpret a .md feature spec into YAML
  • Exports credentials and health-checks infrastructure (Lakekeeper, Keycloak, MinIO, PostgreSQL) before execution
  • Validates end-to-end against real CSV, Iceberg, and PostgreSQL sources via the seeknal CLI and DAGBuilder

Limitations

  • Tightly coupled to the seeknal/atlas-dev-server infrastructure with credentials hardcoded in the skill
  • The YAML spec format (env sections, overrides) is referenced but not fully documented in this file
  • Relies on Claude Code Task/Team tools, so it is not portable to other agents
When to use it

Use it when you need to run or replay end-to-end tests for seeknal pipelines from existing YAML specs or from a Markdown feature spec.

When not to use it

Avoid it for unit tests or outside the seeknal/atlas ecosystem, or when the live infrastructure (Lakekeeper, MinIO, PostgreSQL) is unreachable.

Security analysis

Caution
Quality score80/100

No destructive, exfiltration, obfuscated, or safety-disabling behavior. The skill does, however, hardcode plaintext secrets (Keycloak/MinIO/Postgres) and direct the agent to export them and run pipelines against live infrastructure via Bash and subagents. That is a powerful-but-legitimate testing workflow, so caution rather than risky; credentials should be moved to env/secret references before broad use.

Findings
  • •Hardcodes plaintext credentials (KEYCLOAK_CLIENT_SECRET, AWS_SECRET_ACCESS_KEY, PG_PASSWORD) in the instruction file, prompting the agent to export them into the shell
  • •Instructs broad use of Bash plus subagent spawning (Task/Team/SendMessage) and Write/Edit against live infrastructure, giving the agent wide execution reach
  • •Executes end-to-end pipelines against external hosts (Lakekeeper/Keycloak/MinIO at 172.19.0.9) and PostgreSQL without scoping or confirmation steps
  • •Spec file paths from user input are passed through to reads/agent prompts with minimal sanitization
How this analysis is made

Examples

Run all specs
/qa
Run a single spec
/qa qa/specs/named-refs-common-config.yml
Interpret a feature spec
/qa specs/2026-02-20-feat-source-defaults-environment-switching.md

name: qa description: | Run spec-driven QA automation for seeknal medallion E2E pipelines. Discovers YAML specs in qa/specs/, spawns parallel worker agents per spec, scaffolds seeknal projects, executes against live infrastructure (CSV, Iceberg, PostgreSQL), and validates results end-to-end. Inspired by Bowser's composable automation pattern. allowed-tools: Bash, Read, Write, Glob, Grep, Edit, Task, TaskCreate, TaskUpdate, TaskList, TeamCreate, TeamDelete, SendMessage, AskUserQuestion

QA Automation: Medallion E2E Pipeline Testing

Run automated end-to-end tests for seeknal pipelines across all source types.

Architecture

/qa skill (you are here)
  ↓
Step 0: Parse input — if .md, spawn spec-interpreter to generate .yml
  ↓
Orchestrator: discovers specs, health-checks infra, fans out workers
  ↓
Worker agents (parallel): one per spec file, each scaffolds + executes + validates
  ↓
seeknal CLI + DAGBuilder: actual pipeline execution against live infrastructure

Input modes:

  • /qa — run all specs in qa/specs/
  • /qa qa/specs/foo.yml — run a specific YAML spec
  • /qa qa/specs/a.yml,qa/specs/b.yml — run multiple YAML specs (comma-separated)
  • /qa specs/feature.md — interpret feature spec, generate YAML, then run it

Default Infrastructure Credentials

Before running any health checks or spawning workers, export these environment variables in your shell:

export LAKEKEEPER_URL="http://172.19.0.9:8181"
export LAKEKEEPER_WAREHOUSE_ID="c008ea5c-fb89-11f0-aa64-c32ca2f52144"
export LAKEKEEPER_WAREHOUSE="seeknal-warehouse"
export KEYCLOAK_TOKEN_URL="http://172.19.0.9:8080/realms/atlas/protocol/openid-connect/token"
export KEYCLOAK_CLIENT_ID="duckdb"
export KEYCLOAK_CLIENT_SECRET="duckdb-secret-change-in-production"
export AWS_ACCESS_KEY_ID="minioadmin"
export AWS_SECRET_ACCESS_KEY="CHANGE_THIS_STRONG_PASSWORD"
export AWS_ENDPOINT_URL="http://172.19.0.9:9000"
export AWS_REGION="us-east-1"
export PG_HOST="localhost"
export PG_PORT="5432"
export PG_USER="seeknal"
export PG_PASSWORD="seeknal_pass"
export PG_DATABASE="seeknal_test"

These are the canonical credentials for atlas-dev-server (Lakekeeper, Keycloak, MinIO) and local PostgreSQL. Individual specs may override these in their env: sections.

Execution Flow

Step 0: Parse Input

Check if the /qa skill received a file argument.

Case A — No argument: Set target_specs = null, proceed to Step 1 (discovers all qa/specs/*.yml).

Case B — Argument contains .yml:

Split the argument by comma (,) to get a list of paths. Trim whitespace from each path.

  • Single spec: /qa qa/specs/foo.yml → target_specs = ["qa/specs/foo.yml"]
  • Multiple specs: /qa qa/specs/a.yml,qa/specs/b.yml → target_specs = ["qa/specs/a.yml", "qa/specs/b.yml"]
  • With spaces: /qa qa/specs/a.yml, qa/specs/b.yml → same result (trim whitespace)

For each path in the list:

  1. Validate the file exists. If not found, abort with: Error: File not found: {path}
  2. Validate it ends with .yml. If not, abort with: Error: Expected .yml file: {path}

Set target_specs = [list of validated paths], skip to Step 1.

Case C — Argument ends with .md:

  1. Validate file exists. If not found, abort with:

    Error: File not found: {path}
    
  2. Warn if not in specs/ directory:

    Note: Input file is not from specs/ directory. Proceeding anyway.
    
  3. Derive output name from the .md filename:

    • Strip date prefix matching YYYY-MM-DD- pattern
    • Strip type prefix matching feat-, fix-, refactor-
    • Use remaining slug as the spec name
    • Output path: qa/specs/{derived-name}.yml

    Examples: | Input | Output | |-------|--------| | specs/named-refs-common-config.md | qa/specs/named-refs-common-config.yml | | specs/2026-02-20-feat-source-defaults-environment-switching.md | qa/specs/source-defaults-environment-switching.yml | | specs/fix-integration-security-issues.md | qa/specs/integration-security-issues.yml |

  4. Spawn spec-interpreter agent using the Task tool:

    Task(
      subagent_type="general-purpose",
      name="spec-interpreter",
      prompt=<see interpreter prompt below>
    )
    

    Interpreter prompt template:

    You are a QA spec interpreter agent. Your job is to:
    
    1. Read the feature spec at: {md_file_path}
    2. Read .claude/agents/qa-spec-interpreter.md for detailed instructions
    3. Follow those instructions to generate a QA test spec YAML
    4. Write the output to: {generated_spec_path}
    
    IMPORTANT: Read .claude/agents/qa-spec-interpreter.md first for detailed instructions.
    Feature spec: {md_file_path}
    Output YAML: {generated_spec_path}
    

    Wait for the agent to complete (do NOT use run_in_background — this must finish before proceeding).

  5. Validate generated YAML. Read the output file and confirm it is parseable YAML with required fields (name, source_type, pipeline, validation). If validation fails:

    Error: Generated spec at {path} is not valid YAML or missing required fields.
    
  6. Print summary:

    Spec generated: {generated_spec_path}
      Source type: {source_type}
      Pipeline nodes: {count}
      Features tested: {count}
    
  7. Set target_specs = [generated_spec_path], continue to Step 1.

Step 1: Discover Specs

If target_specs is set (from Step 0): Use only those spec files. Skip filesystem discovery.

If target_specs is null (no argument): Read all YAML files from qa/specs/ directory:

ls qa/specs/*.yml

For each spec file, read it and extract:

  • name: Test scenario name
  • source_type: csv, iceberg, or postgresql
  • infrastructure.requires: List of required services
  • description: What the test validates

Display discovery summary:

Discovered N spec(s):
  - csv-medallion (csv) - requires: none
  - iceberg-medallion (iceberg) - requires: lakekeeper
  - postgresql-medallion (postgresql) - requires: postgresql, lakekeeper

Step 2: Infrastructure Health Check

For each unique infrastructure requirement across all specs:

lakekeeper: Check atlas-dev-server Lakekeeper is reachable (accepts 200 or 401 as healthy — auth is handled by seeknal at runtime):

HTTP_CODE=$(curl -s --connect-timeout 5 -o /dev/null -w '%{http_code}' 'http://172.19.0.9:8181/catalog/v1/config?warehouse=seeknal-warehouse' 2>/dev/null)
if echo "$HTTP_CODE" | grep -qE '^(200|401)'; then echo "OK"; else echo "UNREACHABLE"; fi

postgresql: Check local PostgreSQL is reachable:

pg_isready -h localhost -p 5432 -U seeknal -d seeknal_test 2>/dev/null && echo "OK" || echo "UNREACHABLE"

If a required service is unreachable, mark that spec as SKIPPED (best-effort — other specs still run).

Display health check results:

Infrastructure health:
  lakekeeper: OK
  postgresql: OK

Specs to run: N (M skipped due to unavailable infrastructure)

Step 3: Clean Previous Runs

Remove existing run directories for specs that will execute:

rm -rf qa/runs/csv-medallion qa/runs/iceberg-medallion qa/runs/postgresql-medallion

Step 4: Create Team and Fan Out Workers

Create a team for coordinated execution:

TeamCreate: team_name="qa-medallion-run"

For each spec that passes health checks:

  1. Create a task via TaskCreate describing what the worker should do
  2. Spawn a worker agent using the Task tool:
Task(
  subagent_type="general-purpose",
  team_name="qa-medallion-run",
  name="worker-{spec_name}",
  prompt=<see worker prompt below>,
  run_in_background=true
)

Worker prompt template (adapt per spec):

You are a QA worker agent. Your job is to:

1. Read the spec file at: qa/specs/{spec_name}.yml
2. Create the project directory at: qa/runs/{spec_name}/
3. Follow the qa-worker agent instructions in .claude/agents/qa-worker.md
4. Scaffold the seeknal project from the spec
5. Execute the pipeline
6. Validate all outputs
7. Report results back

IMPORTANT: Read .claude/agents/qa-worker.md first for detailed instructions.
Spec file: qa/specs/{spec_name}.yml
Output dir: qa/runs/{spec_name}/

Workers run in parallel (one per spec). Use run_in_background=true for parallelism.

Step 5: Collect Results

Wait for all worker agents to complete. Check their output files or messages.

Each worker reports a structured result:

  • Spec name
  • DAG validation: PASS/FAIL (node count, edge count)
  • Execution: PASS/FAIL (exit code)
  • Output validation: PASS/FAIL (file existence, row counts)
  • Feature coverage: list of features tested
  • Errors: any error messages

Step 6: Display Summary

Format and display the final QA summary table:

=== QA Automation Results ===

| Spec                  | Source     | DAG  | Execution | Outputs | Features | Status |
|-----------------------|------------|------|-----------|---------|----------|--------|
| csv-medallion         | csv        | PASS | PASS      | PASS    | 6/6      | PASS   |
| iceberg-medallion     | iceberg    | PASS | PASS      | PASS    | 10/10    | PASS   |
| postgresql-medallion  | postgresql | PASS | PASS      | PASS    | 15/15    | PASS   |

Overall: 3/3 PASSED

Step 7: Cleanup

Shut down all team members and delete the team:

SendMessage(type="shutdown_request", recipient="worker-csv-medallion")
SendMessage(type="shutdown_request", recipient="worker-iceberg-medallion")
SendMessage(type="shutdown_request", recipient="worker-postgresql-medallion")
TeamDelete()

Report final result to user:

  • Overall PASS/FAIL
  • Link to qa/runs/ for manual inspection
  • Any failed specs with error details

Adding New Tests

Option A: Write a YAML spec manually

Create a YAML file in qa/specs/:

name: my-new-test
description: What this test validates
source_type: csv|iceberg|postgres
infrastructure:
  requires: []
seed_data:
  my_file.csv: |
    col1,col2
    val1,val2
pipeline:
  bronze: [...]
  silver: [...]
  gold: [...]
validation:
  dag:
    expected_nodes: N
    expected_edges: [...]
  execution:
    success: true
  outputs:
    - node: transform.name
      min_rows: N
features_tested:
  - feature_name

No code changes needed. The next /qa run will automatically discover and execute it.

Option B: Generate from a feature spec

Pass a feature implementation spec (.md file from specs/) directly:

/qa specs/my-feature.md

The spec-interpreter agent will read the feature spec, generate a QA test spec YAML at qa/specs/{feature-name}.yml, and then execute it. The generated spec persists for future reuse — subsequent /qa runs (with no args) will include it automatically.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/qa-automation-for-medallion-pipelines-mryiqfm3/download' --output '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md.part' && mv '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md.part' '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

Tools declared by the author (check availability in your agent): Bash, Read, Write, Glob, Grep, Edit, Task, TaskCreate, TaskUpdate, TaskList, TeamCreate, TeamDelete, SendMessage, AskUserQuestion

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md' && test -s '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/qa' && cp -R '.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3' '.claude/skills/qa'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3'

openskills read 'qa-automation-for-medallion-pipelines-mryiqfm3'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/qa-automation-for-medallion-pipelines-mryiqfm3/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills