vigilante-issue-implementation-on-terraform

Vigilante Terraform Issue Implementation

Focus

• Read the prompt for detected tech stacks, process hints, and Terraform security guidance before changing code.
• Follow idiomatic Terraform conventions for resource naming, file layout, and formatting.
• Keep changes scoped to the issue and do not broaden into unrelated refactoring or architecture redesign.

Terraform Tooling Workflow

• Formatting: run terraform fmt -recursive on all touched Terraform directories before committing. Do not hand-format Terraform code — let the standard formatter handle layout.
• Validation: run terraform validate in each root module directory that contains changed files. Ensure provider and backend blocks are present or that validation is run with -no-color for clean output. If validation requires initialized providers, run terraform init -backend=false first to install providers without configuring remote state.
• Planning: do not run terraform plan or terraform apply unless the repository defines a safe local workflow for it (e.g., a Makefile target, CI script, or documented local plan process). Assume cloud credentials are not available in the agent environment.
• Linting: use the repository's established lint tooling. When tflint is configured (.tflint.hcl), run tflint on touched modules. When tfsec or trivy is configured, run the appropriate scanner. Do not introduce a different linter unless the issue specifically requires it. If no project linter is configured, terraform validate is sufficient.
• Policy checks: when the repository uses policy tools such as OPA/Conftest, Sentinel, or Checkov, respect their configuration and run them if a safe local path exists. Do not skip policy checks to make changes pass.

Terraform Style

• Use snake_case for resource names, variable names, output names, and local values.
• Keep resource blocks focused — one logical resource per block.
• Group related resources in files named by purpose (e.g., main.tf, variables.tf, outputs.tf, providers.tf).
• Use variables.tf for input variable declarations and outputs.tf for output declarations.
• Pin provider versions with required_providers blocks and use pessimistic version constraints (e.g., ~> 5.0).
• Pin module versions when sourcing from a registry. Avoid ref=main for git-sourced modules in production configurations.