Quality gate for test generation output. Independently enumerates conditional branches from the stored procedure (without trusting the generator's branch manifest), maps test scenarios against the reviewer's own branch list, scores coverage, reviews fixture quality, and issues a verdict. Can kick back to Skill Generating Tests with specific feedback or approve the test spec.

/reviewing-tests <schema.table> [--iteration <N>]

Argument is the fully-qualified table name (the item_id). The optional --iteration flag (1-based, default 1) is passed by the /generate-tests command to track the review loop.

This skill is typically invoked by the /generate-tests command after the generator produces output, not directly by the user.

• manifest.json must exist in the project root.
• catalog/tables/<item_id>.json must exist.
• test-specs/<item_id>.json must exist (produced by Skill Generating Tests).

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

Also reads the generator's output from test-specs/<item_id>.json.

The reviewer enumerates all conditional branches from proc_body and statements independently. The generator's branch_manifest is not read or trusted -- the reviewer builds its own from scratch.

Uses the same coverage model:

Each branch gets a stable id (snake_case, descriptive) and human-readable description.

For each scenario in unit_tests[], the reviewer determines which branches (from its own enumeration) the scenario exercises by analyzing the given fixture rows against the proc logic -- not by trusting scenario names or descriptions.

Rules:

• A scenario may cover multiple branches
• A branch may require multiple scenarios
• Mapping is based on fixture analysis, not naming conventions

A branch is untestable when it depends on runtime state: GETDATE()/SYSDATETIME() comparisons, dynamic SQL with variable targets, external service calls, or non-deterministic functions. Each untestable classification requires a rationale.

Each scenario is assessed on four dimensions:

Issues are recorded with scenario name, description, and severity (warning or error).

Maximum review iterations: 2. If --iteration 2 and issues remain, the reviewer approves with warnings rather than looping further, flagging the item for human review.

None. The reviewer does not modify test-specs/ or any catalog files. It emits a TestReviewResult JSON structure as output.

{
  "item_id": "silver.dimproduct",
  "status": "revision_requested",
  "reviewer_branch_manifest": [
    {
      "id": "merge_matched_update",
      "description": "MERGE WHEN MATCHED -> UPDATE existing product",
      "covered": true,
      "covering_scenarios": ["test_merge_matched_existing_product_updated"]
    },
    {
      "id": "merge_not_matched_insert",
      "description": "MERGE WHEN NOT MATCHED -> INSERT new product",
      "covered": true,
      "covering_scenarios": ["test_merge_not_matched_new_product_inserted"]
    },
    {
      "id": "left_join_null_category",
      "description": "LEFT JOIN to category table -- no matching category (NULL right side)",
      "covered": false,
      "covering_scenarios": []
    },
    {
      "id": "getdate_expiry_check",
      "description": "WHERE ExpiryDate < GETDATE() -- runtime date comparison",
      "covered": false,
      "covering_scenarios": []
    }
  ],
  "coverage": {
    "total_branches": 8,
    "covered_branches": 6,
    "untestable_branches": 1,
    "score": "partial",
    "uncovered": [
      {
        "id": "left_join_null_category",
        "description": "LEFT JOIN to category table -- no matching category (NULL right side)"
      }
    ],
    "untestable": [
      {
        "id": "getdate_expiry_check",
        "description": "WHERE ExpiryDate < GETDATE() -- runtime date comparison",
        "rationale": "Branch depends on current system time; static fixtures cannot control GETDATE() output"
      }
    ]
  },
  "quality_issues": [
    {
      "scenario": "test_merge_matched_existing_product_updated",
      "issue": "Fixture uses negative list_price (-10.00) which is unrealistic for this domain",
      "severity": "warning"
    }
  ],
  "feedback_for_generator": {
    "uncovered_branches": ["left_join_null_category"],
    "quality_fixes": ["Use realistic positive prices in test_merge_matched_existing_product_updated"]
  },
  "warnings": [],
  "errors": []
}

warnings[] and errors[] use the shared diagnostics schema:

The test reviewer must not:

• Generate or modify fixture data
• Execute stored procedures
• Write to test-specs/ -- only the test generator writes there
• Make migration or profiling decisions
• Override the test generator's ground truth output (captured proc results are facts)