terraform-drift-detection
Skill15 starsChanged 9 months agoMITView on GitHub
Use when detecting infrastructure drift between Terraform state and actual AWS resources. Identifies out-of-band changes.
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 93
Accept Drift: Run terraform apply -refresh-only to update state to match actual
- Very specific: line 94
Reject Drift: Run terraform apply to revert actual infrastructure to match code
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Terraform Drift Detection
Overview
Detect and categorize drift between Terraform-managed state and actual infrastructure. Drift indicates out-of-band changes that can cause problems during the next apply.
Announce at start: "I'm using the terraform-drift-detection skill to check for infrastructure drift."
The Process
Step 1: Verify Environment
# Verify AWS credentials and account
aws sts get-caller-identity
# Confirm we're in the right directory/environment
pwd
ls -la *.tf 2>/dev/null | head -5Step 2: Refresh State
# Initialize if needed
terraform init
# Refresh state to detect drift
terraform plan -refresh-only -out=drift.out
# Convert to JSON for analysis
terraform show -json drift.out > drift.jsonStep 3: Analyze Drift
Parse drift.json and categorize changes:
Drift Categories
| Category | Severity | Examples |
| Security Drift | CRITICAL | Security groups, IAM, encryption |
| Configuration Drift | HIGH | Instance settings, networking |
| Tag Drift | LOW | Tags modified outside Terraform |
| Metadata Drift | INFO | AWS-managed fields that change |
Step 4: Dispatch Analysis Agent
Task(drift-detector) → Categorize and assess drift impactAgent should:
- Categorize each drifted resource
- Assess impact of accepting vs rejecting drift
- Identify potential causes (manual changes, AWS updates, etc.)
Step 5: Present Findings
## Drift Detection Report
### Summary
- Total drifted resources: X
- Critical drift: Y
- High drift: Z
- Low/Info drift: W
### Critical Drift (Requires Immediate Attention)
| Resource | Attribute | State Value | Actual Value |
|----------|-----------|-------------|--------------|
| ... | ... | ... | ... |
### Potential Causes
- Manual console changes: [list if detected]
- AWS service updates: [list if detected]
- Unknown origin: [list if detected]
### Recommended Actions
1. [Action for each drifted resource]Step 6: Resolution Options
Present user with options:
- Accept Drift: Run
terraform apply -refresh-onlyto update state to match actual - Reject Drift: Run
terraform applyto revert actual infrastructure to match code - Investigate: Manual review needed before deciding
- Hybrid: Accept some drift, reject other drift
Never auto-resolve drift. Always get user approval.
Common Drift Sources
Intentional (Usually Accept)
- AWS auto-scaling adjustments
- Managed service updates
- Emergency manual fixes (document these!)
Unintentional (Usually Reject)
- Console click-ops mistakes
- Unapproved manual changes
- Conflicting automation
Systemic (Fix Root Cause)
- Multiple tools managing same resources
- Missing Terraform coverage
- CI/CD race conditions
Integration with Memory
Store detected drift patterns:
- Which resources commonly drift
- Common causes in this environment
- Resolution preferences
Query memory before analysis:
- Has this resource drifted before?
- What was the cause last time?
- What resolution was chosen?
Verification Checklist
Before presenting:
- Refresh completed successfully
- All drift categorized by severity
- Root causes identified where possible
- Resolution options are clear
- No sensitive values exposed in output
In this repository20 other files it gives its agents.
- auto-documentationSkill
- aws-profile-managementSkill
- brainstormingSkill
- dispatching-parallel-agentsSkill
- executing-plansSkill
- finishing-a-development-branchSkill
- historical-pattern-analysisSkill
- provider-upgrade-analysisSkill
- receiving-code-reviewSkill
- requesting-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- terraform-plan-reviewSkill
- terraform-state-operationsSkill
- test-driven-developmentSkill
- using-devops-skillsSkill
- using-git-worktreesSkill
- verification-before-completionSkill
- writing-plansSkill
- writing-skillsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

