sensitivity-comparison-review

Verifies sensitivity-analysis and comparison result JSONs retain all fields required by downstream comparison tables.

1|Updated Dec 13, 2025
One-click install
npx skills add https://github.com/ZK-Theory/TDL --skill sensitivity-comparison-review-zk-theory
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sensitivity-comparison-review
Source: https://github.com/ZK-Theory/TDL/tree/main/.agents/skills/sensitivity-comparison-review
Command: npx skills add https://github.com/ZK-Theory/TDL --skill sensitivity-comparison-review-zk-theory

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Sensitivity-analysis and comparison result JSONs can validate as well-formed while silently dropping fields that downstream comparison tables and figures need, forcing costly re-runs of the analysis to recover missing data. ## Core Features & Use Cases - Downstream-field inventory: Lists every field the comparison tables and figures consume, such as test statistic T, dimension d, mean, p-value, and per-cell identifiers. - Field presence and comparability checks: Confirms each required field is present for every arm, cell, or probe, on the same scale and computed the same way across arms. - Silent narrowing detection: Catches schema changes that drop fields, preferring a schema contract with explicit required_keys over informal review. - Use Case: When reviewing LM-sensitivity result JSONs before building a comparison table, run this review to get a field-by-field PRESENT / MISSING report across all arms and confirm the table can be built from the JSON as-is. ## Quick Start Review my sensitivity-analysis result JSONs and confirm every field needed for the comparison table is present across all arms.

Frequently Asked Questions about sensitivity-comparison-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify comparison result JSONs have all required fields?

Inventory every field the downstream comparison tables and figures consume, then confirm each is present in the result JSON for every arm, cell, or probe. Report field-by-field PRESENT or MISSING status across arms.

How to prevent schema changes from silently dropping result fields?

Define a schema contract with explicit required_keys for the result JSON instead of relying on informal review. This catches field drops at validation time rather than when the comparison table fails to build.

Why does a well-formed JSON still break my comparison table?

A JSON can be syntactically valid while missing fields the table consumes, such as test statistic T, dimension d, or mean. Structural validity does not guarantee the presence of downstream-required content.

What makes fields comparable across analysis arms?

Fields must be on the same scale and computed the same way across arms, with per-arm identifiers that let rows be matched. Without this, present fields still cannot be assembled into a valid comparison table.

When should I use a schema contract instead of manual review?

Use a schema contract whenever result JSONs feed automated downstream consumers like comparison tables. Manual review catches issues once; a contract with required_keys mechanizes the requirement and catches regressions on every run.