What problem does it solve? Changing the Terraform module or E2E tests for the Materialize monitoring stack without understanding how the module couples to the Helm chart produces silently-wrong-but-valid configuration that passes terraform validate yet is ignored by the chart. ## Core Features & Use Cases - Module-chart coupling rules: Explains why consumer-side fan-outs (scheduling, storage class, Azure identity labels, Alloy config hash) exist because Helm cannot template subchart values from the parent chart. - Test tier guidance: Details what each tier proves — make terraform-check (no cluster), tier 1 (kind logging round trip), tier 2 (real object storage, Postgres, Thanos) — and how the tiers collide on shared CRD release names. - Gotcha catalog: Documents HCL pitfalls like yamlencode quoting keys, yamldecode promoting dates, count requiring plan-time-known values, and stale pinned refs masking variable validation. - Use Case: When adding a new module variable, use this Skill to add a render assertion in bin/terraform-render-check.sh proving the value lands in a path the chart actually reads. ## Quick Start Use the platform-development skill to add a new input variable to the Terraform module and verify it renders into the chart values.
