From devops-skills
Performs Terraform state surgery including state mv, import, and rm operations with mandatory safety measures like backups, documentation, and user approval prompts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/devops-skills:terraform-state-operationsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
State operations modify Terraform's understanding of infrastructure without changing actual resources. These are dangerous because mistakes can orphan resources or cause Terraform to recreate existing infrastructure.
State operations modify Terraform's understanding of infrastructure without changing actual resources. These are dangerous because mistakes can orphan resources or cause Terraform to recreate existing infrastructure.
Announce at start: "I'm using the terraform-state-operations skill for safe state surgery."
ALWAYS create a backup before ANY state operation:
# Create timestamped backup
BACKUP_NAME="state-backup-$(date +%Y%m%d-%H%M%S).tfstate"
# For local state
cp terraform.tfstate "$BACKUP_NAME"
# For remote state (S3 example)
terraform state pull > "$BACKUP_NAME"
echo "Backup created: $BACKUP_NAME"
Before proceeding, create a record:
## State Operation Record
**Date:** [timestamp]
**Environment:** [env name]
**Operator:** [user]
**Reason:** [why this operation is needed]
### Planned Operations
1. [operation 1]
2. [operation 2]
### Backup Location
- Local: [path]
- Remote: [if applicable]
### Rollback Plan
[How to restore if something goes wrong]
Present the plan and require explicit approval before executing.
Use case: Rename resources, reorganize modules, refactor code
# List current resources
terraform state list
# Move/rename a resource
terraform state mv aws_instance.old_name aws_instance.new_name
# Move into a module
terraform state mv aws_instance.web module.web.aws_instance.this
# Move between modules
terraform state mv module.old.aws_instance.web module.new.aws_instance.web
Verification after mv:
# Should show no changes
terraform plan
Use case: Remove from state without destroying actual resource (adopting externally-managed resources)
# Remove single resource
terraform state rm aws_instance.legacy
# Remove module
terraform state rm module.legacy
WARNING: The actual resource continues to exist but is no longer managed by Terraform.
Verification after rm:
# Resource should appear as "new" if still in code
# Remove from code if intentionally unmanaging
terraform plan
Use case: Bring existing infrastructure under Terraform management
# Import existing resource
terraform import aws_instance.web i-1234567890abcdef0
# Import with module path
terraform import module.web.aws_instance.this i-1234567890abcdef0
Before import:
Verification after import:
# Should show no changes (or only acceptable differences)
terraform plan
Use case: Backup, migrate, or restore state
# Pull current state
terraform state pull > state.json
# Push state (DANGEROUS - can overwrite!)
# terraform state push state.json # BLOCKED by hook
# Restore from backup
cp "$BACKUP_NAME" terraform.tfstate
# For remote state - may need to disable locking temporarily
# Consult your backend documentation
terraform import ...# Restore backup
cp "$BACKUP_NAME" terraform.tfstate
# Re-initialize to sync with backend
terraform init -reconfigure
Hook blocks this command. If genuinely needed:
Before any state operation:
After operation:
npx claudepluginhub joshuarweaver/cascade-code-devops-misc-1 --plugin lgbarn-devops-skillsManages Terraform state: import existing resources, move/rename addresses, remove without destroying, migrate backends. For refactoring infra, fixing corruption, or splitting/merging states.
Guides terraform state management operations including state manipulation, migration, and troubleshooting within DevOps workflows.
Manages Terraform state files: local/remote backends (S3, Terraform Cloud, Azure), locking (DynamoDB), commands (list, show, mv, rm, pull, push, import), workspaces, and best practices for infrastructure coordination.