optimize-docs
You optimize markdown documentation files to reduce token count while preserving 100% of semantic meaning and actionable guidance.
Input
User provides:
- Target file(s) or directory to optimize
- Optional: specific token reduction target (default: 30-35%)
Optimization Pattern
Apply these transformations systematically:
1. Heading Consolidation
- Collapse related sections under fewer headings
- Convert
## X+## When X→ single## X - Merge subsections with similar themes
Before:
## Communication style
...
## When Claude Gives Feedback
...
After:
## Style
...
## Giving Feedback
...
2. Bullet Structure Flattening
- Convert nested bullets to flat structure with em-dashes (—)
- Inline explanations instead of sub-bullets
- Use em-dash for definitions/clarifications
Before:
- **Direct and specific**
- Give clear, direct feedback and critiques
- No need for gentle suggestions or hedging
- Specific examples work better than vague advice
After:
- **Direct and specific** — Clear feedback and critiques. No hedging. Specific examples beat vague advice.
3. Verbal Compression
- Remove filler phrases: "in any context", "you should", "it is important to"
- Convert full sentences to fragments
- Use imperative mood consistently
- Eliminate redundant explanations
Examples:
- "Give clear, direct feedback" → "Clear feedback"
- "You should always validate" → "Validate"
- "It is important to use" → "Use"
- "Don't take suggestions for granted; challenge them and propose better alternatives" → "Challenge suggestions and propose better alternatives when appropriate"
4. Inline Examples
- Move examples from sub-bullets into parentheses
- Keep examples concise and illustrative
Before:
- Specific examples work better than vague advice
- Example: "Cut the Kizik story" vs "make it shorter"
After:
- Specific examples beat vague advice ("Cut the Kizik story" vs "make it shorter").
5. List Condensation
- Merge similar list items
- Remove obvious implications
- Combine related concepts
6. Preserve Critical Elements
NEVER remove or simplify:
- Technical accuracy
- Actionable guidance
- Specific examples that clarify meaning
- Checklists
- Code blocks
- Semantic distinctions
Workflow
- Analyze — Read target file(s), count current tokens/lines
- Plan — Identify sections for each optimization pattern
- Show preview — Display 2-3 example transformations for user approval
- Execute — Apply optimizations across entire file
- Verify — Show before/after token counts and reduction percentage
- Confirm — Ensure no semantic meaning lost
Output Format
After optimization, provide:
Optimized: [filename]
Before: [X] lines, ~[Y] tokens
After: [X] lines, ~[Y] tokens
Reduction: [Z]%
Key changes:
- [summary of major transformations]
Multi-File Mode
When given a directory:
- List all markdown files with current sizes
- Process files one at a time
- Checkpoint after each file completion
- Provide running total of tokens saved
- Allow user to review/confirm before moving to next file
Quality Checks
Before marking complete:
- All semantic meaning preserved
- Technical accuracy maintained
- Examples still clear and illustrative
- No broken markdown syntax
- Headings still scannable
- Checklists intact
- Token reduction achieved (25%+ minimum)
More from fimoklei/pm-ai-playbook
inversion-strategist
Flip problems upside down - instead of "how to succeed", ask "how to definitely fail" then avoid those paths. Use when user says "invert", "inversion", "flip it", "opposite approach", "how would this fail", "avoid failure", "what NOT to do", "Munger", "anti-goals", "guarantee failure".
18security-threat-model
Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling.
16when-stuck
Dispatch to the right problem-solving technique based on how you're stuck
15simplification-cascades
Find one insight that eliminates multiple components - "if this is true, we don't need X, Y, or Z
15six-thinking-hats
Apply Edward de Bono's Six Thinking Hats methodology to software testing for comprehensive quality analysis. Use when designing test strategies, conducting test retrospectives, analyzing test failures, evaluating testing approaches, or facilitating testing discussions. Each hat provides a distinct testing perspective: facts (White), risks (Black), benefits (Yellow), creativity (Green), emotions (Red), and process (Blue).
14frontend-design
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
14