terraform-specialist
Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".
- License 许可
- MIT
- 最近更新
- 2026-10-26
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- id
- terraform-specialist
- name
- terraform-specialist
- task
- [ "debugging", "review" ]
- type
- skill
- model
- opus
- owner
- @kaiohenricunha
- tools
- Read, Grep, Glob, Bash
- domain
- [ "infra" ]
- effort
- max
- created
- 1735689600000
- updated
- 1776384000000
- version
- 1.0.0
- dotbabel
- { "compute": { "mode": "dynamic", "binding": "consumer", "rationale": "Evidence-based investigation or evaluation must hold several technical constraints at once.", "requirement": "deep" } }
- maturity
- validated
- platform
- [ "terraform" ]
- description
- Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".
- allowed-tools
- Read Grep Glob Bash
- argument-hint
- <module path, workspace, or problem description>
02 资源文件 6
- 参考文档references/import-patterns.md2.6 KB
- 参考文档references/modules.md2.1 KB
- 参考文档references/providers.md2.4 KB
- 参考文档references/state-management.md2.4 KB
- 参考文档references/testing.md2.3 KB
- 参考文档references/workspaces.md2.0 KB
03 SKILL.md 正文
Terraform Specialist
Structured investigation for Terraform codebases. Five phases: gather context, diagnose, design, recommend, verify.
Arguments
$0— module path, workspace context, or problem description. Required.
Phase 1: Context Gathering
- Identify the scope: module, workspace, or full repo.
- Glob for Terraform files:
find . -name "*.tf" | sort find . -name "*.tfvars" | sort find . -name ".terraform.lock.hcl" | sort - Check backend and provider configuration:
grep -r "backend" . --include="*.tf" -l grep -r "required_providers" . --include="*.tf" -l - Check for existing state:
terraform workspace list terraform state list
Phase 2: Diagnosis
Module structure:
# Check module inputs/outputs surface
grep -r "variable\|output\|locals" . --include="*.tf" -l
terraform validate
State health:
terraform state list
terraform state show <resource>
terraform plan -detailed-exitcode
Provider locks:
cat .terraform.lock.hcl
terraform providers
Test coverage:
find . -name "*_test.go" -o -name "*.tftest.hcl" | sort
Phase 3: Design / Root-Cause Analysis
Map symptoms to causes:
| Symptom | Common Causes | Check |
|---|---|---|
| Plan shows unexpected replace | ForceNew attribute changed, ID drift |
terraform state show + provider docs |
| State drift | Manual console change, import not run | terraform refresh + terraform plan |
| Module coupling | Outputs passed through too many layers | Count cross-module variable chains |
| Provider version conflict | Lock file pinned differently per module | .terraform.lock.hcl comparison |
count vs for_each bug |
Resource renamed on index change | Switch to for_each with stable keys |
Cite file:line for every finding.
Phase 4: Recommendations
Output findings in priority order:
[CRITICAL] <title>
Resource: <address or file:line>
Issue: <one sentence>
Evidence: <plan output or code snippet>
Fix: <specific change, with HCL diff if applicable>
Trade-off: <alternative and its downside, if meaningful>
Order: CRITICAL → WARNING → INFO.
Phase 5: Verification
After fixes are applied:
- Re-run
terraform validate— no errors. - Run
terraform plan— confirm zero unexpected changes. - For state moves:
terraform state listbefore and after. - For module refactors: run tests if present (
terraform testorgo test ./...). - Confirm
.terraform.lock.hclis committed and unchanged.
Reference Docs
| File | When to use |
|---|---|
modules.md |
Module design, variable/output surface, coupling |
state-management.md |
Backends, state mv, import, drift remediation |
workspaces.md |
Workspace-per-env vs stack-per-env trade-offs |
testing.md |
Unit tests, integration tests, tftest |
providers.md |
Provider config, version pinning, aliases |
import-patterns.md |
terraform import, import blocks, bulk import |
04 同仓库更多 Skills
yolo
Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.
veracity-audit
Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace <label> (single source end-to-end). Invoke when: "audit pipeline", "veracity check", "scoring math correct?", "check gates", "trace source", "verify quality gates", "formula correct?".
validate-spec
Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs/audits/. Use whenever the user asks to "validate a spec", "audit a spec", "check if spec is implemented", "verify the spec is done", "is this spec really done", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.
terragrunt-specialist
Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: "Terragrunt audit", "run-all review", "dependency block", "DRY pattern review", "env hierarchy audit", "mock_outputs", "terragrunt hooks".
spec
Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on "let's spec this out", "create a spec", "design doc", "write a technical plan", "plan the architecture". Works for greenfield and brownfield projects. Outputs to docs/specs/.
smoke-test
Run the smoke checks a repository declares for its deploy targets and report whether production actually answers after a release. Use after a deploy, during release verification, and when confirming a rollback landed. Triggers on: "smoke test", "run smoke checks", "is production healthy", "did the deploy work", "verify the release is live".