TokenKiller (Universal Throttling)

---

name: tokenkiller

description: Reduces token usage across multi-skill agent workflows (search, coding, debugging, testing, docs) using budgets, gating, progressive disclosure, and deduped evidence. Use when the user mentions saving tokens, cost, context length, long logs, large codebases, or when tasks involve multi-step exploration or debugging.

---

# TokenKiller (Universal Throttling)

Goal

Systematically reduce token consumption without noticeably lowering success rate, applicable to agents with multiple capabilities (search/coding/debugging/testing/docs).

Task Complexity Assessment

Before setting budgets, assess task complexity:

| Complexity | Criteria | Tool Budget | Output Budget |

|------------|----------|-------------|---------------|

| Simple | Single file modification, single-point localization, clear requirements | ≤3 calls | ≤50 lines |

| Medium | Across 2-3 files, needs simple exploration, relatively clear requirements | ≤6 calls | ≤120 lines |

| Complex | Cross-module refactoring, multi-step debugging, unclear requirements | ≤10 calls | ≤200 lines |

**Extension Mechanism (Soft Warning)**: When budget is about to run out but task is incomplete:

1. Output warning: `[TokenKiller] Budget running low, current progress X/Y, remaining work: ...`

2. Continue execution, but switch to more conservative strategy

3. User can interrupt or request more detailed output at any time

Default Working Mode (Balanced)

Global Hard Rules (Must Follow)

Budget Gate (Budget + Gate)

At the start of each task, assess complexity and set corresponding budget (see above "Task Complexity Assessment"), then execute gates:

If any gate is exceeded:

Token Consumption Self-Check

High-Consumption Behaviors (Avoid)

Self-Check Timing

After every 3 tool calls, quickly self-check:

Information Layers (L0-L3)

Default output and context stay at L0-L2.

L3 Pull Scenarios (Explicit)

Only pull L3 (full content) in these scenarios:

1. **Code Modification**: When exact indentation/format matching is needed, read target function's complete code

2. **Config Debugging**: When config items are interdependent, need to see complete config block

3. **Error Analysis**: When error message is incomplete, need complete stack trace or context

4. **User Explicit Request**: User requests to see full content

**Decision Flow**:

L2 Evidence → Attempt to proceed → Fail → Determine if L3 is needed → Pull minimum necessary range

Multi-Skill Collaboration

When this Skill is activated alongside other Skills:

Priority Rules

Collaboration Mode

[User Request] → [Functional Skill Processing] → [TokenKiller Constrains Output]

Workflow (General)

1) Task Entry (Any Domain)

1. Produce L0 + L1 (quickly infer if user didn't provide)

2. Choose strategy (search/direct modification/verify first)

3. Execute minimal action

4. Immediately verify (cheapest verification first)

5. Summarize: only key conclusion + 1 next step

2) Search/Exploration (Priority Domain)

Priority:

1. **Filename/Path** (Glob)

2. **Exact String** (Grep)

3. **Semantic Search** (SemanticSearch)

4. **Read File** (Read, by sections/line ranges)

Rules:

3) Coding/Refactoring

Rules:

4) Debugging/Troubleshooting

Rules:

5) Testing/Verification

Priority (from cheap to expensive):

1. lint / typecheck

2. build

3. unit test

4. e2e / browser automation

When failed, only append "diff information", don't repost full output.

6) Docs/Summary

Rules:

Output Template (Default)

Use the following structure, unless user explicitly requests other format:

Trigger Words (Recommended Auto-Enable)

Force enable this Skill when user mentions any of the following keywords/scenarios: