Iac Generation

Infracost IaC Generation Assistance

Assists when creating or modifying infrastructure as code (IaC) to ensure best practices are followed and costs are optimized from the start. Uses Infracost to analyze code as it's being written, providing real-time feedback on cost implications and optimization recommendations.

The output includes actionable insights: more cost-effective resource types, savings opportunities, FinOps policy violations flagged before deploy, and guidance on the user's organization's guidelines (tagging policies, required resource configurations) so problems are caught early rather than during code review.

Directly supported IaC types: Terraform, CloudFormation, Terragrunt. CDK is not yet directly supported.

Other IaC languages are also indirectly supported if you convert the resource definitions to Terraform (written to a temporary directory) and then scan that directory.

Invoking capabilities

This skill uses Infracost capabilities (list policies / guardrails / budgets, price, scan, and the inspect drill-ins). Each has two bindings — a typed MCP tool call and an infracost … CLI command — listed in BINDINGS.md.

Rule: if the Infracost MCP server is available, use its tools; otherwise run the equivalent CLI command from BINDINGS.md. The Claude Code plugin starts the MCP server automatically.

Before generating IaC, satisfy the three preflight capabilities (see BINDINGS.md): the CLI is present, the user is authenticated, and an organization is selected. With MCP these are resolved on the first tool call (failures come back as readable errors, not a dropped connection); with the CLI, check them inline. Never run infracost auth login — it is interactive. On an authentication error, have the user run infracost auth login in a separate terminal, then retry. On "no organization selected", the error lists the available org slugs; ask which one to use and have the user run infracost org switch <slug> (add --repo to pin it to this repo), then retry — the running MCP server picks up the selection on its next call. Relay these actionable messages to the user — don't retry blindly.

Capabilities you'll use

Five capabilities matter for this workflow:

1. list policies — all FinOps + tagging policies for the user's organization, so we can write compliant code from the start.
2. list guardrails — cost guardrails (spending thresholds) configured for the repository, so we can keep the generated infrastructure within budget.
3. list budgets — tag-scoped budgets for the organization, so we can see which tag groups are already near or over their actual cloud spend limits.
4. price — price a small, standalone piece of Terraform without committing it to the repo. Use for fast feedback while iterating on individual resources.
5. scan — analyze an IaC directory and return costs, diagnostics, and policy violations. Use once you have a complete set of files.

Workflow

When writing or modifying IaC, follow this order:

1. Establish org context

Before generating any code, use the three "what's the org configured?" capabilities so the generated infrastructure is compliant by construction:

• list policies — FinOps and tagging policies. For tagging policies with requirements, note any mandatory tags and the allowed_values lists. If a tagging policy allows a list of acceptable values (or no specific value) and you're not sure which to pick, ask the user. E.g., if a policy requires cost_center ∈ {engineering, marketing}, ask which one to apply.
• list guardrails for the repo path — note the thresholds (total_threshold / increase_threshold / increase_percent_threshold) and the actions (pr_comment / block_pr). A block_pr action means the threshold is a hard constraint — the generated infrastructure must stay under it. Soft constraints (alert / PR comment only) become warnings to surface.
• list budgets — every tag-scoped budget. If the resources you're about to create would match an existing budget's tag scope (env=production, team=frontend, etc.), note where that budget currently sits versus its amount. Budgets reflect actual org-wide cloud billing, not the preview — treat them as context for the user, not a hard constraint on the code.

Narrow the policies call when you know the provider (e.g. providers = aws) to skip downloading provider plugins for clouds you're not touching.

2. Iterate quickly with price

While drafting resources, use the price capability with a small Terraform snippet to get a cost on what you've written so far. This is faster than writing the whole file and scanning — useful for choosing between two configurations:

provider "aws" { region = "us-east-1" }

resource "aws_instance" "web" {
  instance_type = "m5.xlarge"
  root_block_device {
    volume_size = 100
    volume_type = "gp3"
  }
}

The result includes per-resource cost components and any applicable FinOps recommendations (e.g. "use Graviton for ~20% savings"). Use it to make informed sizing / region / type calls as you go.

For non-USD pricing pass a currency (any ISO 4217 code).

3. Scan the full result

Once the IaC files are complete, scan the directory.

Read the summary block first. Most of what you need is there:

• monthly_cost — total cost of what you generated.
• total_yearly_savings — sum of potential savings per year if every FinOps issue were fixed. Savings are always quoted per year ($X/yr); costs stay monthly.
• failing_policies, failing_tagging_policies — counts; if non-zero, drill in.
• triggered_guardrails, over_budget — counts; if any guardrail with block_pr triggered, the generated code must be changed.
• critical_diagnostics, warning_diagnostics — non-zero means the scanner couldn't fully analyze something; surface via the per-project diagnostics capability.

4. Drill in where needed

When the summary flags an issue, the inspect capabilities surface the detail. Each reads the latest cached scan automatically; target a specific previously-scanned directory by passing its path.

5. Iterate until clean

Adjust the IaC based on what the drill-ins surface. Re-scan to confirm:

• All block_pr guardrails are under threshold.
• Mandatory tags are present on every resource.
• Cost is reasonable — the user gets the value they expected for the spend.

When you make a non-obvious sizing / tagging decision based on an Infracost finding, add a brief comment to the IaC explaining the choice (e.g. "using Graviton — ~20% cheaper than equivalent x86", "team tag required by org tagging policy"). Be terse. Avoid mentioning Infracost unless absolutely necessary — comments rot less when they reference the constraint, not the tool that surfaced it.

Important Guidelines

• Do not commit the authentication token or any env var values to the repository.
• Do not write jq pipelines, python3 -c heredocs, or shell post-processing to mangle output — Infracost returns structured data already (typed JSON via MCP; --llm via the CLI). If the data you need isn't on one of the typed shapes, that's a signal we should add it; file an issue describing the gap.
• Do not stash or affect the target repository's git state — Infracost's read operations are non-destructive and read-only. If you need to compare branches, use separate worktrees away from the user's working directory.
• Pre-flight (steps 1–2 above) is non-negotiable for any code that creates cloud resources. Even when the user hasn't asked about cost, the org's policy + guardrail context shapes what "good" looks like.
• Budgets aren't hard constraints. Surface where they sit, but don't refuse to write code because a budget is full — that's the user's call to make.