Token optimization: 69% line reduction across all 14 skills with no behavioral regression

[skibxskatic]

Summary

I ran a systematic token optimization pass across all 14 superpowers skills, reducing them from 3,150 to 977 lines (69%) with no loss of non-obvious behavioral guidance. Every skill loads fully into context when invoked, so line count directly impacts per-invocation token cost.

Methodology

Applied four questions to every section:

1. "Would Claude do this anyway?" — Cut it (e.g., "use async/await for I/O")
2. "Non-obvious default?" — Keep it (e.g., iron law in TDD, safety gates)
3. "Description redundancy?" — Cut duplicate triggering/explanation sections
4. "Reference vs. inline?" — Heavy content (>30 lines) → reference file

Per-skill results

Skill	Before	After	Reduction	Key cuts
writing-skills	655	110	83%	CSO section (128→15), rationalization tables, anti-pattern galleries
test-driven-development	371	108	71%	"Why Order Matters" rebuttals, rationalizations table, verbose code examples
systematic-debugging	296	64	78%	Red flags list, rationalizations table, verbose bash examples
subagent-driven-development	277	114	59%	Example workflow (75 lines), advantages section (31 lines)
using-git-worktrees	218	66	70%	Example workflow, common mistakes (redundant with quick ref)
receiving-code-review	213	58	73%	Forbidden responses verbosity, real examples section
finishing-a-development-branch	200	76	62%	Common mistakes, red flags (redundant with process)
dispatching-parallel-agents	182	67	63%	Real example, key benefits, "when NOT to use"
brainstorming	164	80	51%	Anti-pattern section, key principles (mostly obvious)
writing-plans	145	79	46%	Verbose "Remember" section
verification-before-completion	139	41	70%	Rationalization prevention table, red flags, "Why This Matters"
using-superpowers	115	52	55%	12-row rationalization table, verbose flowchart
requesting-code-review	105	32	70%	Verbose example, red flags
executing-plans	70	30	57%	Minor trims
Total	3,150	977	69%

Patterns observed

Most cuttable content types (in order of savings):

1. Rationalization tables — Every skill had a "thoughts that mean STOP" table. These repeat the same meta-pattern and Claude already understands adversarial self-monitoring. One table in using-superpowers is sufficient.
2. Red flags lists — Similar to rationalization tables but framed as warning signs. Redundant when the process itself is clear.
3. Verbose examples/workflows — Full example scenarios (50-75 lines each) that demonstrate usage. Claude generalizes well from concise instructions.
4. Marketing copy — "Why this matters", "Key benefits", "Real-world impact" sections. These convince a human reader but don't change Claude's behavior.
5. Redundant sections — Common mistakes that restate the process in negative form, "bottom line" summaries that repeat the introduction.

Most valuable content to keep:

1. Flowcharts (graphviz dot) — Non-obvious decision points, worth every token
2. Quick reference tables — Dense, scannable, high information density
3. Safety gates — Hard stops that prevent skipping steps (iron law, verification gates)
4. Non-obvious defaults — Things Claude wouldn't do without instruction (e.g., "don't summarize workflow in description" in writing-skills)
5. Reference file pointers — Lazy-loading heavy content only when needed

Suggestion

Consider offering a "lean mode" or applying these cuts to the default skills. The current skills are well-written but optimized for human readability rather than token efficiency. Since skills load fully into context on every invocation, the 69% reduction meaningfully impacts cost and leaves more context window for actual work. Use case for Claude Pro users with lower token quota limits.

Happy to share the optimized versions or discuss specific cuts.

[obra]

Yeah, the rationalization tables are there for a reason and are based on extensive testing and real world use. It sure sounds like all you’re testing is skills activation. And for that, the only thing you need to look at is the description field.

[skibxskatic]

This issue's about optimizing for token efficiency for users with smaller quota limits...?