Context Budget Manager

This skill exists because of one specific failure mode: Claude Code quality doesn't degrade smoothly as context fills — it collapses suddenly. Instructions from early in the session fall out of view. Decisions get silently re-litigated. Uncommitted work gets forgotten. A forced auto-/compact can land in the middle of a half-finished change, dropping exactly the state you needed.

The fix isn't heroics near the limit — it's budgeting. The skill operates in three zones (green/amber/red) and gives different instructions for each. Green is normal work, but you're front-loading durable state — the plan, decisions, and constraints captured in a place that survives compaction. Amber is "stop starting things you can't finish before the next clean boundary." Red is "no new multi-step work, drive to a committed boundary fast, plan the compact on your terms."

Honest scope first. A markdown skill is instructions, not instrumentation. It can't read your true token count and the skill explicitly says so — anyone claiming a skill alone gives live telemetry is wrong. It acts on the signals that are available: your own reports, structural self-estimation (long transcript, many large file reads), and — if installed — injected <system-reminder> lines from the free open-source context-window-awareness plugin (MIT). The plugin supplies the signal; this skill supplies the judgement. Either works standalone; together they compose.

The skill is opinionated about durable state: every important decision, every plan, every "we're going to do X next" gets written to a place that survives a compact — usually a file, sometimes a commit message, sometimes a comment in code. The rule is: if losing this session would lose this fact, the fact isn't durable yet. That single discipline is what makes the difference between "compact and continue" and "compact and start over."