Use when requirements, KPIs, business questions, dashboards, APIs, semantic models, ML datasets, or data outputs need a clear data product boundary, consumer, owner, lifecycle, trust level, or service expectation.
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.
Use when requirements, KPIs, business questions, dashboards, APIs, semantic models, ML datasets, or data outputs need a clear data product boundary, consumer, owner, lifecycle, trust level, or service expectation.
des-data-product-definition
Purpose
Use this skill to create and validate the Data Product Specification for any data engineering project.
This skill defines:
data product boundary;
target consumers;
supported use cases;
product outputs;
service expectations;
ownership and stewardship;
freshness expectations;
trust expectations;
access and serving expectations;
lifecycle status.
The goal is to ensure the project delivers a usable data product rather than a collection of disconnected pipelines, tables, dashboards, notebooks, APIs, or scripts.
In the Phase-Orchestrated Support Model, this phase is not Done when the Data Product Specification is first written.
Phase 04 is Done only when:
Data Product Specification exists
+ Phase 03 artifact and handoff are reviewed
+ data product boundary validation work is identified
+ product definition evidence is collected or waived with reason
+ artifact is revised from evidence
+ Phase 04 Done Gate passes
+ Phase 04 to Phase 05 handoff exists
When To Use
Use this skill when:
Phase 01 Business Discovery exists;
Phase 02 Business Question Catalog exists;
Phase 03 Requirements and KPI Catalog exists;
Phase 03 handoff exists or the user explicitly accepts the risk of continuing without it;
consumers, business questions, requirements, KPIs, or success criteria need to be packaged into a defined data product;
the user asks for dashboards, semantic models, APIs, ML datasets, data sharing, operational data outputs, or customer-facing analytics;
the workflow router selects Phase 04.
Do not use this skill to design physical tables, source ingestion, transformations, data contracts, orchestration, semantic model details, dashboards, APIs, or code.
Identify output_file, template_file, checklist_file, status_file, and required upstream artifacts.
Identify Phase-Orchestrated Support files:
phase_support_plan_file;
phase_evidence_pack_file;
phase_artifact_revision_file;
phase_done_gate_file;
phase_handoff_file.
Load only steps/step-01-context-and-readiness.md.
Do not load step-02 or step-03 until the current step explicitly instructs you to continue.
Stop at every HALT point and wait for user input.
Do not invent consumers, product outputs, service levels, owners, lifecycle status, trust expectations, or product boundaries.
Do not design physical tables, sources, pipelines, transformations, full data contracts, dashboards, semantic model internals, APIs, application implementation, or code.
Before marking Phase 04 as Done, create or update the support plan, evidence pack, artifact revision notes, Done Gate, handoff, and workflow status.
Process Overview
The detailed execution procedure lives in steps/.
At a high level, this skill will:
Confirm upstream discovery, questions, requirements, and KPI context.
Confirm Phase 03 handoff readiness.
Identify the candidate data product and its consumers.
Define the product boundary and first release scope.
Define supported use cases and product outputs.
Define service expectations, trust expectations, access expectations, and ownership.
Identify dependencies, source needs, risks, assumptions, and open questions.
Ask HALT questions for unresolved product boundary, consumer, output, SLA, trust, lifecycle, and ownership decisions.
Draft the Data Product Specification.
Create the Phase 04 Support Plan.
Collect or reference Phase 04 evidence.
Revise the Data Product Specification using evidence.
Run the Phase 04 Done Gate.
Create the Phase 04 to Phase 05 Handoff.
Update workflow status.
Recommend the next skill.
Do not execute this overview directly. Follow the step files.
Phase-Orchestrated Support Model
Phase 04 uses data-product boundary validation support work.
The purpose is not technical implementation. The purpose is to prevent Phase 05 source assessment from searching for sources before the data product boundary, outputs, trust expectation, consumer, and first release needs are clear.
Required Support Work
Support Work
Purpose
Output
Phase 03 Handoff Review
Check that product definition derives from approved requirements/KPIs.
Evidence pack section
Product Boundary Check
Ensure the product is small enough to own, support, and assess sources for.
Evidence pack section
Consumer and Use Case Alignment Check
Ensure consumers and use cases match upstream context.
Evidence pack section
Product Output Check
Ensure first release output is explicit.
Evidence pack section
Service Expectation Check
Ensure freshness, support, access, reliability, and availability expectations are recorded.
Evidence pack section
Trust Expectation Check
Ensure quality/trust posture is explicit.
Evidence pack section
Ownership and Stewardship Check
Ensure owner/steward exists or is marked Draft/Risk.
Evidence pack section
Lifecycle Status Check
Ensure Experimental/Draft/MVP/Internal shared/Production/etc. is explicit.
Evidence pack section
Phase 05 Source Need Readiness Check
Ensure Phase 05 knows what source evidence to look for.
Evidence pack section
Phase 04 Done Gate
Decide whether Phase 04 is Done, Done with risks, or Blocked.
phase-04-done-gate.md
Phase 04 Handoff
Tell Phase 05 what source needs to assess.
phase-04-to-05-handoff.md
Optional Support Skills
Existing support or learning skills may be used when helpful:
If evidence is missing, mark the item as Draft, Open Question, Risk, Deferred, Blocked, or Waived with reason.
Guardrails
The agent must not:
treat every table or dashboard as a data product automatically;
define a data product without a consumer;
define a data product without a supported use case;
define a product output without access expectations;
define SLA without owner or consumer need;
assume self-service availability without approval;
design physical schemas or Gold tables in this phase;
write data contracts in full; only capture contract expectations;
choose final source systems before Phase 05;
mark the artifact Done if product owner, consumer, product output, trust expectation, or product boundary is unresolved without accepted risk;
mark Phase 04 Done if the handoff to Phase 05 is missing.
Quality Checklist
Upstream discovery, question, and requirements artifacts exist or Draft continuation is explicitly accepted.
Phase 03 handoff exists or missing handoff risk is explicitly accepted.
Data product name and intent are defined.
Primary consumer and supported use case are defined.
Product outputs and first release output are clear.
Product boundary and non-scope are documented.
Service, freshness, trust, and access expectations are documented.
Owner, steward, and lifecycle status are defined or explicitly marked Draft/Risk.
Source needs for Phase 05 are clear enough to assess candidate sources.
Phase 04 support plan exists or is explicitly waived with reason.
Phase 04 evidence pack exists or evidence is explicitly waived with reason.
Phase 04 artifact revision notes exist.
Phase 04 Done Gate result is recorded.
Phase 04 to Phase 05 handoff exists.
The artifact does not design physical schemas, ingestion, transformations, full contracts, semantic internals, dashboards, APIs, application implementation, or code.
Anti-Patterns to Avoid
Anti-Pattern
Why It Fails
Calling a table or dashboard the data product by default
A product also needs consumer, promise, owner, lifecycle, access, trust, and support expectations.
Defining products without consumers
No consumer means no usable scope, success criteria, service level, or prioritization.
Combining unrelated consumers and outputs into one vague product
Ownership, contracts, and service expectations become unstable.
Treating service expectations as implementation details
Freshness, trust, support, and access expectations drive later architecture, quality, and release gates.
Writing full contracts or schemas in Phase 4
Contract and physical design belong to downstream phases after product boundary is approved.
Starting Phase 05 with vague product outputs
Source assessment needs concrete product outputs and requirements to map source feasibility.
HALT Policy
This skill must stop when a product definition decision cannot be safely inferred.
Stop especially when:
Phase 03 Requirements and KPI Catalog is missing or inconsistent;
Phase 03 handoff is missing and the user has not accepted the risk;
primary consumer is unclear;
product boundary is unclear;
first release output is unclear;
product owner or steward is unclear;
product lifecycle status is unclear;
service/freshness expectation is unclear;
trust expectation is unclear;
supported use case conflicts with scope or requirements;
Phase 05 would not know what source evidence to assess;
the user asks for implementation before data product definition is complete.
Handoff To The Next Skill
Recommend des-data-source-assessment only after:
Data Product Specification exists
+ Phase 04 support plan exists or is waived with reason
+ Phase 04 evidence pack exists or evidence is waived with reason
+ Phase 04 Done Gate is Pass or Pass with risks
+ Phase 04 to Phase 05 handoff is Ready or Ready with Risks
If the phase is Draft or Blocked, recommend one of:
continue des-data-product-definition
return to Step 02 product boundary and service design
resolve HALT question
route back to des-requirements-and-kpis
des-wise
des-correct-course
