update-data-product

Modifying/Updating an Existing Data Product

This skill governs the end-to-end workflow for researching, planning, implementing, and validating changes to an existing Cortex data product (in either standard or custom namespaces).

Because modifying existing products carries risk of breaking downstream dependencies or replication chains, you MUST perform thorough impact research and obtain user approval on the plan BEFORE modifying any files.

---

Phase 1: Impact Research & Analysis (MANDATORY 4 STEPS)

Before writing any code, you must execute the following research steps and present an Impact Analysis Report to the user.

1. Target Discovery & Namespace Auditing

• Locate the target data product under src/data_modules/<namespace>/<source>/products/<type>/.
• Identify the namespace. If it is in the standard cortex namespace, you MUST warn the user that modifying standard modules directly is against best practices and risks being overwritten during future framework updates. You MUST recommend using the Clone & Modify strategy (copying the core product folder to your custom namespace under src/data_modules/<custom_namespace>/<source>/products/<type>/ and registering it in config.yaml as an override) to ensure upgrade safety and isolation.

2. Downstream Dependency Analysis

• Use grep search or glob tools to identify all models, views, Dataform definitions, or BI configs across the repository that query or depend on the tables and columns of this target data product.
• Document all dependencies in the impact report to prevent breaking downstream transformations.

3. GCP & BI Deployed Assets Impact Analysis (BigQuery, Data Catalog & Looker MCP)

• If MCP access to GCP BigQuery, GCP Knowledge/Data Catalog, and/or Looker BI is available, you MUST use it to trace and understand if your changes impact already deployed assets in GCP or Looker:
  • Read Config Targets: Parse the active .cortex/config.yaml (or active profile config) to extract target environment details, specifically:
    • buildEnvironment.buildProjectId (Target Google Cloud Project)
    • data.targets.<foundation_target>.datasetId (Foundation dataset)
    • data.targets.<product_target>.datasetId (Product dataset)
  • Query View Definitions: Use the available BigQuery MCP tools (e.g. view retrieval, metadata search, or table inspection tools) to check definitions of existing active views or scheduled queries in BigQuery to identify any external dependencies (e.g., other projects, dashboards, or reporting tools) that query this table/view.
  • Inspect Lineage: If a GCP Knowledge/Data Catalog MCP is configured, use it to lookup metadata records or trace lineages to discover downstream cloud assets.
  • Trace Looker Dependencies: If a Looker MCP is available, use it to search for Looker views, LookML Explores, dimensions, measures, or active dashboards that reference the target tables/columns being updated to prevent breaking downstream business intelligence dashboards.