Arness Infra Cleanup

Check for expired ephemeral infrastructure resources across three TTL sources (issue tracker, TTL registry, resource manifest) and destroy them with user confirmation. Supports periodic monitoring via /loop for session-duration TTL enforcement.

This skill never auto-destroys resources. Every destruction requires explicit user confirmation with a summary of what will be destroyed and its associated cost.

Prerequisites

Read ## Arness from the project's CLAUDE.md. If no ## Arness section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run /arn-infra-wizard to get started — it will set everything up automatically." Do not proceed without it.

Check the Deferred field. If Deferred: yes, inform the user: "Infrastructure is in deferred mode. Cleanup is not available until infrastructure is fully configured. Run /arn-infra-assess to un-defer." Stop.

Extract:

• Experience level -- derived from user profile. Read ~/.arness/user-profile.yaml (or .claude/arness-profile.local.md if it exists — project override takes precedence). Apply the experience derivation mapping from ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md. If no profile exists, check for legacy Experience level in ## Arness as fallback.
• Providers -- which cloud providers are configured
• Providers config -- path to providers.md
• Default IaC tool -- for determining destroy commands
• Environments -- environment names in promotion order
• Environments config -- path to environments.md for per-environment deployment state
• Resource manifest -- path to active-resources.json for resource inventory
• Reference overrides -- path to local reference override directory (for evolving reference reads)
• Platform -- for issue tracker access
• Issue tracker -- for reading cleanup issues and updating labels
• Tooling manifest -- path to tooling-manifest.json for available CLIs

Workflow

Step 1: Scan TTL Sources

Check all three TTL sources in priority order. Collect a unified list of resources with expired or near-expiry TTLs.

Source 1: Issue Tracker (highest priority)

If issue tracking is configured (Platform is github or Issue tracker is jira):

For GitHub:

gh issue list --label "arn-infra-cleanup" --state open --json number,title,body,createdAt

For Jira: Query issues with label arn-infra-cleanup in the configured Jira project.

Parse each cleanup issue:

• Extract TTL expiry timestamp from the issue body (set by arn-infra-deploy during ephemeral deployments)
• Extract resource identifiers and destroy commands from the issue body
• Determine if the TTL has expired (expiry timestamp < current time)
• Determine if the TTL is approaching (within 1 hour of expiry) for early warning

Source 2: TTL Registry (secondary)

Check for the TTL registry file:

Read .arness/infra/ttl-registry.md

If the file exists, parse resource entries with their TTL timestamps. The TTL registry is a fallback for environments without issue tracking or for resources created outside the normal deployment flow.

Expected format:

# TTL Registry

| Resource | Environment | Provider | Created | TTL Expiry | Destroy Command |
|----------|-------------|----------|---------|------------|-----------------|
| [name] | [env] | [provider] | [timestamp] | [expiry] | [command] |

Source 3: Resource Manifest (tertiary)

Read the resource manifest:

Read <resource-manifest-path>

Filter resources where:

• ttl is not null
• ttl timestamp is in the past (expired)
• status is active (not already destroyed)

Step 2: Compile Expired Resource List

Merge results from all three sources, deduplicating by resource ID. For each expired resource, compile:

• Resource name and type
• Provider and region
• Environment
• Created timestamp
• TTL expiry timestamp (how long ago it expired)
• Estimated cost since creation (calculate: monthly_cost × (hours_since_creation / 730))
• Destroy command (IaC-tool-appropriate)
• Source (which TTL source identified this resource)

If no expired resources are found:

Present: "No expired resources found. All TTLs are current."

If there are resources with TTLs approaching expiry (within 1 hour), list them as early warnings: "The following resources will expire soon:

• [resource]: expires in [time remaining]"

Stop here (or if running via /loop, wait for the next interval).

If expired resources are found:

Continue to Step 3.

Step 3: Present Expired Resources for Confirmation

Present each expired resource group (grouped by environment):

"The following resources have expired TTLs and are candidates for cleanup:

Environment: [env]

Total cost of expired resources: $[total] (estimated charges since TTL expired)

Ask (using AskUserQuestion):

"How would you like to handle the expired resources?"

Options:

1. Destroy all -- Destroy all expired resources listed above
2. Select -- Choose which resources to destroy
3. Extend TTL -- Extend the TTL for some or all resources
4. Skip -- Do not destroy anything right now

NEVER auto-destroy without confirmation. Even when running via /loop, each cleanup cycle must ask for confirmation before destroying anything.

Step 4: Execute Destruction

For each confirmed resource, execute the appropriate destroy command.

Read the local override or plugin default for rollback-patterns.md.

Destroy commands by IaC tool:

For targeted IaC destruction (OpenTofu/Terraform):

When destroying specific resources from a larger state file, use -target to avoid destroying the entire environment:

