meta-pattern-recognition
Meta-Pattern Recognition
Overview
When the same pattern appears in 3+ domains, it's probably a universal principle worth extracting.
Core principle: Find patterns in how patterns emerge.
Quick Reference
| Pattern Appears In | Abstract Form | Where Else? |
|---|---|---|
| CPU/DB/HTTP/DNS caching | Store frequently-accessed data closer | LLM prompt caching, CDN |
| Layering (network/storage/compute) | Separate concerns into abstraction levels | Architecture, organization |
| Queuing (message/task/request) | Decouple producer from consumer with buffer | Event systems, async processing |
| Pooling (connection/thread/object) | Reuse expensive resources | Memory management, resource governance |
Process
- Spot repetition - See same shape in 3+ places
- Extract abstract form - Describe independent of any domain
- Identify variations - How does it adapt per domain?
- Check applicability - Where else might this help?
Example
Pattern spotted: Rate limiting in API throttling, traffic shaping, circuit breakers, admission control
Abstract form: Bound resource consumption to prevent exhaustion
Variation points: What resource, what limit, what happens when exceeded
New application: LLM token budgets (same pattern - prevent context window exhaustion)
Red Flags You're Missing Meta-Patterns
- "This problem is unique" (probably not)
- Multiple teams independently solving "different" problems identically
- Reinventing wheels across domains
- "Haven't we done something like this?" (yes, find it)
Remember
- 3+ domains = likely universal
- Abstract form reveals new applications
- Variations show adaptation points
- Universal patterns are battle-tested
More from fimoklei/pm-ai-playbook
first-principles-decomposer
Break any problem down to fundamental truths, then rebuild solutions from atoms up. Use when user says "firstp", "first principles", "from scratch", "what are we assuming", "break this down", "atomic", "fundamental truth", "physics thinking", "Elon method", "bedrock", "ground up", "core problem", "strip away", or challenges assumptions about how things are done.
22optimize-docs
Condense markdown documentation for token efficiency while preserving all semantic meaning. Use when rules, documentation, or config files need optimization. Target 25-40% reduction through systematic condensation patterns.
20pre-mortem-analyst
Imagine the project already failed, then work backward to find why. More powerful than risk assessment because it assumes failure is certain. Use when user says "pre-mortem", "premortem", "imagine this failed", "what could go wrong", "risk analysis", "before we launch", "stress test", "what would kill this", "project risks".
20idea-challenger
Pre-launch red team analysis that identifies failure modes and validates assumptions before resource commitment. Use when evaluating new products/features/strategies, before significant resource allocation, when stakeholders seem overly optimistic, or when cost of failure would be high (reputation, budget, market position).
20inversion-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".
20security-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.
18