test

Étoiles0

Forks0

Mis à jour10 juin 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

datacoolie

datacoolie/dekit

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·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:
- ...

Plus depuis ce dépôt

même dépôt

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:
- ...