tofu destroy -target=module.<module>.<resource_type>.<name> -var-file=environments/<env>.tfvars

For full environment teardown: If all resources in an environment are expired, offer full environment destruction:

tofu destroy -var-file=environments/<env>.tfvars

Important: Always ask for confirmation before executing destroy commands. Show the exact command that will be run.

Step 5: Update Tracking

After successful destruction:

5a. Update resource manifest:

• Set status to destroyed for each destroyed resource
• Update lastUpdated timestamp
• Recalculate the summary section

5b. Close/update cleanup issues: If the resource was tracked via an issue:

• For GitHub: close the issue with a comment "Resources destroyed by arn-infra-cleanup at [timestamp]"

  gh issue close <number> --comment "Resources destroyed by arn-infra-cleanup at [timestamp]."

• For Jira: transition the issue to Done/Closed

5c. Update TTL registry: If the resource was tracked in .arness/infra/ttl-registry.md, remove the entry or mark it as destroyed.

5d. Update Environments config: If all resources in an environment were destroyed (read from the Environments config path extracted in Prerequisites):

• Reset the environment entry: Last deployed: --, Pending changes: none

Step 6: TTL Extension (if selected in Step 3)

If the user chose to extend TTL for some resources:

Ask: "How long would you like to extend the TTL? (e.g., 2h, 24h, 7d)"

For each selected resource:

1. Calculate new expiry timestamp (current time + extension duration)
2. Update ttl field in active-resources.json
3. Update the cleanup issue body with the new expiry (if issue-tracked)
4. Update TTL registry entry (if registry-tracked)

Present: "TTL extended for [N] resources. New expiry: [timestamp]. The next cleanup check will re-evaluate these resources."

Step 7: Summarize

Present the cleanup summary:

"Cleanup Summary:

• Resources destroyed: [N]
• Resources extended: [N]
• Resources skipped: [N]
• Estimated savings: $[amount]/month (freed monthly cost)
• Issues closed: [N]

Files updated:

• [list all files modified]

Remaining TTLs:

• [resource]: expires [timestamp]
• [resource]: expires [timestamp]

Periodic monitoring: To automatically check for expired resources, use: /loop 6h /arn-infra-cleanup

This will check TTLs every 6 hours during the current session and prompt for cleanup when resources expire."

/loop Support

This skill supports periodic execution via the /loop command:

/loop 6h /arn-infra-cleanup

When running in loop mode:

1. Each iteration runs Steps 1-2 (scan and compile)
2. If no expired resources: silently continues to the next interval (no output)
3. If expired resources found: presents the list and asks for confirmation (Step 3)
4. After confirmation (destroy/extend/skip): continues to the next interval
5. NEVER auto-destroys. Even in loop mode, destruction requires explicit confirmation.

Recommended loop intervals:

• Development environments: 1-2 hours (short-lived ephemeral deployments)
• Staging environments: 6 hours (standard monitoring)
• Mixed environments: 4-6 hours (balanced check frequency)

Error Handling

• ## Arness config missing: Suggest running /arn-infra-wizard to get started. Stop.
• No TTL sources available: If there is no issue tracker, no TTL registry, and no resource manifest, inform the user: "No TTL tracking is configured. Deploy ephemeral resources with /arn-infra-deploy (which creates cleanup issues) or manually add resources to .arness/infra/ttl-registry.md." Stop.
• Resource manifest missing: Check other TTL sources (issues, registry). If found, proceed with those. If the manifest should exist, warn: "Resource manifest not found at [path]. Resource tracking may be incomplete."
• Issue tracker unavailable: Skip Source 1, proceed with Sources 2 and 3. Note: "Issue tracker was not reachable. Checking TTL registry and resource manifest only."
• Destroy command fails: Report the error with the full error output. Offer to retry or skip. Do NOT mark the resource as destroyed if the destroy command failed. Update the issue/registry with the failure.
• Destroy partially succeeds (multi-resource teardown): Report which resources were destroyed and which failed. Update tracking for successful destructions only. Present the failures for manual intervention.
• State lock prevents destruction: If the IaC state is locked, warn: "Cannot destroy resources -- state is locked by [details]. Wait for the lock to release or force-unlock." Never force-unlock without user confirmation.
• Resource already destroyed (outside of Arness): If a resource listed in the manifest no longer exists at the provider, mark it as destroyed in the manifest and close any associated cleanup issue. Inform the user: "[resource] was already destroyed (possibly manually or by another process)."
• TTL registry file does not exist: Skip Source 2 silently. The TTL registry is optional.
• Re-running is safe: Re-running scans all TTL sources again. Already-destroyed resources are skipped (status is destroyed in manifest). Closed issues are filtered out by the open-issues query.