Pro Preview: The Terraform Instruction File

The file

This is the complete file. Bracketed values are the ones you replace; every other line is a rule the file expects you to delete if it is not true of your repository.

# Instructions for AI assistants

Terraform for [environment] on [provider]. Applied by CI from `main`. Nobody
runs `apply` locally against a real backend, and state is remote and locked.

## Rules that are not obvious from the code

- Versions are pinned in `versions.tf`. Do not relax a constraint to make
  something work; if a resource needs a newer provider, say so.
- Every variable has a `type`, a `description`, and a `validation` block where
  the value is bounded. An unvalidated variable is a typo that reaches apply.
- No hardcoded region, account id, subscription id or ARN. Those come from
  variables or data sources.
- Resource names use `local.name_prefix` from `locals.tf`.
- Secrets come from [secret manager] data sources. Never a variable with a
  default. Never a committed `.tfvars`. A secret in state is a secret in the
  state file.
- `count` for conditional creation, `for_each` for collections. `count` over a
  list means removing the first element re-creates every resource after it.

## Security defaults this repository holds to

- Storage is encrypted at rest and blocks public access explicitly, not by
  relying on a provider default. Those defaults have changed before.
- Every ingress rule names a source. `0.0.0.0/0` requires a comment justifying
  it and gets read in review.
- IAM policies name actions and resources. No `Action: "*"`, no
  `Resource: "*"` — including in an example or a comment, because examples get
  copied.
- Logging and versioning on for anything holding data.
- `prevent_destroy` on stateful resources stays on.

## Testing

- `terraform fmt -check`, `terraform validate` and `tflint` gate CI.
- A module change updates its example in `examples/` in the same commit.
- Plan output is reviewed by a human. An approved plan is not an applied plan.

## Do not

- Do not suggest `terraform import` in a comment; imports are recorded in
  `docs/imports.md` with a reason.
- Do not introduce `null_resource`, `local-exec` or `remote-exec` without
  explaining why in your response.
- Do not use `depends_on` to paper over a missing reference.
- Do not write to `terraform.tfstate` or suggest local state, even in an
  example.

Why these rules

How you would use it

1. Copy the file to .github/copilot-instructions.md.
2. Delete every rule that is not true of your codebase. A nearly-true rule is worse than none — it gets followed.
3. Replace every bracketed value.
4. Confirm your client discovered it — the references list on a Chat response, or /instructions in the CLI.
5. Ask for something a rule forbids and check the answer. That is the test that matters.

What the rest of the library is

Ready-to-commit .github/copilot-instructions.md files for six stacks — Python services, TypeScript/Node, Go, React frontends, Terraform and Kubernetes. Each states the non-obvious rules that actually change what a suggestion looks like, with the reasoning kept as comments so you can tell which lines to keep. The other five follow the same shape as this one: Python service, TypeScript/Node, React frontend, Go service, Kubernetes. Beyond the instruction files, the archive packages the companion project repositories with their READMEs, and the in-progress benefits on the Pro page are added as they land.

The reason to stay subscribed is the revision, not the first download: when GitHub changes what a client reads or how instructions combine — which it did for the CLI this month — the files are revised and the changelog says what moved. The site's changes log is where that work starts; Pro is where it turns into an updated file.