| name | carbon-budget-designer |
| description | Design per-feature and per-service efficiency budgets — page-weight budgets, token budgets per AI feature, query budgets per endpoint, GPU-hour budgets per training project — with owners, review checkpoints, and enforcement hooks. Use this skill whenever the user wants sustainability targets for teams, asks how to keep efficiency from regressing organizationally, mentions performance-budget-style governance for carbon/energy, or is setting engineering standards. Part of Lean Agentic AI Skills; an advisor emitting budget definitions plus lean-findings.json. |
Carbon Budget Designer
Advisor skill — the organizational layer. Input: current baselines (from audit findings files where available), team/feature structure, existing review processes. Output: budget definitions + findings for anything currently unbudgeted and unowned.
Performance budgets work because they convert a value ("fast") into a number a team can defend in code review. This skill does the same for efficiency — with proxy metrics that are honestly countable, never invented carbon figures.
Subject type: emit subject.type: "organization" in findings.
Budget catalog (pick per context)
- Web: page transfer budget (KB per page class), request-count budget, image-weight budget. Baseline from web-carbon-audit evidence or a Lighthouse run.
- AI features: tokens per interaction budget (prompt + completion), model-tier policy (which tiers are allowed per task class — pairs with model-right-sizer), tool-calls-per-agent-task budget (pairs with agentic-loop-auditor).
- APIs/services: queries per request budget (N+1 ceiling), payload-size budget, cache-hit-ratio floor.
- Data: ingestion volume budget per pipeline, retention ceiling per dataset class (pairs with logging-telemetry-audit, data-minimization-designer).
- ML training: GPU-hours per experiment class, sweep-trial budgets (pairs with training-efficiency-audit).
- Infra: utilization floors (fleet p95 below X% triggers right-sizing review — pairs with right-size-compute).
Design rules
- Budgets are proxies and say so. A KB or token budget tracks E directionally; the budget doc states the proxy relationship in one line rather than claiming carbon units it can't measure.
- Baseline before target. Every budget starts from a measured current value (audit evidence, analytics, logs) — a budget with no baseline is a wish. If no baseline exists, the first "budget" is the instruction to measure for two weeks.
- Every budget has an owner and a checkpoint — a named role and where it's checked (PR gate via lean-regression-gate, sprint review, quarterly). Unowned budgets decay in a quarter.
- Headroom over heroics — budgets set at achievable-with-effort (typically current baseline minus the quick wins from findings), reviewed and tightened on a cadence, not set at aspirational floors that get ignored.
- Exceed-with-justification path — a documented process for deliberately exceeding a budget (new feature launch) with a paydown plan, so the system bends rather than gets abandoned.
Honesty rules
No budget is denominated in gCO2 unless the org has actual measurement (via impact-framework-bridge + instrumentation) — proxy units (KB, tokens, queries, GPU-hours) are the honest default and this is a feature, not a limitation: teams can count them in CI.
Not this skill's job
Detecting violations (lean-regression-gate), producing baselines (the producer audits), measurement (impact-framework-bridge).
