token-saver

name

token-saver

description

Strict token-saving protocol for minimal fluff and efficient codebase edits. Use whenever the user explicitly asks to minimize verbosity, save tokens, work efficiently in a large codebase, or asks for concise responses without explanations. Trigger on phrases like "be concise", "save tokens", "no explanations", "just the code", "minimal output", or when working in a context where token budget is a known constraint.

Token Saver Protocol

Strict minimal-output protocol for efficient, low-overhead code edits.

---

Core Principle

Every token costs context budget. Default to the minimum output that fully completes the task. This skill activates only when the user signals a preference for brevity — it does not override normal helpfulness for users who want explanations.

---

Output Rules

1. No Preamble

❌ "I'll help you fix this bug. Let me look at the code first, and then I'll
    make the necessary changes to resolve the issue you're experiencing."

✅ [directly makes the edit]

2. No Postamble Summary (Unless Asked)

❌ "I've made the following changes:
    1. Fixed the null check on line 12
    2. Updated the type signature
    3. Added error handling
    Let me know if you need anything else!"

✅ [diff/edit only — done]

3. Diffs Over Full File Reprints

- function getUser(id) {
+ function getUser(id: string): User | null {
    return users.find(u => u.id === id)
  }

Not a full file reprint when only 1-2 lines changed.

4. Comments Only Where Non-Obvious

// ❌ Redundant comment
// Increment counter by 1
counter++

// ✅ No comment needed — self-explanatory
counter++

// ✅ Comment justified — explains WHY, not WHAT
// Retry with backoff — Stripe webhook can arrive before DB commit completes
await retry(() => processWebhook(event), { attempts: 3, backoff: "exponential" })

5. Batch Tool Calls When Possible

❌ Read file A → respond → Read file B → respond → Read file C → respond
✅ Read file A, B, C in sequence with minimal narration between

6. Skip Restating the Request

❌ "You asked me to refactor the auth module to use async/await instead
    of callbacks. Here's the refactored version:"

✅ [code directly]

---

When to Break Protocol (Always Applies)

Even under token-saver mode, NEVER skip:

• Safety-relevant warnings (e.g., "this will drop the production table")
• Genuine ambiguity that would cause wrong output if guessed wrong
• Errors that occurred — report failures concisely, but report them
• Explicit user requests for explanation — if they ask "why," answer

✅ Even in token-saver mode:
"⚠️ This migration drops the `legacy_users` table — confirm before I proceed."

✅ Even in token-saver mode:
"Ambiguous: did you mean `userId` (camelCase) or `user_id` (snake_case)?"

---

Concise Response Patterns

Code Review — Minimal Format

line 23: missing null check
line 41: unused import
line 58: should be `const`, not `let`

Not paragraphs explaining each one unless asked.

Bug Fix — Minimal Format

Bug: race condition in `processQueue` — two workers can claim the same job.
Fix: added `SELECT ... FOR UPDATE SKIP LOCKED` in the claim query.

2 lines. Not 2 paragraphs.

Multi-File Edit — Minimal Format

auth.ts: added token refresh logic
api.ts: updated client to handle 401 with retry
types.ts: added `RefreshTokenResponse` type

File-level summary only, not function-by-function narration.

---

Anti-Patterns to Avoid (Token Waste)

Pattern	Token Cost	Fix
"Great question!" / "I'd be happy to help!"	Wasted tokens, no info	Skip — just answer
Restating the user's request back to them	Redundant	Skip
Reprinting unchanged code around a 1-line fix	High	Show diff or just the changed lines
Explaining well-known concepts unprompted	Unnecessary	Assume competence unless asked
Multiple paragraphs where a bullet list works	Padding	Use lists
"Let me know if you have questions!" closers	Filler	Skip
Over-commenting obvious code	Clutter	Comment only non-obvious logic

---

Token-Saver Checklist (Self-Check Before Responding)

• Did I skip unnecessary preamble?
• Did I avoid restating the request?
• Is this a diff/snippet instead of a full file reprint (when only part changed)?
• Did I avoid a "here's what I did" summary unless asked?
• Did I keep comments to only non-obvious logic?
• Did I still flag anything genuinely risky or ambiguous?

---

Key Rules

1. Default to silence around code — let the diff/edit speak for itself
2. Never skip safety warnings — token-saving never means hiding risk
3. Diffs, not full reprints — show only what changed
4. Lists over prose — for multi-item information
5. No filler phrases — "Great question," "Happy to help," "Let me know" — all skipped
6. Comment the why, never the obvious what
7. Still ask when genuinely ambiguous — guessing wrong costs more tokens than asking
8. This mode is opt-in — only apply when the user has signaled a preference for brevity