Lists multiple specific concrete actions: creating modules, writing tests (with named frameworks), setting up CI/CD pipelines, reviewing configurations, debugging state issues, implementing security scanning (with named tools), and making architecture decisions.

Opens with an explicit 'Use when' clause that doubles as both the 'when' trigger and the 'what' description. The what (creating modules, writing tests, CI/CD, security scanning, etc.) and when (working with Terraform/OpenTofu in these contexts) are both clearly addressed.

Excellent coverage of natural terms users would say: 'Terraform', 'OpenTofu', 'modules', 'tests', 'Terratest', 'CI/CD', 'state issues', 'trivy', 'checkov', 'infrastructure-as-code'. These are terms practitioners naturally use when seeking help.

Highly distinctive with clear niche triggers like 'Terraform', 'OpenTofu', 'Terratest', 'trivy', 'checkov', and 'infrastructure-as-code'. Unlikely to conflict with other skills unless there are multiple IaC-related skills, and even then the specific tool names provide strong differentiation.

The skill is fairly long (~400 lines) and includes some content Claude already knows (e.g., basic file naming conventions like main.tf/variables.tf/outputs.tf, general advice like 'use least-privilege security groups'). However, most content adds genuine value with specific patterns, decision matrices, and concrete examples. Could be tightened by removing obvious guidance.

The skill provides extensive executable HCL code examples, concrete bash commands (trivy, checkov, terraform init -upgrade), specific decision matrices with clear recommendations, and copy-paste ready patterns for resource ordering, variable blocks, count vs for_each, and version constraints. The guidance is highly specific and actionable throughout.

The CI/CD section lists workflow stages (Validate → Test → Plan → Apply) but lacks explicit validation checkpoints and error recovery steps. The testing section provides a decision matrix but doesn't include a clear step-by-step workflow with feedback loops for when tests fail. The module development section lists best practices but doesn't sequence them into a validated workflow. For infrastructure operations that can be destructive, the missing validation/feedback loops cap this at 2.

The skill references multiple detailed guides (testing-frameworks.md, module-patterns.md, ci-cd-workflows.md, security-compliance.md, quick-reference.md, code-patterns.md) with clear signaling and descriptions. However, no bundle files were provided, so we cannot verify these references exist. Additionally, the main file itself is quite long and includes substantial detail that could arguably be pushed to reference files, making the overview heavier than ideal.