orphaned-resource-auditor
Purpose
Audit cloud resources for stale, unowned, unused, or risky assets that should be tagged, reclaimed, or removed.
Trigger this skill when
- A cloud or platform decision needs operationally realistic review rather than generic best-practice talk.
- You need outputs that can feed architecture, operations, release, migration, or governance work.
- The team risks hand-waving ownership, drift, rollback, timing, or lifecycle constraints.
Expected inputs
- resource inventory
- ownership metadata
- usage data
- environment scope
- retention rules
Deliverables
- orphaned asset findings
- ownership gaps
- reclamation candidates
- risk summary
- cleanup actions
Operating procedure
- Clarify the actual workload, platform boundary, environment scope, and operational ownership.
- Separate what is observed, measured, or approved from what is merely assumed.
- Produce the skill-specific artifact or review output.
- Surface lifecycle risks, drift, dependency timing, rollback gaps, and hidden ops burden explicitly.
- Recommend the next best handoff instead of trying to solve the whole platform strategy at once.
Quality gates
- The result is specific to the real workload and operating context.
- Ownership, timing, and rollback assumptions are visible.
- The output is usable by engineers, platform owners, ops staff, architects, or assessors.
- The recommendation reflects operational safety and maintainability, not only implementation speed.
Handoff targets
- resource-lifecycle-planner
- acl-maintenance-reviewer
- patch-management-checker
Output style
- Be explicit about control, ownership, reversibility, and operational cost.
- Prefer concrete decision artifacts over general cloud prose.
- Surface evidence gaps instead of inventing certainty.
- Keep outputs reusable inside runbooks, ADRs, tickets, migration plans, and platform docs.
Failure modes to avoid
- Do not assume “cloud-native” means operationally simple.
- Do not ignore drift, tagging gaps, or unowned resources.
- Do not treat rollback as optional for risky updates or migrations.
- Do not bury customer impact or support timing behind architecture language.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Risks / blockers
## Open questions
## Recommended next skill
1---2name: orphaned-resource-auditor3description: orphaned-resource-auditor4---5# orphaned-resource-auditor67## Purpose8Audit cloud resources for stale, unowned, unused, or risky assets that should be tagged, reclaimed, or removed.910## Trigger this skill when11- A cloud or platform decision needs operationally realistic review rather than generic best-practice talk.12- You need outputs that can feed architecture, operations, release, migration, or governance work.13- The team risks hand-waving ownership, drift, rollback, timing, or lifecycle constraints.1415## Expected inputs16- resource inventory17- ownership metadata18- usage data19- environment scope20- retention rules2122## Deliverables23- orphaned asset findings24- ownership gaps25- reclamation candidates26- risk summary27- cleanup actions2829## Operating procedure301. Clarify the actual workload, platform boundary, environment scope, and operational ownership.312. Separate what is observed, measured, or approved from what is merely assumed.323. Produce the skill-specific artifact or review output.334. Surface lifecycle risks, drift, dependency timing, rollback gaps, and hidden ops burden explicitly.345. Recommend the next best handoff instead of trying to solve the whole platform strategy at once.3536## Quality gates37- The result is specific to the real workload and operating context.38- Ownership, timing, and rollback assumptions are visible.39- The output is usable by engineers, platform owners, ops staff, architects, or assessors.40- The recommendation reflects operational safety and maintainability, not only implementation speed.4142## Handoff targets43- resource-lifecycle-planner44- acl-maintenance-reviewer45- patch-management-checker4647## Output style48- Be explicit about control, ownership, reversibility, and operational cost.49- Prefer concrete decision artifacts over general cloud prose.50- Surface evidence gaps instead of inventing certainty.51- Keep outputs reusable inside runbooks, ADRs, tickets, migration plans, and platform docs.5253## Failure modes to avoid54- Do not assume “cloud-native” means operationally simple.55- Do not ignore drift, tagging gaps, or unowned resources.56- Do not treat rollback as optional for risky updates or migrations.57- Do not bury customer impact or support timing behind architecture language.5859## Minimum output skeleton60```md61## Summary62## Findings63## Structured outputs64## Risks / blockers65## Open questions66## Recommended next skill67```