Terrashark: Failure-Mode Workflow for Terraform/OpenTofu
Run this workflow top to bottom.
1) Capture execution context
Record before writing code:
- runtime (
terraform or tofu) and exact version
- provider(s), target platform, and state backend
- execution path (local CLI, CI, HCP Terraform/TFE, Atlantis)
- environment criticality (dev/shared/prod)
If unknown, state assumptions explicitly.
2) Diagnose likely failure mode(s)
Select one or more based on user intent and risk:
- identity churn: resource addressing instability, refactor breakage
- secret exposure: secrets in state, logs, defaults, artifacts
- blast radius: oversized stacks, weak boundaries, unsafe applies
- CI drift: version mismatch, unreviewed applies, missing artifacts
- compliance gate gaps: missing policies/approvals/audit controls
3) Load only the relevant reference file(s)
Primary references:
references/identity-churn.md
references/secret-exposure.md
references/blast-radius.md
references/ci-drift.md
references/compliance-gates.md
Supplemental references (only when needed):
references/testing-matrix.md
references/quick-ops.md
references/examples-good.md
references/examples-bad.md
references/examples-neutral.md
references/coding-standards.md
references/module-architecture.md
references/ci-delivery-patterns.md
references/security-and-governance.md
references/do-dont-patterns.md
references/mcp-integration.md
Conditional references (CRR; load only on detected signals):
references/conditional/backend-state-safety.md (backend is s3, azurerm, gcs, remote, cloud, pg, consul, or local, or task mentions backend migration, locking, state backup, or restore)
references/conditional/trusted-modules.md (provider is aws, azurerm, google, oci, or ibm)
Do not load multiple conditional references unless the task spans multiple detected backends, providers, or tools.
4) Propose fix path with explicit risk controls
For each fix, include:
- why this addresses the failure mode
- what could still go wrong
- guardrails (tests, approvals, rollback)
5) Generate implementation artifacts
When applicable, output:
- HCL changes (typed vars, stable keys, bounded versions)
- migration blocks (
moved, import strategy)
- CI pipeline updates (plan/apply separation, artifacts, policy checks)
- compliance controls (approvals, policy rules, evidence paths)
When a trusted registry module covers the requested resource and the user has not asked for raw HCL, default to that module with an exact version pin (see references/conditional/trusted-modules.md).
6) Validate before finalize
Always provide command sequence tailored to runtime and risk tier.
Never recommend direct production apply without reviewed plan and approval.
7) Output contract
Return:
- assumptions and version floor
- selected failure mode(s)
- chosen remediation and tradeoffs
- validation/test plan
- rollback/recovery notes for destructive-impact changes
1---2name: terrashark3description: Prevent Terraform/OpenTofu hallucinations by diagnosing and fixing failure modes: identity churn, secret exposure, blast-radius mistakes, CI drift, and compliance gate gaps. Use when generating, reviewing, refactoring, or migrating IaC and when building delivery/testing pipelines.4---5
6# Terrashark: Failure-Mode Workflow for Terraform/OpenTofu
7
8Run this workflow top to bottom.
9
10## 1) Capture execution context
11
12Record before writing code:
13- runtime (`terraform` or `tofu`) and exact version
14- provider(s), target platform, and state backend
15- execution path (local CLI, CI, HCP Terraform/TFE, Atlantis)
16- environment criticality (dev/shared/prod)
17
18If unknown, state assumptions explicitly.
19
20## 2) Diagnose likely failure mode(s)
21
22Select one or more based on user intent and risk:
23- identity churn: resource addressing instability, refactor breakage
24- secret exposure: secrets in state, logs, defaults, artifacts
25- blast radius: oversized stacks, weak boundaries, unsafe applies
26- CI drift: version mismatch, unreviewed applies, missing artifacts
27- compliance gate gaps: missing policies/approvals/audit controls
28
29## 3) Load only the relevant reference file(s)
30
31Primary references:
32- `references/identity-churn.md`
33- `references/secret-exposure.md`
34- `references/blast-radius.md`
35- `references/ci-drift.md`
36- `references/compliance-gates.md`
37
38Supplemental references (only when needed):
39- `references/testing-matrix.md`
40- `references/quick-ops.md`
41- `references/examples-good.md`
42- `references/examples-bad.md`
43- `references/examples-neutral.md`
44- `references/coding-standards.md`
45- `references/module-architecture.md`
46- `references/ci-delivery-patterns.md`
47- `references/security-and-governance.md`
48- `references/do-dont-patterns.md`
49- `references/mcp-integration.md`
50
51Conditional references (CRR; load only on detected signals):
52- `references/conditional/backend-state-safety.md` (backend is `s3`, `azurerm`, `gcs`, `remote`, `cloud`, `pg`, `consul`, or `local`, or task mentions backend migration, locking, state backup, or restore)
53- `references/conditional/trusted-modules.md` (provider is `aws`, `azurerm`, `google`, `oci`, or `ibm`)
54
55Do not load multiple conditional references unless the task spans multiple detected backends, providers, or tools.
56
57## 4) Propose fix path with explicit risk controls
58
59For each fix, include:
60- why this addresses the failure mode
61- what could still go wrong
62- guardrails (tests, approvals, rollback)
63
64## 5) Generate implementation artifacts
65
66When applicable, output:
67- HCL changes (typed vars, stable keys, bounded versions)
68- migration blocks (`moved`, import strategy)
69- CI pipeline updates (plan/apply separation, artifacts, policy checks)
70- compliance controls (approvals, policy rules, evidence paths)
71
72When a trusted registry module covers the requested resource and the user has not asked for raw HCL, default to that module with an exact `version` pin (see `references/conditional/trusted-modules.md`).
73
74## 6) Validate before finalize
75
76Always provide command sequence tailored to runtime and risk tier.
77Never recommend direct production apply without reviewed plan and approval.
78
79## 7) Output contract
80
81Return:
82- assumptions and version floor
83- selected failure mode(s)
84- chosen remediation and tradeoffs
85- validation/test plan
86- rollback/recovery notes for destructive-impact changes