Cursor Rules for Terraform: Plans, State, and Reviews

Cursor rules for Terraform set the guardrails an assistant needs before touching infrastructure code: which environments exist, how state is stored, what a plan review must cover, and which changes require a person to approve before applying. Without them, the assistant may write valid HCL that violates your separation of concerns or proposes an apply before anyone has reviewed the plan.

Infrastructure changes carry real consequences. fenbs keeps the decisions behind your setup — why production state is remote, who approved the last module restructure, which networking changes are pending review — so the assistant starts from the agreed rationale, not just the current file.

What Terraform rules should cover

Terraform rules address a different risk profile from application code rules. A style mistake in a TypeScript file is annoying; a plan applied to the wrong environment can disrupt production. Rules that make environment separation explicit and require human review for certain changes reduce that risk without slowing down routine work.

• Environment directories: where each environment lives and which variables files it uses.
• State storage: remote backend location and the rule against local state in any shared environment.
• Plan discipline: what a plan review must check, and that apply always follows a reviewed plan.
• Approval boundaries: which resources or environments require human sign-off before an apply.
• Module structure: the layout of reusable modules and when to create a new one.

Environment separation

A common Terraform layout puts each environment in its own directory under environments/. An assistant that does not know this layout may add resources to the wrong folder or create a new one. A rule that names the directories and states the separation requirement removes that ambiguity.

Workspace-level dependencies between modules also need naming. When environments/prod calls a module in modules/networking, and that module pins a provider version, a change to the module affects every environment that uses it. A rule that names module dependencies and requires a review when a shared module changes prevents silent upgrades during unrelated work.

Variable files are another source of confusion. If dev.tfvars and prod.tfvars contain environment-specific values, the rule should explain that clearly. An assistant that treats them as interchangeable can write a plan that uses development values against production infrastructure.

---
description: Terraform infrastructure conventions
globs: "**/*.tf,**/*.tfvars,**/*.hcl"
alwaysApply: false
---

## Environments
- Environments are in `environments/dev`, `environments/staging`, `environments/prod`.
- Each environment has its own `.tfvars` file; do not share variable values across environments.
- Never run plan or apply in prod without an explicit task that names the change and who approved it.

## State
- Remote state is in S3 + DynamoDB (see `environments/prod/backend.tf`).
- Never use local state for dev, staging, or prod. Local state is only for scratch experiments.

## Plan and apply
- Always run `terraform plan -out=tfplan` and review the output before applying.
- Note any additions, changes, and destructions in the task before an apply.
- Flag resource destructions for human review before proceeding.

## Modules
- Reusable modules live in `modules/`. Create a new module when a pattern appears in three or more environments.
- Keep module interfaces stable; breaking changes require a Decision recorded in fenbs.

Plan review before apply

The most important practice in Terraform is reading the plan before applying it. An assistant that jumps from writing HCL to running apply skips the step that would catch a resource being destroyed or replaced unexpectedly. The rule can make this explicit: generate a plan, summarize its changes, and stop for human confirmation on destructive actions.

Resources marked with # forces replacement in the plan deserve extra attention. A replacement deletes the current resource and creates a new one, which can mean data loss for stateful resources like databases or storage buckets. The rule can require the assistant to call these out explicitly rather than burying them in a summary of the total change count.

A useful rule also names what to look for in the plan output: the count of additions, changes, and destructions. An assistant that reports those numbers before asking to apply gives the reviewer a quick summary and makes the confirmation meaningful rather than a rubber stamp.

Remote state and locking

Local state is fine for learning Terraform but has no place in a shared environment. If two people run plan simultaneously against local state, one of them overwrites the other's record. Remote state with locking prevents that. The rule should state where remote state lives and prohibit local state for any environment that more than one person touches.

State file drift is another common issue in teams where multiple people run plan and apply locally. If two engineers apply different changes from different working copies, the state diverges from what any single plan describes. Remote state with a locking backend prevents the overlapping apply; a rule that names the backend and requires remote state for all shared environments closes the door to the pattern before it starts.

State also holds sensitive output values. The rule can note what categories of outputs are sensitive and should not be logged, printed, or stored in task notes. That boundary helps the assistant handle state operations without accidentally exposing credentials.

How to set up Terraform rules with fenbs

1. Create a free account and add your infrastructure project.
2. Record the decisions already in your setup: why the backend uses a specific region, which environments are production-grade, any approved exceptions to the module layout.
3. Place the .cursor/rules/terraform.mdc file at the repository root and adjust the environment paths and backend reference to match your layout.
4. Connect Cursor via Integrations and ask it to read the project context before working on any environment-specific change.
5. Before any apply, add a task that records the specific change, the plan summary, and who reviewed it.

For applying similar conventions to application code, see cursor rules examples and cursor rules for AI projects. For organizing rule files across a complex project, see cursor rules hierarchy and cursor rules globs. fenbs does not run Terraform or access your cloud provider; it keeps the rationale behind the rules.