| name | prompt-carbon-optimizer |
| description | Treat prompt engineering as an efficiency discipline — trim few-shot bloat, cap output length, deduplicate system-prompt repetition, structure prompts for prefix caching, and cut token waste per call. Use this skill whenever the user shares prompts or system prompts for review, asks to reduce token usage, cost, or the per-call footprint of a production prompt, mentions prompts feeling bloated, or is writing a prompt for a high-volume production call site. Part of Lean Agentic AI Skills; emits lean-findings.json. |
Prompt Carbon Optimizer
Producer skill. Input: the actual prompts (system + user templates), call volumes if known. Output: lean-findings.json plus, when asked, the rewritten prompt.
Tokens are the unit of inference energy. A prompt trimmed by a third, at production volume, is a permanent E-reduction applied millions of times. Prompt engineering IS green engineering.
Subject type: emit subject.type: "ai-inference" in findings.
Signatures
- Few-shot bloat — more examples than the task needs; examples longer than necessary; examples the model already handles zero-shot. High at volume. Fix: ablate examples one at a time on an eval sample; keep the minimum that holds quality.
- Unbounded output — no max_tokens / length instruction on tasks with natural short answers; model rambles, every extra token is energy. High. Fix: explicit length caps + "respond with only X" phrasing + stop sequences.
- System-prompt repetition — the same instruction stated 3 ways; boilerplate courtesy; capability descriptions the call never uses. Medium.
- Cache-hostile structure — dynamic content (timestamps, user data) interleaved early in the prompt, breaking prefix caching. Medium-high where provider prefix caching exists. Fix: static-first ordering — stable system prompt and examples up top, volatile content last.
- Redundant context — retrieved documents pasted whole when sections suffice; full conversation history where a summary serves. High in RAG/agent settings.
- Verbose formats — asking for JSON with long keys, XML wrappers, or markdown decoration that downstream code strips anyway. Low-medium.
- Chain-of-thought where unneeded — reasoning tokens requested for tasks that don't benefit. Medium; keep CoT where it measurably lifts quality.
Procedure
Read the prompt fully; measure baseline token count (report actual counts — countable, so count). For each signature hit, show the trimmed alternative. Deliver a before/after token count — this is one of the few places real numbers are legitimately available, use them. Always end with: "validate on an eval sample before shipping the trim".
Honesty rules
Token counts: real. Energy/carbon per token: never (not publishable data) — directional only. Quality regressions from over-trimming are the named trade-off; the eval-before-ship step is non-negotiable.
Cost signal (countable)
Cost driver: prompt tokens per call × call volume. This is the cleanest driver in the whole catalog — tokens are exactly countable. Every trim finding SHOULD carry a cost_signal with observed = baseline token count and direction = the counted delta ("reduces the counted driver by ~160 tokens per call"). No currency figure without the user's per-token rate.
Not this skill's job
Choosing the model (model-right-sizer), response caching (llm-cache-designer).
