Quality gate for model generation output. Reviews the generated dbt model SQL and schema YAML for standards compliance, correctness against the original stored procedure, and test integration with the approved test spec. Issues a verdict: approve, kick back with specific fixes (including stable reference codes and severity tiers), or approve with warnings after max iterations. This skill does not modify any files -- it is a pure quality gate.

/reviewing-model <schema.table>

Argument is the fully-qualified table name (the item_id). This skill is invoked by the /generate-model command after dbt tests pass, not directly by the user.

• manifest.json must exist in the project root.
• Generated model SQL must exist at the expected path (e.g., dbt/models/staging/stg_<table>.sql and/or dbt/models/<layer>/<table>.sql).
• test-specs/<item_id>.json must exist (the approved test spec).

uv run --project <shared-path> migrate context --table <item_id>

Also reads:

• The generated model SQL and schema YAML from the dbt project
• The approved test spec from test-specs/<item_id>.json

Context includes refactored_sql but the reviewer does not use it. Ground truth is always the original proc (proc_body).

Compare the generated model against proc_body (the original proc DDL). This is the primary check.

Both correctness and standards checks always run regardless of the other's result.

Evaluate against reference files. Each issue must include a stable reference code (e.g., SQL_001, CTE_002).

• Every unit_tests[] entry from the test spec is rendered in the schema YAML
• given[].input references match actual source() / ref() calls in the model
• No test scenarios were dropped or modified during rendering
• Gap tests (test_gap_*) have reasonable expectations consistent with model logic

After kicking back, the model generator revises the model, re-runs dbt test, and resubmits. The resubmission must include an acknowledgements block mapping each feedback code to fixed or ignored: <reason>. Maximum review/model-generator iterations: 2.

None. The reviewer emits a ModelReviewResult JSON structure as output but does not modify any files.

{
  "item_id": "silver.dimproduct",
  "status": "revision_requested",
  "checks": {
    "standards": {
      "passed": true,
      "issues": []
    },
    "correctness": {
      "passed": false,
      "issues": [
        {
          "code": "MISSING_SOURCE_TABLE",
          "message": "bronze.product_category referenced in proc but not in model import CTEs",
          "item_id": "silver.dimproduct",
          "severity": "error",
          "details": {}
        }
      ]
    },
    "test_integration": {
      "passed": true,
      "issues": []
    }
  },
  "feedback_for_model_generator": [
    {
      "code": "SQL_001",
      "message": "Keywords should be lowercase — found uppercase SELECT on line 4",
      "severity": "error",
      "ack_required": true
    },
    {
      "code": "CTE_002",
      "message": "Final CTE must be named 'final' — currently named 'output'",
      "severity": "error",
      "ack_required": true
    },
    {
      "code": "SQL_013",
      "message": "Line 12 exceeds 80 characters",
      "severity": "info",
      "ack_required": false
    }
  ],
  "acknowledgements": {
    "SQL_001": "fixed",
    "CTE_002": "ignored: legacy naming convention required by downstream tool"
  },
  "warnings": [],
  "errors": []
}

acknowledgements is present on resubmission only -- a flat map of { "<code>": "fixed" | "ignored: <reason>" }. The model-generator must acknowledge all ack_required: true items before resubmission.

Each check area has the same structure:

Standards:

Correctness:

Test integration:

checks.*.issues[], warnings[], and errors[] use the shared diagnostics schema:

The model reviewer must not:

• Modify model SQL or schema YAML files
• Run dbt tests or compile commands
• Generate or modify test fixtures
• Override profile decisions (classification, materialization, keys)
• Override ground truth (captured proc output is fact)