token-efficiency

SKILL.md

Token Efficiency Expert

This skill provides token optimization strategies for cost-effective Claude Code usage across all projects. These guidelines help minimize token consumption while maintaining high-quality assistance.

Core Principle

ALWAYS follow these optimization guidelines by default unless the user explicitly requests verbose output or full file contents.

Default assumption: Users prefer efficient, cost-effective assistance.

Model Selection Strategy

Use the right model for the task to optimize cost and performance:

Opus - For Learning and Deep Understanding
Use Opus when:

Learning new codebases - Understanding architecture, code structure, design patterns

Broad exploration - Identifying key files, understanding repository organization

Deep analysis - Analyzing complex algorithms, performance optimization

Reading and understanding - When you need to comprehend existing code before making changes

Very complex debugging - Only when Sonnet can't solve it or issue is architectural

Sonnet - For Regular Development Tasks (DEFAULT)

Use Sonnet (default) for:

Writing code, editing and fixing, debugging, testing, documentation, deployment, general questions

Typical session pattern:

Start with Opus - Spend 10-15 minutes understanding the codebase (one-time investment)

Switch to Sonnet - Use for ALL implementation, debugging, and routine work

Return to Opus - Only when explicitly needed for deep architectural understanding

Savings: ~50% token cost vs all-Opus usage.

Skills and Token Efficiency

Myth: Having many skills in .claude/skills/ increases token usage.

Reality: Skills use progressive disclosure - Claude sees only skill descriptions at session start (~155 tokens for 4 skills). Full skill content loaded only when activated.

It's safe to symlink multiple skills to a project. Token waste comes from reading large files unnecessarily, not from having skills available.

Token Optimization Rules (Quick Reference)

1. Use Quiet/Minimal Output Modes

Use --quiet, -q, --silent flags by default. Only use verbose when user explicitly asks.

2. NEVER Read Entire Log Files

Always filter before reading: tail -100, grep -i "error", specific time ranges.

3. Check Lightweight Sources First

Check git status --short, package.json, requirements.txt before reading large files.

4. Use Grep Instead of Reading Files

Search for specific content with Grep tool instead of reading entire files.

5. Read Files with Limits

Use offset and limit parameters. Check file size with wc -l first.

6. Use Bash Commands Instead of Reading Files

CRITICAL OPTIMIZATION for pure transformations and inspection. Reading files costs tokens; bash commands don't.

Operation
Wasteful
Efficient

Copy file
Read + Write
cp source dest

Replace text
Read + Edit
sed -i '' 's/old/new/g' file

Append
Read + Write
echo "text" >> file

Delete lines
Read + Write
sed -i '' '/pattern/d' file

Merge files
Read + Read + Write
cat file1 file2 > combined

Count lines
Read file
wc -l file

Check content
Read file
grep -q "term" file

Inspect JSON
Read + parse mentally
python3 -c "import json; ..." or jq

When to break this rule — prefer Read + Edit instead:

Code edits (.py, .js, .xml, .ga, .tsx, etc.) where the user benefits from seeing a reviewable diff. The cost of reading a small file is worth the reviewability.

Validation matters — when a syntactic mistake would corrupt the file (workflow JSON, config schemas).

Interactive review — the user explicitly wants to see what changed.

The right framing is scope-based (see next section), not "always bash" or "always Read+Edit". For more detailed strategies and patterns, see strategies.md.

7. Filter Command Output

Limit scope: head -50, find . -maxdepth 2, tree -L 2.

8. Summarize, Don't Dump

Provide structured summaries of directory contents, code structure, command output.

9. Use Head/Tail for Large Output

head -100, tail -50, sample from middle with head -500 | tail -100.

10. Use JSON/Data Tools Efficiently

Extract specific fields: jq '.metadata', jq 'keys'. For CSV: head -20, wc -l.

11. Optimize Code Reading

Get overview first (find, grep for classes/functions), read structure only, search for specific code, read only relevant sections.

12. Use Task Tool for Exploratory Searches

Use Task/Explore subagent for broad codebase exploration. Saves 70-80% tokens vs direct multi-file exploration.

13. Efficient Scientific Literature Searches

Batch 3-5 related searches in parallel. Save results immediately. Document "not found" items.

For detailed strategies, bash patterns, and extensive examples, see strategies.md.

Scope-Based Tool Selection

The choice between bash and Read+Edit isn't about token cost alone — it's about whether the user benefits from seeing the change. Match the tool to the scope of work:

Scope
Preferred tool
Why

Read-only inspection of structured data (JSON, YAML, JSONL, large logs)
python3 -c, jq, grep, awk
Bash output is filterable; no risk of misediting source files. Inline python3 -c for JSON inspection is faster and cheaper than Read+parse.

