model-data
/model-data — Model Plan interview
This skill runs a short, branching interview that converts a planned (or existing-but-undocumented) transformation into a Model Plan markdown file at docs/model-plans/<model>.md in the consumer's project. It is an interview, not a template — every plan that lands has been pressure-tested against the Transformation kill-switch (a named upstream Storage Plan), the grain-must-resolve-to-a-cardinality test, the assertions-honesty test (business-invariant is earned, not asserted aspirationally), the sensitivity-propagation test, and the "is this actually an ADR moment?" routing test.
This skill is self-contained: the vocabulary it leans on is inlined just below, the Model Plan contract it writes against ships beside it at references/model-plan.md, and the linter that enforces that contract ships at scripts/lint-model-plan.sh. Read the contract for the artefact's frontmatter fields, enum domains, and body section order before writing — do not duplicate it into the interview; reference it.
Vocabulary this skill assumes (the minimum it needs; the full worldview is optional deeper reading, linked at the end):
- Model Plan. The data team's version-controlled model of a single transformation — the grain ("one row per what"), the layer, the materialization, the modelling convention it honours, the assertion posture, its intra-stage dependencies, the sensitivity, and the canonical definition it owns for downstream consumers. The operational and contractual model of the transformation, not a project-management plan and not a dbt/SQL model file (it contains no SQL). Stage 4's deliverable; one file per model at
docs/model-plans/<model>.md. - Transformation kill-switch. An accepted Model Plan must name at least one upstream Storage Plan in
related_storage_plans. A model that does not chain back to governed storage is ungoverned business logic — the duplicated-revenue-definition failure mode — masquerading as a real table. This is the soul of the skill; see the next section. assertionsposture. The Stage-4-distinctive honesty field —business-invariant(a test ties to a named business truth),shape-only(onlynot null/unique/ referential checks), ornone(no tests yet).business-invariantis earned, not asserted aspirationally;shape-onlyandnoneare honest, accepted answers, not failures to punish.
Optional deeper reading — not required to run this skill (a per-skill install works without them): the full repo worldview in CONTEXT.md and the lifecycle reference in docs/data-engineering-101.md.
A Model Plan is neither of the two things its name risks being read as. It is not a project-management plan for a modelling effort — no TODO list, owners, or delivery dates. It is not a dbt/SQL model file — it contains no SQL, no ref(), no Jinja, no Dataform/SQLMesh config. It is the operational and contractual model of the transformation: the human-authored commitments (grain, layer, materialization, convention, assertions, canonical definition, downstream contract) that the actual SQL/dbt/Dataform/SQLMesh code should reflect. The code that implements those commitments lives in the consumer's transformation repo and is out of scope — this skill emits no SQL, no dbt model, no test YAML. The plan is the contract the code should be reviewed against, not a substitute for it. It is the structural analogue of the Storage Plan one stage upstream, deliberately human-authored and never inferred from a tool: no manifest.json parsing, no INFORMATION_SCHEMA scan, no warehouse or dbt/Dataform project introspection.
Soul of the skill: the Transformation kill-switch
The single load-bearing question this skill exists to force is: