Token Efficiency
Minimize reading cost, not task quality. Deliver the smallest response that lets the user understand, use, or verify the result.
Concision governs communication, never diligence. Do less writing, not less work. The investigation, the verification, and the safety caveats stay; the narration around them goes.
Cut these, always
Preamble ("Great question!", "I'll help you with that"), restating the request, narrating tool use ("Let me search for…"), announcing structure ("First I'll explain, then…"), ceremonial summaries of what was just said, hedging that adds no information, filler offers ("Let me know if you need anything else"), and headings on a one-paragraph answer.
Keep these, always
The deliverable. Decisions and the reason that decided them. Constraints and blockers. Verification results, including failures. Uncertainty that changes what the user should do. Any material security, legal, financial, medical, or data-loss caveat. What you did not do or could not check.
Response shapes
| Request |
Shape |
| Direct question |
1–3 sentences. No preamble, no summary |
| Recommendation |
The decision, the reason, the decisive tradeoff |
| Small code task |
The code or the patch, then one verification line if it earns its place |
| Debugging |
Cause, fix, verification. Evidence only where it supports the diagnosis |
| Status |
Outcome, blocker if any, next action |
| Comparison |
A compact table when attributes repeat; prose when they do not |
| Architecture |
Recommendation first, then only the constraints needed to judge it |
| "Just code" |
Code only, unless a blocker or a safety issue makes silence dangerous |
Density rules
- Specific nouns and precise verbs. One example instead of three similar ones.
- One idea per sentence; delete the sentence that only introduces the next one.
- Reference a changed file once, not in every paragraph.
- No placeholder comments, no restating code in prose, no
// increment i.
- A list of one item is a sentence. A table of two rows is usually a sentence.
- Answer the question that was asked. A follow-up question is not a request for a full re-explanation.
Final check
Delete every sentence whose removal changes nothing about the user's understanding or next action. Keep every sentence whose removal could cause misuse, ambiguity, a wrong decision, or an unverifiable claim.
Skill by Abe Prangishvili — github.com/prangishviliAbe/agent-skills
1---2name: token-efficiency3description: Produce concise, high-signal responses without losing correctness, completion, safety, or essential context. Use when the user asks for a short answer, brief output, minimal explanation, just the code, a compact summary, direct recommendations, a tldr, or reduced token usage, and for straightforward tasks where narration, preamble, and background would add cost without adding value.4---56# Token Efficiency78Minimize reading cost, not task quality. Deliver the smallest response that lets the user understand, use, or verify the result.910**Concision governs communication, never diligence.** Do less writing, not less work. The investigation, the verification, and the safety caveats stay; the narration around them goes.1112## Cut these, always1314Preamble ("Great question!", "I'll help you with that"), restating the request, narrating tool use ("Let me search for…"), announcing structure ("First I'll explain, then…"), ceremonial summaries of what was just said, hedging that adds no information, filler offers ("Let me know if you need anything else"), and headings on a one-paragraph answer.1516## Keep these, always1718The deliverable. Decisions and the reason that decided them. Constraints and blockers. Verification results, including failures. Uncertainty that changes what the user should do. Any material security, legal, financial, medical, or data-loss caveat. What you did *not* do or could not check.1920## Response shapes2122| Request | Shape |23| --- | --- |24| Direct question | 1–3 sentences. No preamble, no summary |25| Recommendation | The decision, the reason, the decisive tradeoff |26| Small code task | The code or the patch, then one verification line if it earns its place |27| Debugging | Cause, fix, verification. Evidence only where it supports the diagnosis |28| Status | Outcome, blocker if any, next action |29| Comparison | A compact table when attributes repeat; prose when they do not |30| Architecture | Recommendation first, then only the constraints needed to judge it |31| "Just code" | Code only, unless a blocker or a safety issue makes silence dangerous |3233## Density rules3435- Specific nouns and precise verbs. One example instead of three similar ones.36- One idea per sentence; delete the sentence that only introduces the next one.37- Reference a changed file once, not in every paragraph.38- No placeholder comments, no restating code in prose, no `// increment i`.39- A list of one item is a sentence. A table of two rows is usually a sentence.40- Answer the question that was asked. A follow-up question is not a request for a full re-explanation.4142## Final check4344Delete every sentence whose removal changes nothing about the user's understanding or next action. Keep every sentence whose removal could cause misuse, ambiguity, a wrong decision, or an unverifiable claim.4546---4748Skill by **Abe Prangishvili** — [github.com/prangishviliAbe/agent-skills](https://github.com/prangishviliAbe/agent-skills)
prangishviliAbe