Context Budget Skill

A context window is a budget that gets re-spent every single turn — everything sitting in it rides every call, which is how a session that "only loaded a few files" ends up paying for them forty times. This skill plans the spend before the session: what earns a permanent seat (loaded once, up front, stable), what gets linked (a map or index, with the full thing fetch-on-demand), and what never enters at all. The quiet second half is cache-awareness: providers price cached prefix tokens at a fraction of fresh ones, but only if the prefix stays byte-identical — so the layout (stable things first, volatile things last) is itself a cost decision.

What This Skill Produces

• The allocation — every candidate piece of context sorted into load / link / fetch-on-demand / exclude, with reasons
• The prefix layout — stable-first ordering that keeps provider caches hitting turn after turn
• The per-turn cost shape — what a turn costs at the start, mid-session, and near the window limit (measure with token-cost)
• The eviction rules — pre-decided: what gets summarized, crushed, or dropped when the window fills, and in what order

Required Inputs

Ask for these if not provided:

• The workflow — what the session does, how many turns it typically runs, what it touches (files, APIs, documents)
• The candidate context — everything someone wants loaded: instructions, docs, schemas, examples, history — the raw wishlist the budget disciplines
• The volatility map — which pieces change mid-session (edited files, growing history) and which never do (instructions, schemas) — the cache layout keys off this
• The window and the pricing — the model's context size, and whether the provider prices cached input differently (most majors do — verify the current terms)