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
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.
Avoid it for unit tests or outside the seeknal/atlas ecosystem, or when the live infrastructure (Lakekeeper, MinIO, PostgreSQL) is unreachable.
Security analysis
CautionNo 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.
- •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
Examples
/qa/qa qa/specs/named-refs-common-config.yml/qa specs/2026-02-20-feat-source-defaults-environment-switching.mdname: 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 inqa/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:
- Validate the file exists. If not found, abort with:
Error: File not found: {path} - 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:
-
Validate file exists. If not found, abort with:
Error: File not found: {path} -
Warn if not in specs/ directory:
Note: Input file is not from specs/ directory. Proceeding anyway. -
Derive output name from the
.mdfilename:- 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| - Strip date prefix matching
-
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). -
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. -
Print summary:
Spec generated: {generated_spec_path} Source type: {source_type} Pipeline nodes: {count} Features tested: {count} -
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 namesource_type: csv, iceberg, or postgresqlinfrastructure.requires: List of required servicesdescription: 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:
- Create a task via TaskCreate describing what the worker should do
- 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 filesThis 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.mdFrom 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 installationopenskills 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 syncManual 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.
ClickHouse Performance Comparison
Testing
Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.
Analyze CI Performance Reports
Testing
Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.
Santa Method
Testing
Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.