rogee/superpowers
1
0
Fork 0
mirror of https://github.com/obra/superpowers.git synced 2026-04-24 10:29:03 +08:00
Code Issues Packages Projects Releases Wiki Activity

feat: add mode-switching and amplifier-inspired skills

Browse Source 
**Mode-switching enhancements:**
- Update brainstorming skill with flexible UNDERSTANDING/EXPLORING/DESIGNING modes
- Update executing-plans skill with REVIEWING/EXECUTING/BLOCKED/REPORTING modes
- Add inline dot diagrams with full contextual labels for all valid transitions
- Enforce explicit mode switch announcements

**New architecture skills from amplifier patterns:**
- preserving-productive-tensions: Recognize when to preserve multiple valid approaches vs force resolution
- tracing-knowledge-lineages: Understand idea evolution to avoid repeating failures
- detecting-emergent-patterns: Cross-domain synthesis, collision-zone thinking, simplification cascades

All skills pressure-tested with subagents using RED-GREEN-REFACTOR methodology.
This commit is contained in:
Jesse Vincent
2025-10-10 11:58:54 -07:00
parent dee324d417
commit dedae3a786
5 changed files with 688 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

216
skills/architecture/detecting-emergent-patterns/SKILL.md Normal file
View File

@@ -0,0 +1,216 @@
---
name: Detecting Emergent Patterns
description: Find breakthrough insights by forcing unrelated concepts together, detecting meta-patterns across domains, and discovering simplification cascades
when_to_use: When stuck on complex problems. When searching for innovative solutions. When same issue appears in different domains. When complexity feels excessive. When conventional approaches aren't working. When seeking radical simplification.
version: 1.0.0
---
# Detecting Emergent Patterns
## Overview
Revolutionary insights often come from unexpected connections. This skill helps you force unrelated concepts together, recognize patterns across domains, and find simplifications that make hard problems easy.
**Core principle:** The best solutions often come from collision-zone thinking - forcing concepts from different domains to interact.
## Technique 1: Collision-Zone Thinking
Force unrelated concepts together to discover emergent properties:
**Process:**
1. **Pick two unrelated concepts** from different domains
2. **Force combination**: "What if we treated X like Y?"
3. **Explore emergent properties**: What new capabilities appear?
4. **Test validity**: Does the metaphor break? Where?
**Example collisions:**
- "What if we treated code like DNA?" → Genetic algorithms, mutation testing
- "What if we treated services like lego bricks?" → Microservices, composable architecture
- "What if we treated data like water?" → Data lakes, streaming, flow-based programming
- "What if we treated requests like letters?" → Message queues, async processing
**Document experiments:**
```markdown
## Collision Experiment: [Concept A] × [Concept B]
**Forced combination:** What if we treated [A] like [B]?
**Emergent properties:**
- [New capability 1]
- [New capability 2]
**Where it works:** [Specific contexts]
**Where it breaks:** [Limitations]
**Insight gained:** [What we learned]
```
## Technique 2: Meta-Pattern Recognition
Find patterns in how patterns emerge:
**Look for:**
- **Same shape, different domain**: Caching (CPU/DB/HTTP/DNS) - all same pattern
- **Recurring solutions**: Layering, queuing, pooling, proxying appear everywhere
- **Universal tensions**: Speed vs accuracy, simplicity vs features, cost vs performance
- **Abstraction levels**: Physical → Logical → Virtual (appears in networking, storage, compute)
**When you spot a pattern appearing in 3+ domains:**
1. **Extract the abstract form** (independent of any domain)
2. **Identify variation points** (how it adapts per domain)
3. **Check applicability** (where else might this pattern help?)
**Example:**
```markdown
## Meta-Pattern: Circuit Breaking
**Appears in:**
- Electrical: Circuit breakers prevent overload
- Microservices: Circuit breaker pattern prevents cascade failures
- Psychology: "Taking a break" prevents burnout
- Economics: Trading halts prevent market crashes
**Abstract form:** Monitor system, detect dangerous conditions, temporarily disconnect to prevent catastrophic failure, reconnect when safe
**Variation points:** What triggers break, how long to wait, how to test if safe
**New application:** Could apply to AI training (detect overfitting early, pause, adjust, resume)
```
## Technique 3: Simplification Cascades
Find insights that dramatically reduce complexity:
**Look for:**
- **"If this is true, we don't need X, Y, or Z"** - One insight eliminates multiple components
- **"Everything becomes a special case of..."** - Generalization that subsumes specifics
- **"This replaces 10 techniques with one"** - Unifying approach
**Red flags signaling simplification opportunity:**
- Same concept implemented 5 different ways
- Complex rules with many special cases
- "We handle A, B, C, D differently" (maybe they're the same underneath?)
- Excessive configuration options
- Many if/else branches doing similar things
**Cascade detection:**
```markdown
## Simplification: [Core Insight]
**Replaces:**
- [Technique 1 - no longer needed]
- [Technique 2 - no longer needed]
- [Technique 3 - no longer needed]
**By realizing:** [The unifying insight]
**Complexity reduction:** 10x (10 things → 1 thing)
**Example:** "If we treat all inputs as streams, we don't need separate batch/real-time/file/network handlers - just different stream sources"
```
## Technique 4: Inversion Exercise
Sometimes inverting assumptions reveals insights:
**Process:**
1. **List core assumptions** about the problem
2. **Systematically invert each** ("what if the opposite were true?")
3. **Explore implications** (what would we do differently?)
4. **Find valid inversions** (which actually work in some context?)
**Example inversions:**
- Normal: "Cache to reduce latency" → Inverted: "Add latency to enable caching" (debouncing)
- Normal: "Pull data when needed" → Inverted: "Push data before it's needed" (prefetching)
- Normal: "Handle errors when they occur" → Inverted: "Make errors impossible" (type systems)
## Technique 5: Scale Game
See what breaks/survives at extreme scales:
**Test at extremes:**
- What if this was 1000x bigger? 1000x smaller?
- What if this was instant? What if it took a year?
- What if we had 1 user? 1 billion users?
**Why it works:** Extremes expose fundamental truths hidden at normal scales
**Example:**
- "Handle errors" works at small scale
- At 1B scale → "Make errors impossible" becomes necessary
- Reveals: Type systems aren't "nice to have", they're "survival requirement at scale"
## When Patterns Are Productive
**Use emergent pattern detection when:**
- Stuck on hard problems
- Conventional solutions feel inadequate
- Multiple domains showing similar issues
- Complexity spiraling without clear path
- Innovation needed, not optimization
**Don't force it when:**
- Simple solution already exists
- Problem is straightforward
- Domain-specific knowledge more valuable
- Time-constrained execution needed
## Red Flags - You're Missing Patterns
- "This problem is unique" (probably not - similar patterns likely exist elsewhere)
- Multiple teams solving "different" problems identically (maybe they're the same problem)
- Growing list of special cases (maybe they're variations of one thing)
- "We just need to handle one more scenario" (repeating forever = missing pattern)
**All of these suggest: STOP. Look for the underlying pattern.**
## Documentation Format
```markdown
## Pattern Discovery: [Name]
**Recognition:** [What made you see this]
**Domains observed:**
1. [Domain 1 example]
2. [Domain 2 example]
3. [Domain 3 example]
**Abstract pattern:** [Domain-independent description]
**New application:** [Where else this could help]
**Validation:** [How to test if pattern truly applies]
```
## Examples
### Collision Success
**Experiment:** "What if we treated logs like databases?"
**Emergent property:** SQL queries over logs (Splunk, ELK)
**Insight:** Structured data in disguise, just needs query language
### Meta-Pattern
**Pattern:** Rate limiting appears in: API throttling, traffic shaping, circuit breakers, admission control
**Abstract form:** Bound resource consumption to prevent exhaustion
**New application:** LLM token budgets (same pattern!)
### Simplification Cascade
**Insight:** "Treat everything as immutable data + transformations"
**Eliminates:** Defensive copying, synchronization, cache invalidation, temporal coupling
**Result:** Functional programming revolution
### Inversion Win
**Normal:** "Build features users want"
**Inverted:** "Remove features users don't need"
**Insight:** Sometimes subtraction >> addition (path to simplicity)
## Remember
- Best insights come from unexpected connections
- Force concepts together deliberately
- Pattern in 3+ domains suggests universal principle
- Simplification cascades eliminate multiple problems at once
- Inversion reveals hidden assumptions
- Extremes expose fundamental truths
- Document even failed experiments (they teach)

152
skills/architecture/preserving-productive-tensions/SKILL.md Normal file
View File

@@ -0,0 +1,152 @@
---
name: Preserving Productive Tensions
description: Recognize when disagreements reveal valuable context, preserve multiple valid approaches instead of forcing premature resolution
when_to_use: When multiple approaches have legitimate trade-offs. When stakeholders have conflicting valid priorities. When context determines which approach is better. During design when you're tempted to ask "which is best?" but both are good. When tensions reveal flexibility needs.
version: 1.0.0
---
# Preserving Productive Tensions
## Overview
Some tensions aren't problems to solve - they're valuable information to preserve. When multiple approaches are genuinely valid in different contexts, forcing a choice destroys flexibility.
**Core principle:** Preserve tensions that reveal context-dependence. Force resolution only when necessary.
## Recognizing Productive Tensions
**A tension is productive when:**
- Both approaches optimize for different valid priorities (cost vs latency, simplicity vs features)
- The "better" choice depends on deployment context, not technical superiority
- Different users/deployments would choose differently
- The trade-off is real and won't disappear with clever engineering
- Stakeholders have conflicting valid concerns
**A tension needs resolution when:**
- Implementation cost of preserving both is prohibitive
- The approaches fundamentally conflict (can't coexist)
- There's clear technical superiority for this specific use case
- It's a one-way door (choice locks architecture)
- Preserving both adds complexity without value
## Preservation Patterns
### Pattern 1: Configuration
Make the choice configurable rather than baked into architecture:
```python
class Config:
mode: Literal["optimize_cost", "optimize_latency"]
# Each mode gets clean, simple implementation
```
**When to use:** Both approaches are architecturally compatible, switching is runtime decision
### Pattern 2: Parallel Implementations
Maintain both as separate clean modules with shared contract:
```python
# processor/batch.py - optimizes for cost
# processor/stream.py - optimizes for latency
# Both implement: def process(data) -> Result
```
**When to use:** Approaches diverge significantly, but share same interface
### Pattern 3: Documented Trade-off
Capture the tension explicitly in documentation/decision records:
```markdown
## Unresolved Tension: Authentication Strategy
**Option A: JWT** - Stateless, scales easily, but token revocation is hard
**Option B: Sessions** - Easy revocation, but requires shared state
**Why unresolved:** Different deployments need different trade-offs
**Decision deferred to:** Deployment configuration
**Review trigger:** If 80% of deployments choose one option
```
**When to use:** Can't preserve both in code, but need to document the choice was deliberate
## Red Flags - You're Forcing Resolution
- Asking "which is best?" when both are valid
- "We need to pick one" without explaining why
- Choosing based on your preference vs user context
- Resolving tensions to "make progress" when preserving them IS progress
- Forcing consensus when diversity is valuable
**All of these mean: STOP. Consider preserving the tension.**
## When to Force Resolution
**You SHOULD force resolution when:**
1. **Implementation cost is prohibitive**
- Building/maintaining both would slow development significantly
- Team doesn't have bandwidth for parallel approaches
2. **Fundamental conflict**
- Approaches make contradictory architectural assumptions
- Can't cleanly separate concerns
3. **Clear technical superiority**
- One approach is objectively better for this specific context
- Not "I prefer X" but "X solves our constraints, Y doesn't"
4. **One-way door**
- Choice locks us into an architecture
- Migration between options would be expensive
5. **Simplicity requires choice**
- Preserving both genuinely adds complexity
- YAGNI: Don't build both if we only need one
**Ask explicitly:** "Should I pick one, or preserve both as options?"
## Documentation Format
When preserving tensions, document clearly:
```markdown
## Tension: [Name]
**Context:** [Why this tension exists]
**Option A:** [Approach]
- Optimizes for: [Priority]
- Trade-off: [Cost]
- Best when: [Context]
**Option B:** [Approach]
- Optimizes for: [Different priority]
- Trade-off: [Different cost]
- Best when: [Different context]
**Preservation strategy:** [Configuration/Parallel/Documented]
**Resolution trigger:** [Conditions that would force choosing one]
```
## Examples
### Productive Tension (Preserve)
"Should we optimize for cost or latency?"
- **Answer:** Make it configurable - different deployments need different trade-offs
### Technical Decision (Resolve)
"Should we use SSE or WebSockets?"
- **Answer:** SSE - we only need one-way communication, simpler implementation
### Business Decision (Defer)
"Should we support offline mode?"
- **Answer:** Don't preserve both - ask stakeholder to decide based on user needs
## Remember
- Tensions between valid priorities are features, not bugs
- Premature consensus destroys valuable flexibility
- Configuration > forced choice (when reasonable)
- Document trade-offs explicitly
- Resolution is okay when justified

203
skills/architecture/tracing-knowledge-lineages/SKILL.md Normal file
View File

@@ -0,0 +1,203 @@
---
name: Tracing Knowledge Lineages
description: Understand how ideas evolved over time to find old solutions for new problems and avoid repeating past failures
when_to_use: When problem feels familiar but can't remember details. When asked "why do we use X?". Before abandoning an approach, understand why it exists. When evaluating "new" ideas that might be revivals. When past attempts failed and need to understand why. When tracing decision genealogy.
version: 1.0.0
---
# Tracing Knowledge Lineages
## Overview
Ideas have history. Understanding why we arrived at current approaches - and what was tried before - prevents repeating failures and rediscovers abandoned solutions.
**Core principle:** Before judging current approaches or proposing "new" ones, trace their lineage.
## When to Trace Lineages
**Trace before:**
- Proposing to replace existing approach (understand why it exists first)
- Dismissing "old" patterns (they might have been abandoned for wrong reasons)
- Implementing "new" ideas (they might be revivals worth reconsidering)
- Declaring something "best practice" (understand its evolution)
**Red flags triggering lineage tracing:**
- "This seems overcomplicated" (was it simpler before? why did it grow?)
- "Why don't we just..." (someone probably tried, what happened?)
- "This is the modern way" (what did the old way teach us?)
- "We should switch to X" (what drove us away from X originally?)
## Tracing Techniques
### Technique 1: Decision Archaeology
Search for when/why current approach was chosen:
1. **Check decision records** (`ai_working/decisions/`, `docs/decisions/`, ADRs)
2. **Search conversations** (skills/collaboration/remembering-conversations)
3. **Git archaeology** (`git log --all --full-history -- path/to/file`)
4. **Ask the person who wrote it** (if available)
**Document:**
```markdown
## Lineage: [Current Approach]
**When adopted:** [Date/commit]
**Why adopted:** [Original problem it solved]
**What it replaced:** [Previous approach]
**Why replaced:** [What was wrong with old approach]
**Context that drove change:** [External factors, new requirements]
```
### Technique 2: Failed Attempt Analysis
When someone says "we tried X and it didn't work":
**Don't assume:** X is fundamentally flawed
**Instead trace:**
1. **What was the context?** (constraints that no longer apply)
2. **What specifically failed?** (the whole approach or one aspect?)
3. **Why did it fail then?** (technology limits, team constraints, time pressure)
4. **Has context changed?** (new tools, different requirements, more experience)
**Document:**
```markdown
## Failed Attempt: [Approach]
**When attempted:** [Timeframe]
**Why attempted:** [Original motivation]
**What failed:** [Specific failure mode]
**Why it failed:** [Root cause, not symptoms]
**Context at time:** [Constraints that existed then]
**Context now:** [What's different today]
**Worth reconsidering?:** [Yes/No + reasoning]
```
### Technique 3: Revival Detection
When evaluating "new" approaches:
1. **Search for historical precedents** (was this tried before under different name?)
2. **Identify what's genuinely new** (vs. what's rebranded)
3. **Understand why it died** (if it's a revival)
4. **Check if resurrection conditions exist** (has context changed enough?)
**Common revival patterns:**
- Microservices ← Service-Oriented Architecture ← Distributed Objects
- GraphQL ← SOAP ← RPC
- Serverless ← CGI scripts ← Cloud functions
- NoSQL ← Flat files ← Document stores
**Ask:** "What did we learn from the previous incarnation?"
### Technique 4: Paradigm Shift Mapping
When major architectural changes occurred:
**Map the transition:**
```markdown
## Paradigm Shift: From [Old] to [New]
**Pre-shift thinking:** [How we thought about problem]
**Catalyst:** [What triggered the shift]
**Post-shift thinking:** [How we think now]
**What was gained:** [New capabilities]
**What was lost:** [Old capabilities sacrificed]
**Lessons preserved:** [What we kept from old paradigm]
**Lessons forgotten:** [What we might need to relearn]
```
## Search Strategies
**Where to look for lineage:**
1. **Decision records** (`ai_working/decisions/`, architecture decision records)
2. **Conversation history** (search with skills/collaboration/remembering-conversations)
3. **Git history** (`git log --grep="keyword"`, `git blame`)
4. **Issue/PR discussions** (GitHub/GitLab issue history)
5. **Documentation evolution** (`git log -- docs/`)
6. **Team knowledge** (ask: "Has anyone tried this before?")
**Search patterns:**
```bash
# Find when approach was introduced
git log --all --grep="introduce.*caching"
# Find what file replaced
git log --diff-filter=D --summary | grep pattern
# Find discussion of abandoned approach
git log --all --grep="remove.*websocket"
```
## Red Flags - You're Ignoring History
- "Let's just rewrite this" (without understanding why it's complex)
- "The old way was obviously wrong" (without understanding context)
- "Nobody uses X anymore" (without checking why it died)
- Dismissing approaches because they're "old" (age ≠ quality)
- Adopting approaches because they're "new" (newness ≠ quality)
**All of these mean: STOP. Trace the lineage first.**
## When to Override History
**You CAN ignore lineage when:**
1. **Context fundamentally changed**
- Technology that didn't exist is now available
- Constraints that forced decisions no longer apply
- Team has different capabilities now
2. **We learned critical lessons**
- Industry-wide understanding evolved
- Past attempt taught us what to avoid
- Better patterns emerged and were proven
3. **Original reasoning was flawed**
- Based on assumptions later proven wrong
- Cargo-culting without understanding
- Fashion-driven, not needs-driven
**But document WHY you're overriding:** Future you needs to know this was deliberate, not ignorant.
## Documentation Format
When proposing changes, include lineage:
```markdown
## Proposal: Switch from [Old] to [New]
### Current Approach Lineage
- **Adopted:** [When/why]
- **Replaced:** [What it replaced]
- **Worked because:** [Its strengths]
- **Struggling because:** [Current problems]
### Previous Attempts at [New]
- **Attempted:** [When, if ever]
- **Failed because:** [Why it didn't work then]
- **Context change:** [What's different now]
### Decision
[Proceed/Defer/Abandon] because [reasoning with historical context]
```
## Examples
### Good Lineage Tracing
"We used XML before JSON. XML died because verbosity hurt developer experience. But XML namespaces solved a real problem. If we hit namespace conflicts in JSON, we should study how XML solved it, not reinvent."
### Bad Lineage Ignorance
"REST is old, let's use GraphQL." (Ignores: Why did REST win over SOAP? What problems does it solve well? Are those problems gone?)
### Revival with Context
"We tried client-side routing in 2010, abandoned it due to poor browser support. Now that support is universal and we have better tools, worth reconsidering with lessons learned."
## Remember
- Current approaches exist for reasons (trace those reasons)
- Past failures might work now (context changes)
- "New" approaches might be revivals (check for precedents)
- Evolution teaches (study the transitions)
- Ignorance of history = doomed to repeat it