agentleFS
vindreshsinghvindreshsingh/engineering-skills/skills/finops-budget/SKILL.md

finops-budget

Skill0 starsChanged 5 months agoMITView on GitHub

Controls cloud and SaaS spend — cost visibility, budgets, alerts, and right-sizing. Use when bills spike, planning infra for a feature, or setting cost guardrails before scale.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    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:

    actionable: before a surprise invoice — not after.

    line 9
  2. Distinctive:

    No baseline = no improvement.

    line 33
  3. Distinctive:

    Document who gets paged at 100%.

    line 51
  4. Distinctive:

    No billing alerts configured

    line 89

≈ “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

FinOps Budget

Performance without cost awareness burns runway. This skill makes spend visible, budgeted, and actionable before a surprise invoice — not after.

Pairs with [[observability]] for metrics, [[perf-budget]] for efficiency, [[launch-readiness]] before scale events, and [[data-modeling]] when storage drives cost.

When to Use

  • Monthly cloud bill review or spike investigation
  • New feature with infra impact (compute, storage, egress, LLM tokens)
  • Setting budgets/alerts for prod
  • Right-sizing over-provisioned resources
  • Choosing between managed services by cost

Skip for local-only development with no cloud spend.

Process

1. Baseline — know current spend

  • Top 5 cost drivers (service/SKU)
  • Cost per environment (prod vs staging)
  • Trend: last 3 months MoM
  • Untagged or "unknown" spend percentage

No baseline = no improvement.

2. Attribute cost to product

Tag / dimensionUse
service / teamOwnership
environmentprod vs non-prod
featureNew launch tracking

Target: >90% tagged spend.

3. Set budgets and alerts

  • Monthly budget per env with 50/80/100% alert thresholds
  • Anomaly detection on daily spend
  • LLM/API: cost per 1k requests if applicable

Document who gets paged at 100%.

4. Optimize — measure before cutting

Priority order:

  1. Waste — idle resources, orphaned disks, oversized dev clusters
  2. Right-size — CPU/memory after 2 weeks of metrics
  3. Storage — lifecycle policies, compression, archive cold data
  4. Egress — CDN, regional placement, cache ([[caching-strategy]])
  5. Commitments — reserved/savings plans only after stable baseline

5. Feature cost estimate (before build)

For new features document:

  • Compute delta (requests × duration × price)
  • Storage delta (GB × retention)
  • Egress delta
  • Third-party API (LLM tokens, maps, etc.)
  • Monthly estimate at 1x, 10x, 100x users

Hand to product-manager if estimate breaks business model.

6. Review cadence

  • Weekly: anomaly check
  • Monthly: budget vs actual, top deltas
  • Quarterly: architecture cost review

Common Rationalizations

  • "We're too small for FinOps" — Small teams feel bill spikes hardest.
  • "Staging can mirror prod size" — Staging at 25% spec saves 75% there.
  • "Reserved instances now" — Wait for 30-day stable usage pattern.

Red Flags

  • No billing alerts configured
  • Prod and staging indistinguishable in cost reports
  • LLM features without token/cost logging
  • 20% untagged spend

  • Cost discussed only at fundraise time

Verification

  • Top cost drivers documented
  • Budgets and alerts configured
  • Tagging coverage >90% or gap plan owned
  • Feature cost template used for significant infra changes
  • Monthly review cadence scheduled

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.