test

Estrellas0

Forks0

Actualizado10 de junio de 2026 a las 12:49

Run and design verification for code, data pipelines, SQL, Spark, notebooks, and UI changes. Use for unit, integration, e2e, schema, row count, reconciliation, idempotency, coverage, build, and QA reports.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

datacoolie

datacoolie/dekit

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

SKILL.md

readonly

name	test
description	Run and design verification for code, data pipelines, SQL, Spark, notebooks, and UI changes. Use for unit, integration, e2e, schema, row count, reconciliation, idempotency, coverage, build, and QA reports.

Test

Use the smallest test set that proves the acceptance criteria. Escalate to full suite when risk requires it.

Scope Selection

Narrow change: run affected tests.
Config, shared helper, dependency, infrastructure, or high fan-out change: run full suite.
Data pipeline change: run transformation tests plus schema/quality/reconciliation checks.
Notebook change: restart and run top-to-bottom where practical.
UI change: check console errors, key flows, and responsive/visual behavior.

Diff-Aware Mapping

Identify changed files.
Map to co-located tests, mirrored tests, importers, or pipeline quality checks.
List unmapped changed files and proposed tests.
Escalate to full suite if mapping covers most tests or risk is broad.

Data Test Checklist

Schema assertion.
Row count range.
Key uniqueness.
Required field completeness.
Freshness window.
Source-to-target reconciliation.
Idempotency rerun.
SCD history integrity when relevant.
Boundary data: empty, single row, null-heavy, duplicates.

Standards

Do not suppress failures.
Tests must be deterministic and isolated.
Integration tests should use representative data, not mocks that hide source behavior.
Report exact commands and results.

Output

Scope: <affected|full|explicit>
Commands:
- <command> -> <result>
Results: <passed/failed/skipped>
Coverage or quality gaps:
- ...
Blockers:
- ...
Open questions:
- ...

Más de este repositorio

mismo repositorio

wiki

datacoolie/dekit

Build and maintain an internal technical LLM wiki when the user requests wiki work or a verified major or architectural change qualifies for automatic wiki review. Use for project memory, architecture notes, contracts, runbooks, decisions, glossary, incremental ingest, delta status, and wiki health. Do not use merely because a routine task or plan completed.

2026-07-180

brainstorm

datacoolie/dekit

Explore ambiguous ideas and solution directions before evidence-backed research or implementation planning. Use for ideation, framing, assumption checks, option generation, product or architecture trade-offs, and deciding whether research or a plan is needed.

2026-07-030

research

datacoolie/dekit

Research technical options with source-backed recommendations. Use for technology evaluation, architecture trade-offs, library/framework choices, best practices, scalability, security, maintainability, or when current external facts matter.

2026-07-030

plan

datacoolie/dekit

Create implementation plans, architecture decisions, and phased roadmaps. Use for Standard or Complex changes, new pipelines, schema changes, migrations, multi-file features, technology choices, or when acceptance criteria and verification strategy are unclear.

2026-06-170

code-review

datacoolie/dekit

Review code and data pipeline changes for correctness, security, performance, maintainability, contract breaks, and missing verification. Use before merge, after implementation, for PRs, commits, pending diffs, or codebase risk scans.

2026-06-100

data-ingestion

datacoolie/dekit

Design data ingestion into landing/bronze layers. Use for source onboarding, transfer pattern selection, full/incremental/CDC scope, change detection, landing zones, schema drift, idempotent file or batch processing, and ingestion quality gates.

2026-06-100

name	test
description	Run and design verification for code, data pipelines, SQL, Spark, notebooks, and UI changes. Use for unit, integration, e2e, schema, row count, reconciliation, idempotency, coverage, build, and QA reports.

Test

Use the smallest test set that proves the acceptance criteria. Escalate to full suite when risk requires it.

Scope Selection

Narrow change: run affected tests.
Config, shared helper, dependency, infrastructure, or high fan-out change: run full suite.
Data pipeline change: run transformation tests plus schema/quality/reconciliation checks.
Notebook change: restart and run top-to-bottom where practical.
UI change: check console errors, key flows, and responsive/visual behavior.

Diff-Aware Mapping

Identify changed files.
Map to co-located tests, mirrored tests, importers, or pipeline quality checks.
List unmapped changed files and proposed tests.
Escalate to full suite if mapping covers most tests or risk is broad.

Data Test Checklist

Schema assertion.
Row count range.
Key uniqueness.
Required field completeness.
Freshness window.
Source-to-target reconciliation.
Idempotency rerun.
SCD history integrity when relevant.
Boundary data: empty, single row, null-heavy, duplicates.

Standards

Do not suppress failures.
Tests must be deterministic and isolated.
Integration tests should use representative data, not mocks that hide source behavior.
Report exact commands and results.

Output

Scope: <affected|full|explicit>
Commands:
- <command> -> <result>
Results: <passed/failed/skipped>
Coverage or quality gaps:
- ...
Blockers:
- ...
Open questions:
- ...