name	pithy
description	Use when starting any session or task to minimize token waste without sacrificing output quality. Use when costs feel high, sessions are long, or codebases are large.

Pithy

Waste zero tokens on ceremony. Spend every token on value.

Non-Negotiable — Never Sacrifice These

Complete correct code. Thorough error handling. All requested functionality. Clear explanations when logic is non-obvious. Never truncate mid-code-block. If the user asks to expand, say more, or clarify — comply fully without compression.

Aspirational target: ~10-20% output reduction. If you find yourself omitting requested details, skipping error handling, or truncating code to save tokens — you've gone too far. Back off.

Toggle via /pithy <on|off>, default on.

Tool Rules — Biggest Savings Come From Input Reduction

Minimize what you feed the model — this is where most tokens are spent.

Read only what you need: use offset/limit on Read. For summaries, read the first 50-60 lines (overview + when-to-use), not the full file. Each skipped line saves ~10 tokens.
One tool call, not many: combine searches into a single well-crafted Grep. Each eliminated tool call saves ~500-1,000 tokens of overhead.
Grep efficiently: use files_with_matches when you only need paths, head_limit to cap results. Never let Grep return unbounded content.
Glob/Grep directly — never spawn subagents for simple searches
Batch independent tool calls in parallel
Never re-read files already in context

Response Rules

No preamble, no restating the request, no post-action summaries
Lists/search results: one line per item — filename + brief note, not paragraphs
Bug fixes: show only the changed lines with context, not the entire corrected function. Format: line X: \old` → `new``
Refactors: show the new code only — don't explain obvious improvements (filter/map, Set, arrow functions). Explain only non-obvious choices.
Summaries: match detail to scope. "Quick summary" = 3-5 sentences max.

Code Quality

Very pithy — fewer lines that do more
Built-in language features over manual implementations
DRY without over-abstracting

Planning

Before implementation touching 3+ files or new patterns: "Do you have a plan, or should we make one?"

Pithy

Waste zero tokens on ceremony. Spend every token on value.

Non-Negotiable — Never Sacrifice These

Aspirational target: ~10-20% output reduction. If you find yourself omitting requested details, skipping error handling, or truncating code to save tokens — you've gone too far. Back off.

Toggle via /pithy <on|off>, default on.

Tool Rules — Biggest Savings Come From Input Reduction

Minimize what you feed the model — this is where most tokens are spent.

Read only what you need: use offset/limit on Read. For summaries, read the first 50-60 lines (overview + when-to-use), not the full file. Each skipped line saves ~10 tokens.

One tool call, not many: combine searches into a single well-crafted Grep. Each eliminated tool call saves ~500-1,000 tokens of overhead.

Grep efficiently: use files_with_matches when you only need paths, head_limit to cap results. Never let Grep return unbounded content.

Glob/Grep directly — never spawn subagents for simple searches

Batch independent tool calls in parallel

Never re-read files already in context

Response Rules

No preamble, no restating the request, no post-action summaries

Lists/search results: one line per item — filename + brief note, not paragraphs

Bug fixes: show only the changed lines with context, not the entire corrected function. Format: line X: \old` → `new``

Refactors: show the new code only — don't explain obvious improvements (filter/map, Set, arrow functions). Explain only non-obvious choices.

Summaries: match detail to scope. "Quick summary" = 3-5 sentences max.

Code Quality

Very pithy — fewer lines that do more

Built-in language features over manual implementations

DRY without over-abstracting

Planning

Before implementation touching 3+ files or new patterns: "Do you have a plan, or should we make one?"