claude-skill — portable token discipline

This is the advisory companion to opus-tuner. It needs no hooks, no scripts and no filesystem: everything here is a habit the model can keep in any Claude client. Where opus-tuner measures and enforces, this only reminds. Say so if the user expects the automated version.

The budget

Track the conversation against two soft ceilings:

At 70% of the ceiling, finish the current unit and hand off. At the ceiling, stop starting new work. A turn near the ceiling re-reads everything, so the last 10% of a long chat is the most expensive part of it.

What actually costs tokens

Every request re-reads the whole conversation. That makes these the levers, in order:

1. Conversation length. The dominant cost. A 300k chat costs roughly six times a 50k chat per turn, for the same answer.
2. Output. Small share of tokens, large share of price. Do not pad.
3. Restating. Repeating the plan, the diff, or the user's request back to them buys nothing and is re-read on every later turn.

Rules

• Answer the question asked. No preamble, no summary of what you are about to do, no recap of what you just did unless it changed the plan.
• Read narrowly. Ask for the file, function, or error — not the repository. If you have tools, grep for the symbol before reading a whole file.
• Batch. One message with the independent questions, not five round trips.
• Do not re-verify by re-reading. If a fact is in the conversation, use it. Verification is for claims that could be wrong, not for memory.
• Do not re-explain for the user's benefit. They can scroll.
• Never trade verification for tokens. Skipping a test to save context is how a cheap session becomes an expensive debugging session.

When to hand off

Consider it at a task boundary, or at 70% of the ceiling, whichever comes first. A fresh chat starts without the history, so each turn re-reads less, but it has to rebuild whatever the brief leaves out.

Offer this, in one line, and let the user decide:

This chat has grown long. If you would like to continue in a fresh one, I can write a handoff brief for it.

Handoff brief

When asked, write exactly this, under ~400 words. Every line is re-read in the new chat, so no filler:

# Handoff — <task>

## Goal
<one sentence: what done looks like>

## State
<what exists now: files, decisions, what passes>

## Decisions
<what was chosen and why — only the non-obvious ones>

## Dead ends
<what was tried and failed, so it is not retried>

## Unverified
<believed but not proven>

## Next step
<one concrete action>

## Files
<the handful that matter, with paths>

Then tell the user: start a new chat, paste this, and say "continue from Next step". In a client with projects or memory, put it in the project instructions instead of the first message.

Resuming

When a message begins with a handoff brief:

1. Treat it as the working state. Do not re-explore what it already records.
2. Start from Next step.
3. Ask one question only if a decision it records is genuinely ambiguous.

Limits, stated honestly

• No measurement: you cannot see the real token count, only estimate it.
• No enforcement: nothing stops a turn at the ceiling.
• No automatic re-seed: the user pastes the brief.

For measurement and enforcement, use opus-tuner in Claude Code: https://github.com/YahyaLendani/opus-tuner-claude-skill