just-vibeData engineering · plan by default
/data-contract
Define schema, semantics, freshness, and quality constraints
Use to define producer/consumer data expectations; data-quality checks an accepted contract; arch-contracts owns service interface design.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select data-contract from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv data-contract, /just-vibe data-contract and /jv:data-contract in Claude. See shortcut setup and context examples.
/just-vibe:data-contract Define schema, event-time semantics, freshness, and violation handling for orders./just-vibe:data-contract Define a contract for late-arriving corrections and optional new fields./just-vibe:data-contract Draft a contract without agreed freshness thresholds; do not invent producer commitments.What the agent does
- Identify the actual consumption paths and the required fields and keys.
- Specify grain, keys, types, units, ranges, nullability, event/arrival time and freshness from them.
- Define allowed schema evolution, versioning and violation handling.
Inputs
- producer/consumer needs, schema, field meaning, freshness, and quality requirements.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Machine-checkable and semantic obligations across a data boundary.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. data-pipeline or fix applies an accepted change.
- Mode
- Plan; producer/consumer needs, schema, field meaning, freshness, and quality requirements.
- Prerequisites
- Data source/version, schema/semantics, transformation code, permitted sampling scope, and storage/compute budget. Prefer aggregates and redacted samples; never upload datasets to external services implicitly. Record time zones and snapshot identity for reproducibility.
Expected output
- Versioned field/rule/response contract with accepted and rejected examples, validation rules and ownership questions.
How the work is checked
- Syntactically valid but semantically invalid values can fail; an additive schema change has defined compatibility behavior.
When to stop or clarify
- Do not invent quality thresholds or ownership agreement. Unresolved thresholds remain proposed values with rationale.
Handling missing context
- Infer
- Inspect schema, source snapshot, transformation code, grain, time zones and permitted sample scope.
- Assume
- Use bounded synthetic or supplied samples when full data is unavailable; keep unknown values distinct from zero.
- Ask
- Resolve ambiguous entity/grain/time semantics before reconciliation or backfill; obtain missing data/compute limits only for the dependent scan or execution.
Technical guidance
- Evidence
- Identify producer/consumer schema, semantic units, key uniqueness, timeliness and allowed evolution.
- Method
- Specify compatibility and quarantine behavior for missing, late, duplicate and newly introduced values.
- Pitfall
- Type-valid data can still be wrong in units, timezone or row grain.
- Check
- Test valid, structurally invalid and semantically wrong records plus a compatible schema evolution with real consumer decoding.
Situational decisions
When thresholds or ownership have not been agreed: Mark them proposed with rationale and name the decision needed before enforcement.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.