cost-analysis — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited cost-analysis (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
instructions: | You are an autonomous infrastructure cost analyst. Do NOT ask the user questions. Read the actual codebase, auto-detect all infrastructure, model costs per user action, project at multiple user scales, and produce a comprehensive cost report.
TARGET: $ARGUMENTS
If arguments are provided, use them to focus the analysis (e.g., specific services, custom user tiers, or a particular feature's cost). If no arguments, run the full analysis.
============================================================ PHASE 1: INFRASTRUCTURE AUTO-DETECTION ============================================================
Discover every cost-generating service by reading project configuration files. Search for ALL of the following config files and parse what you find.
Step 1.1 — Detect Cloud Providers & Services
Search the project root (and common subdirectories) for these config files:
Firebase / Google Cloud:
firebase.json, .firebaserc — Firebase services (Firestore, Functions, Storage, Hosting, Auth)firestore.rules, storage.rules — database and storage configurationfunctions/ directory — Cloud Functions sourceapp.yaml, cloudbuild.yaml — Google App Engine / Cloud Build@google-cloud/* or firebase-* packages in dependency filesAWS:
serverless.yml / serverless.ts — Serverless Framework (Lambda, API Gateway, DynamoDB, S3, etc.)template.yaml / template.json — AWS SAMcdk.json, lib/*.ts with CDK imports — AWS CDK*.tf, *.tf.json — Terraform (check provider "aws" blocks)amplify.yml, amplify/ — AWS Amplifycopilot/ — AWS Copilot.elasticbeanstalk/ — Elastic Beanstalk@aws-sdk/*, aws-sdk, or boto3 in dependency filesDockerfile + ECS/ECR referencesAzure:
azure-pipelines.yml — Azure DevOpshost.json, local.settings.json — Azure Functions*.tf with provider "azurerm" — Terraform for Azure@azure/* packages in dependency filesVercel:
vercel.json — Vercel configurationnext.config.js / next.config.ts — Next.js (commonly deployed on Vercel).vercel/ directoryNetlify:
netlify.toml — Netlify configurationnetlify/functions/ — Netlify FunctionsRailway:
railway.json, railway.toml — Railway configurationProcfile (also used by Heroku)Fly.io:
fly.toml — Fly.io configurationSupabase:
supabase/config.toml, supabase/ directory — Supabase project@supabase/supabase-js in dependency filesPlanetScale:
.pscale.yml — PlanetScale configuration@planetscale/* packagesDocker / Generic VPS:
docker-compose.yml / docker-compose.yaml / compose.yml — containerized servicesDockerfile — container buildsnginx.conf, Caddyfile — reverse proxy (implies VPS)systemd/ service filesTerraform (multi-cloud):
*.tf files — parse all provider blocks to determine which clouds are usedterraform.tfvars, *.tfvars — variable values that may indicate instance sizesDependency files (for SDK detection):
package.json (Node.js)requirements.txt, pyproject.toml, Pipfile (Python)go.mod (Go)Gemfile (Ruby)pubspec.yaml (Dart/Flutter)Cargo.toml (Rust)pom.xml, build.gradle (Java/Kotlin)For each detected service, record:
Step 1.2 — Compute Services Inventory
For every serverless function, container, or compute instance found, build a table:
| Service | Provider | Type | Trigger/Schedule | Memory/Size | Min Instances | External APIs |
|---|
Types: Lambda, Cloud Function, Edge Function, Netlify Function, Container, EC2, App Engine, etc.
For scheduled functions/cron jobs, record the interval and calculate daily invocation count.
For always-on compute (EC2, VPS, Railway, Fly.io machines, containers with min instances):
Step 1.3 — Database Services Inventory
For each database service found, record:
| Database | Provider | Type | Pricing Model | Storage Est. | Growth Rate |
|---|
Types: Firestore, DynamoDB, RDS (MySQL/Postgres), PlanetScale, Supabase Postgres, MongoDB Atlas, Redis, ElastiCache, etc.
Growth rate: per-user (linear), per-action (transaction-driven), fixed (config data)
For document databases (Firestore, DynamoDB): identify collections/tables and estimate doc sizes. For relational databases (RDS, PlanetScale, Supabase): identify instance size and storage tier.
Step 1.4 — Real-Time & Streaming Costs
Search for real-time listeners, WebSocket connections, or streaming subscriptions:
onSnapshot / StreamProvidersCount active listeners per user session and estimate ongoing read/connection charges.
Step 1.5 — Storage & CDN
Identify all file storage and CDN usage:
Record: what is stored, estimated file size, upload frequency per user, CDN caching behavior.
Step 1.6 — External Paid Services
Identify all external API integrations with costs:
============================================================ PHASE 2: PER-ACTION COST MODELING ============================================================
For every significant user action, calculate the exact infrastructure cost by reading the code path end-to-end.
Step 2.1 — Define User Actions
Identify every user-facing action that generates infrastructure operations. Common actions (adjust to the app's domain):
Add any app-specific actions found in the codebase.
Step 2.2 — Trace Each Action
For each action, trace the full code path and count all billable operations:
| Action | DB Reads | DB Writes | Compute Invocations | Storage Ops | External API Calls | Bandwidth |
|---|
Rules for counting (adapt to the detected provider):
Firestore: .get() = 1 read/doc, .where().get() = N reads, .set()/.update() = 1 write, batch ops = 1 per operation, listeners = 1 read/snapshot + 1/changed doc DynamoDB: GetItem = 0.5 RRU (eventually consistent) or 1 RRU (strongly consistent), Query/Scan = RRUs based on data scanned, PutItem/UpdateItem = 1 WRU per KB SQL databases: Charged by instance time, not per-query (but query volume affects instance sizing) Lambda/Cloud Functions: 1 invocation + duration x memory cost S3/GCS: PUT = write op, GET = read op, egress = bandwidth cost Vercel: Serverless function invocations, bandwidth, edge middleware invocations Supabase: Database size, bandwidth, edge function invocations, realtime connections
Step 2.3 — Calculate Per-Action Cost
Apply the detected provider's pricing. Use current pricing for the project's region.
Common pricing references (use as defaults, verify against current rates):
AWS Lambda: $0.20/1M requests + $0.0000166667/GB-second AWS S3: $0.023/GB storage, $0.005/1K PUT, $0.0004/1K GET, $0.09/GB egress AWS RDS (db.t3.micro): ~$0.017/hour ($12.41/month) AWS CloudFront: $0.085/GB (first 10TB) AWS DynamoDB: $1.25/1M WRU, $0.25/1M RRU, $0.25/GB storage
Firebase/GCP Firestore: $0.036/100K reads, $0.108/100K writes, $0.012/100K deletes Firebase Cloud Functions: $0.40/1M invocations + compute time Firebase Storage: $0.026/GB, $0.05/10K uploads, $0.004/10K downloads Firebase Auth: Free up to 50K MAU (email/password) Firebase Hosting: 10GB storage free, 360MB/day transfer free
Vercel (Pro $20/mo): 1M serverless invocations included, 1TB bandwidth, $40/100GB overage Netlify (Pro $19/mo): 125K serverless invocations, 1TB bandwidth Railway: $5/mo + usage ($0.000463/vCPU-min, $0.000231/GB-min) Fly.io: 3 shared-cpu VMs free, $0.0000008/s per extra, $0.15/GB bandwidth Supabase (Pro $25/mo): 8GB database, 250GB bandwidth, 500K edge invocations PlanetScale (Scaler $29/mo): 10B row reads, 50M row writes, 10GB storage
External Services:
Produce a per-action cost table:
| Action | DB Cost | Compute Cost | Storage Cost | External Cost | Total Cost/Action |
|---|
Step 2.4 — Background/Fixed Costs
Calculate costs that occur regardless of user actions:
============================================================ PHASE 3: USER BEHAVIOR PROFILES ============================================================
Define realistic user behavior profiles for cost projection.
Step 3.1 — Usage Profiles
Define 3 user profiles with monthly action frequencies. Tailor the actions to what was discovered in Phase 2.
Casual User (60% of users)
Active User (30% of users)
Power User (10% of users)
Adjust these profiles based on the app's domain:
Step 3.2 — Weighted Average User
Calculate the weighted average monthly cost per user: weighted_cost = (0.60 x casual_cost) + (0.30 x active_cost) + (0.10 x power_cost)
============================================================ PHASE 4: SCALE PROJECTION ============================================================
Project total monthly costs at each user tier.
Step 4.1 — User Tiers
Calculate for these tiers (or custom tiers if specified in arguments):
Step 4.2 — Linear Costs (Scale with Users)
For each tier: per-user monthly cost x number of users.
Step 4.3 — Fixed Costs (Do Not Scale)
Costs that remain constant regardless of user count:
Step 4.4 — Sub-Linear Costs (Grow Slower Than Users)
Step 4.5 — Super-Linear Costs (Grow Faster Than Users)
Step 4.6 — Free Tier Deductions
Apply each provider's free tier allowances. Common free tiers:
Firebase: 50K reads/day, 20K writes/day, 2M function invocations/month, 5GB storage AWS: Lambda 1M requests/month, S3 5GB (12 months), DynamoDB 25 WRU/25 RRU Vercel (Hobby): 100GB bandwidth, 100K serverless invocations Netlify (Free): 125K function invocations, 100GB bandwidth Supabase (Free): 500MB database, 2GB bandwidth, 500K edge invocations Fly.io: 3 shared-cpu VMs, 160GB bandwidth Railway: $5 credit/month on trial PlanetScale: No free tier (Hobby deprecated)
Subtract free tier from total before calculating cost. Note which tiers exceed free limits.
Step 4.7 — Build the Projection Table
Build a table with rows for EACH detected service (not a generic Firebase-only template). Group by provider. Example structure:
| 1K MAU | 5K MAU | 10K MAU | 25K MAU | 50K MAU | 100K MAU | |
|---|---|---|---|---|---|---|
| [Provider 1] | ||||||
| Service A | $ | $ | $ | $ | $ | $ |
| Service B | $ | $ | $ | $ | $ | $ |
| Provider 1 Subtotal | $ | $ | $ | $ | $ | $ |
| [Provider 2] | ||||||
| Service C | $ | $ | $ | $ | $ | $ |
| Provider 2 Subtotal | $ | $ | $ | $ | $ | $ |
| External Services | ||||||
| Stripe Fees | $ | $ | $ | $ | $ | $ |
| Email/SMS | $ | $ | $ | $ | $ | $ |
| External Subtotal | $ | $ | $ | $ | $ | $ |
| Fixed Costs | $ | $ | $ | $ | $ | $ |
| TOTAL | $ | $ | $ | $ | $ | $ |
| Per User/Month | $ | $ | $ | $ | $ | $ |
============================================================ PHASE 5: COST OPTIMIZATION RECOMMENDATIONS ============================================================
Step 5.1 — Identify Cost Hotspots
From Phase 4, rank cost categories by total spend at the 100K tier. The top 3 categories are the optimization targets.
Step 5.2 — Generate Optimization Recommendations
For each hotspot, propose specific, actionable optimizations:
| # | Optimization | Service | Est. Savings/Month (100K) | Effort | Risk |
|---|---|---|---|---|---|
| 1 | [specific change] | [service] | $X | Low/Med/High | Low/Med/High |
Common optimization patterns to check for (by provider):
General:
Firebase/Firestore:
AWS:
Vercel/Netlify:
Database:
Supabase:
Step 5.3 — Prioritize by ROI
Sort recommendations by: estimated savings / effort score. Group into:
============================================================ PHASE 6: PROVIDER COMPARISON ============================================================
Based on the detected infrastructure, suggest 1-2 alternative provider configurations and estimate the cost difference.
Step 6.1 — Identify Comparable Alternatives
Map the current stack to alternatives:
| Current | Alternative 1 | Alternative 2 |
|---|---|---|
| Firebase Firestore | Supabase Postgres | AWS DynamoDB |
| Firebase Functions | AWS Lambda | Vercel Serverless |
| Firebase Hosting | Vercel | Netlify |
| Firebase Auth | Supabase Auth | Auth0 |
| AWS EC2 | Railway | Fly.io |
| AWS RDS | PlanetScale | Supabase |
| Vercel Pro | Netlify Pro | Cloudflare Pages |
| Heroku | Railway | Fly.io |
Only compare alternatives that make technical sense for the project's requirements (e.g., don't suggest DynamoDB for a heavily relational schema).
Step 6.2 — Cost Comparison Table
| Provider Setup | 1K MAU | 10K MAU | 50K MAU | 100K MAU |
|---|---|---|---|---|
| Current Stack | $X | $X | $X | $X |
| Alternative 1 | $X | $X | $X | $X |
| Alternative 2 | $X | $X | $X | $X |
Include a brief note on migration effort and trade-offs for each alternative.
============================================================ PHASE 7: WRITE REPORT ============================================================
Write the complete analysis to docs/cost-analysis.md in the project (create the docs/ directory if it doesn't exist).
Report structure:
# Infrastructure Cost Analysis
Generated: [date]
Project: [project name]
Detected Providers: [list of providers found]
Region(s): [detected regions]
## Executive Summary
| User Tier | Monthly Cost | Per User/Month | Top Cost Driver |
|-----------|-------------|----------------|-----------------|
| 1K MAU | $X | $X.XX | [service] |
| 10K MAU | $X | $X.XX | [service] |
| 50K MAU | $X | $X.XX | [service] |
| 100K MAU | $X | $X.XX | [service] |
Key findings:
- [top 3 insights]
## Detected Infrastructure
[Services inventory from Phase 1]
## Compute Services
[Table from Phase 1.2]
## Database Services
[Table from Phase 1.3]
## Per-Action Cost Breakdown
[Table from Phase 2.3]
## Background/Fixed Costs
[Table from Phase 2.4]
## User Behavior Assumptions
[Profiles from Phase 3]
## Cost Projection by Tier
[Full table from Phase 4.7]
### Cost Distribution (100K MAU)
[Rank each service by % of total cost]
## Optimization Recommendations
### Quick Wins
[Items from Phase 5.3]
### Medium-Term
[Items from Phase 5.3]
### Architectural Changes
[Items from Phase 5.3]
## Provider Comparison
[Comparison table and notes from Phase 6]
## Assumptions & Methodology
- Detected providers: [list]
- Pricing region(s): [regions]
- Pricing as of: [date]
- User behavior profiles: [methodology]
- Operations counted by code path tracing
- Free tier deductions applied to all tiers
- External service fees at standard rates
- All costs in USD============================================================ STRICT RULES ============================================================
the billable operation occurs.
============================================================ OUTPUT ============================================================
After writing the report file, print a brief summary:
docs/cost-analysis.mdMonthly cost at key tiers:
| 1K MAU | 10K MAU | 50K MAU | 100K MAU |
|---|---|---|---|
| $X | $X | $X | $X |
Top 3 cost drivers at 100K MAU:
Top 3 optimization opportunities:
Provider comparison (100K MAU):
NEXT STEPS:
/scale-audit to identify scalability bottlenecks alongside cost hotspots."/iterate to implement the Quick Win optimizations."============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================
After producing output, validate data quality and completeness:
note data gaps and attempt alternative discovery methods.
IF VALIDATION FAILS:
IF STILL INCOMPLETE after 2 iterations:
============================================================ SELF-EVOLUTION TELEMETRY ============================================================
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
~/.claude/projects/skill-telemetry.md in that memory directoryEntry format:
### /cost-analysis — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.