agentleFS
kensauruskensaurus/cursor-kenji/skills/audit-infra-cost/SKILL.md

audit-infra-cost

Skill9 starsChanged 43 days agoMITView on GitHub

Read-only audit of hosting, database, storage, egress, and serverless spend (Supabase, Vercel, S3/R2, edge). Use when "hosting bill is high", "cut infra costs", or a bill jumps. CI minutes → audit-cicd. LLM tokens → plan-llm-cost-guardrails.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read-only. Find where money leaks in the infra bill and plan cuts that do not trade away reliability.

    line 17

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

audit-infra-cost — Hosting spend without hurting reliability

Degree of freedom: HIGH — quantify and plan. Phase 2 stays plan-only until approved. Never propose a cut that weakens backups (plan-backup-dr).

Read-only. Find where money leaks in the infra bill and plan cuts that do not trade away reliability.

For a solo operator, infra cost is runway. A silent egress or storage leak can double a bill nobody is watching.

Quantify and plan. Apply only on approval. Never propose a cut that weakens backups (plan-backup-dr) or user experience.

This skill vs neighbors

SkillOwns
audit-infra-cost (this)Compute, storage, bandwidth, platform fees
audit-cicdGitHub Actions minutes / artifacts
plan-llm-cost-guardrailsModel tokens / quota abuse
test-loadMeasured peak — right-size to this, not a guess
audit-bundle-size / audit-performanceClient payload (feeds egress)
backend-db-performanceThe index that stops compute burn

How to reason

  1. Observe — billed resource, pricing model, and (if exposed) the breakdown line
  2. Interpret — is this utilization, a leak (egress/storage/zombies), or a tier mismatch?
  3. Classify — safe quick win / medium / structural / do-not-cut (backup/UX)
  4. Severity — by $ magnitude × reliability risk, not by how easy the cut looks

Worked example

Observe: object-storage bill is 40% of spend; logs prefix has no lifecycle; backups retained 90 days (DR requirement). Interpret: unbounded logs are the leak; backup retention is not a cut. Classify: safe quick win (expire temp logs) + do-not-cut (backups). Severity: major $; reliability risk low if only temp logs expire. Finding: logs | ~X% | lifecycle 7d | do not touch backup prefix


Phase 0 — Map the spend surface [HIGH freedom]

Enumerate billed resources and, if the provider exposes it, the breakdown:

  • Compute (functions / servers / containers)
  • Database (compute + storage + connections)
  • Object storage (GB + operations)
  • Egress (usually the sneaky line)
  • CDN, per-seat / per-project fees

Note each pricing model (per-request, per-GB, per-hour, tiered) — that is where the leak hides. Pricing tiers change: fetch the provider's current pricing page rather than quoting tiers from memory; a remembered price is not evidence for a saving estimate.


Phase 1 — Waste [HIGH freedom]

Egress — Large assets from origin every request? Unoptimized images? Hotlinking / unthrottled public endpoints? Cross-check audit-bundle-size.

Storage growth — Unbounded uploads, logs, backups that never expire, orphans after DB deletes. Lifecycle to cheaper tiers?

Over-provisioning — Sized for a rare peak, 24/7 low utilization. Pair with test-load. Under-provision that forces expensive workarounds is also a finding.

Serverless — Keep-warm waste, chatty N+1 invocations, long functions that belong on a queue, cron too frequent.

Database — Full scans, missing indexes (backend-db-performance), pool misconfig forcing a bigger instance, unbounded rows with no archive.

Zombies — Duplicate staging, unused region, leftover add-ons.

Tier fit — Next tier cheaper than overages? Paid add-on cheaper than the current pattern?


Phase 2 — Plan (approve before executing) [HIGH freedom — plan only]

Estimate saving magnitude ("egress is ~X% of the bill; CDN cuts most of it") and reliability risk.

  • Safe quick wins — CDN/cache, image optimize, expire temp logs, delete zombies, add the missing index
  • Medium — right-size to measured load, lifecycle-tier cold data, batch chatty calls, queue long work
  • Structural — plan/tier change, architecture shift

Protect plan-backup-dr items. Do not expire backups to save cents.


Definition of Done

  • Billed resources + pricing model enumerated
  • Egress / storage / compute / serverless / zombies / tier-fit scored
  • Right-size vs real utilization or test-load
  • Each finding has saving magnitude + reliability risk
  • Nothing proposed that weakens backups or UX
  • Plan approved before change

Self-critique before reporting [LOW freedom — do not skip]

  1. Quantified — each finding has a saving magnitude, even if rough
  2. Backups protected — no expire-backups-to-save-cents item
  3. Right-sized to evidence — test-load or utilization, not a guess
  4. Right owner — CI minutes → audit-cicd; tokens → plan-llm-cost-guardrails
  5. Nothing applied until approved

Output format

  1. Spend surface — resource | model | rough share
  2. Findings — leak | est. saving | fix | risk
  3. Fix plan — safe-quick-win → structural
  4. Read-only until approved

Related

  • audit-cicd — pipeline cost
  • plan-llm-cost-guardrails — token spend
  • test-load — capacity numbers
  • plan-backup-dr — do not cut restore
  • audit-bundle-size / backend-db-performance — technical levers

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.