/arn-infra-cleanup

name: arn-infra-cleanup
description: >-
  This skill should be used when the user says "cleanup", "infra cleanup",
  "arn infra cleanup", "clean up resources", "destroy expired resources",
  "check ttl", "check expired", "ttl cleanup", "remove old deployments",
  "destroy dev environment", "tear down", "teardown infra", "destroy resources",
  "cleanup ephemeral", "check for expired resources", "clean up infra",
  "resource cleanup", "destroy old resources", "prune resources",
  "delete expired deployments", "decommission", or wants to check for and
  destroy expired ephemeral infrastructure resources. This skill also supports periodic
  monitoring via `/loop 6h /arn-infra-cleanup` for
  session-duration TTL enforcement.
version: 1.0.0

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]**

| Resource | Type | Provider | Expired | Cost Since Creation | Destroy Command | |----------|------|----------|---------|--------------------| --------------- | | [name] | [type] | [provider] | [time since expiry] | $[amount] | [command] |

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

Ask (using `AskUserQuestion`):

**"How would you