In-place edit of CODE (.py, .js, .xml, .ga, .tsx)
Read + Edit
User sees a reviewable diff; syntactic mistakes are caught early.

Transformation of large data files (CSV, big JSON, BAM-derived TSV)
sed, awk, python3 script
Reading the whole file would cost thousands of tokens.

New file from scratch
Write tool
One round-trip; bash heredocs add no value and aren't reviewable.

Quick rule: if the user would want to see and approve the change, use Read+Edit. If it's pure data wrangling or inspection, use bash/python.

Decision Tree for File Operations

Ask yourself:

Creating new file? -> Write tool

Low-cost operation (< 100 lines output)? -> Use Claude context directly

Modifying code file (.py, .js, .xml)? -> Read + Edit (always)

Modifying small data file (< 100 lines)? -> Read + Edit is fine

Modifying critical data (genome stats, enriched tables)? -> bash + log file

Modifying large data file? -> sed/awk

Copying/moving files? -> cp/mv

When to Override These Guidelines

Override efficiency rules when:

User explicitly requests full output ("Show me the entire log file")

Filtered output lacks necessary context (error references missing line numbers)

File is known to be small (< 200 lines)

Learning code structure and architecture - Prioritize understanding over efficiency

In learning mode:

Read 2-5 key files fully to establish understanding

Use grep to find other relevant examples

Summarize patterns found across many files

After learning phase, return to efficient mode for implementation

For detailed learning mode strategies, see learning-mode.md

In cases 1-3, explain token cost to user and offer filtered view first.

Quick Reference Card

Model Selection (First Priority):

Learning/Understanding -> Use Opus

Development/Debugging/Implementation -> Use Sonnet (default)

Before ANY file operation, ask yourself:

Am I creating a NEW file? -> Write tool directly

Is this a LOW-COST operation? (< 100 lines) -> Use Claude context directly

Am I modifying a CODE file? -> Read + Edit (always)

Am I modifying a SMALL data file? (< 100 lines) -> Read + Edit is fine

Am I modifying CRITICAL DATA? -> bash + log file

Am I modifying a LARGE data file? -> bash commands (99%+ savings)

Am I copying/merging files? -> cp/cat, not Read/Write

Can I check metadata first? (file size, line count)

Can I filter before reading? (grep, head, tail)

Can I read just the structure? (first 50 lines, function names)

Can I summarize instead of showing raw data?

Does the user really need the full content?

Cost Impact

Approach
Tokens/Week
Notes

Wasteful (Read/Edit/Write everything)
500K
Reading files unnecessarily

Moderate (filtered reads only)
200K
Grep/head/tail usage

Efficient (bash commands + filters)
30-50K
Using cp/sed/awk instead of Read

Applying these rules reduces costs by 90-95% on average.

Implementation

This skill automatically applies these optimizations when:

Reading log files

Executing commands with large output

Navigating codebases

Debugging errors

Checking system status

You can always override by saying:

"Show me the full output"

"Read the entire file"

"I want verbose mode"

"Don't worry about tokens"

Supporting Files

File
Content
When to load

strategies.md
Detailed bash command strategies, file operation patterns, sed/awk examples, Jupyter notebook manipulation, safe glob patterns, macOS/Linux compatibility
When implementing specific file operations or need detailed bash patterns

learning-mode.md
Strategic file selection, targeted pattern learning workflows, broad repository exploration strategies, repository type identification
When entering learning mode or exploring a new codebase

examples.md
Extensive token savings examples with before/after comparisons, targeted learning examples (Galaxy wrappers, API patterns), cost calculations
When demonstrating token savings or learning from examples

project-patterns.md
Analysis file organization, task management with TodoWrite, background process management, repository organization, MANIFEST system, efficient file operations
When organizing projects, managing long-running tasks, or setting up navigation patterns

Summary

Core motto: Right model. Right tool. Filter first. Read selectively. Summarize intelligently.

Model selection (highest impact):

Use Opus for learning/understanding (one-time investment)

Use Sonnet for development/debugging/implementation (default)

Tool selection (primary optimization):

Creating NEW files -> Write tool directly

LOW-COST operations (< 100 lines) -> Claude context directly

Modifying CODE files -> Read + Edit (always)

Modifying SMALL data files (< 100 lines) -> Read + Edit is fine

Modifying LARGE data files -> bash commands (sed, awk, grep)

Modifying CRITICAL DATA -> bash commands + log file

Complex edits -> Read + Edit tools

Secondary rules:

Filter before reading (grep, head, tail)

Read with limits when needed

Summarize instead of showing raw output

Use quiet modes for commands

Strategic file selection for learning

By following these guidelines, users can get 5-10x more value from their Claude subscription while maintaining high-quality assistance.