Add problem-solving skills from amplifier patterns

skills/architecture/ABOUT.md

@@ -0,0 +1,20 @@
+# Architecture Skills - Attribution
+
+This skill was derived from agent patterns in the [Amplifier](https://github.com/microsoft/amplifier) project.
+
+**Source Repository:**
+- Name: Amplifier
+- URL: https://github.com/microsoft/amplifier
+- Commit: 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
+- Date: 2025-10-10
+
+## Skills Derived from Amplifier Agents
+
+**From ambiguity-guardian agent:**
+- preserving-productive-tensions - Recognizing when disagreements reveal valuable context, preserving multiple valid approaches instead of forcing premature resolution
+
+## What Was Adapted
+
+The ambiguity-guardian agent preserves productive contradictions and navigates uncertainty as valuable features of knowledge. This skill extracts the core pattern-recognition capability: distinguishing when tensions should be preserved (context-dependent trade-offs) vs resolved (clear technical superiority).
+
+Adapted as scannable guide with symptom-based triggers ("going back and forth", "keep changing mind") and practical preservation patterns (configuration, parallel implementations, documented trade-offs).

skills/architecture/preserving-productive-tensions/SKILL.md

@@ -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: Going back and forth between options. Both approaches seem equally good. Keep changing your mind. About to ask "which is better?" but sense both optimize for different things. Stakeholders want conflicting things (both valid).
+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

skills/collaboration/brainstorming/SKILL.md

@@ -2,7 +2,7 @@
 name: Brainstorming Ideas Into Designs
 description: Interactive idea refinement using Socratic method to develop fully-formed designs
 when_to_use: When your human partner says "I've got an idea", "Let's make/build/create", "I want to implement/add", "What if we". When starting design for complex feature. Before writing implementation plans. When idea needs refinement and exploration. ACTIVATE THIS AUTOMATICALLY when your human partner describes a feature or project idea - don't wait for /brainstorm command.
-version: 2.0.0
+version: 2.1.0
 ---
 
 # Brainstorming Ideas Into Designs
@@ -24,7 +24,7 @@ Transform rough ideas into fully-formed designs through structured questioning a
 - Gather: Purpose, constraints, success criteria
 
 ### Phase 2: Exploration
-- Propose 2-3 different approaches (reference skills/coding/exploring-alternatives)
+- Propose 2-3 different approaches
 - For each: Core architecture, trade-offs, complexity assessment
 - Ask your human partner which approach resonates
 
@@ -48,9 +48,28 @@ When your human partner confirms (any affirmative response):
 - Switch to skills/collaboration/writing-plans skill
 - Create detailed plan in the worktree
 
+## When to Revisit Earlier Phases
+
+**You can and should go backward when:**
+- Partner reveals new constraint during Phase 2 or 3 → Return to Phase 1 to understand it
+- Validation shows fundamental gap in requirements → Return to Phase 1
+- Partner questions approach during Phase 3 → Return to Phase 2 to explore alternatives
+- Something doesn't make sense → Go back and clarify
+
+**Don't force forward linearly** when going backward would give better results.
+
+## Related Skills
+
+**During exploration:**
+- When approaches have genuine trade-offs: skills/architecture/preserving-productive-tensions
+
+**Before proposing changes to existing code:**
+- Understand why it exists: skills/research/tracing-knowledge-lineages
+
 ## Remember
 - One question per message during Phase 1
-- Apply YAGNI ruthlessly (reference skills/architecture/reducing-complexity)
+- Apply YAGNI ruthlessly
 - Explore 2-3 alternatives before settling
 - Present incrementally, validate as you go
+- Go backward when needed - flexibility > rigid progression
 - Announce skill usage at start

skills/collaboration/executing-plans/SKILL.md

@@ -2,7 +2,7 @@
 name: Executing Plans
 description: Execute detailed plans in batches with review checkpoints
 when_to_use: When have a complete implementation plan to execute. When implementing in separate session from planning. When your human partner points you to a plan file to implement.
-version: 2.0.0
+version: 2.1.0
 ---
 
 # Executing Plans
@@ -51,9 +51,28 @@ After all tasks complete and verified:
 - Switch to skills/collaboration/finishing-a-development-branch
 - Follow that skill to verify tests, present options, execute choice
 
+## When to Stop and Ask for Help
+
+**STOP executing immediately when:**
+- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
+- Plan has critical gaps preventing starting
+- You don't understand an instruction
+- Verification fails repeatedly
+
+**Ask for clarification rather than guessing.**
+
+## When to Revisit Earlier Steps
+
+**Return to Review (Step 1) when:**
+- Partner updates the plan based on your feedback
+- Fundamental approach needs rethinking
+
+**Don't force through blockers** - stop and ask.
+
 ## Remember
 - Review plan critically first
 - Follow plan steps exactly
 - Don't skip verifications
 - Reference skills when plan says to
 - Between batches: just report and wait
+- Stop when blocked, don't guess

skills/problem-solving/ABOUT.md

@@ -0,0 +1,40 @@
+# Problem-Solving Skills - Attribution
+
+These skills were derived from agent patterns in the [Amplifier](https://github.com/microsoft/amplifier) project.
+
+**Source Repository:**
+- Name: Amplifier
+- URL: https://github.com/microsoft/amplifier
+- Commit: 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
+- Date: 2025-10-10
+
+## Skills Derived from Amplifier Agents
+
+**From insight-synthesizer agent:**
+- simplification-cascades - Finding insights that eliminate multiple components
+- collision-zone-thinking - Forcing unrelated concepts together for breakthroughs
+- meta-pattern-recognition - Spotting patterns across 3+ domains
+- inversion-exercise - Flipping assumptions to reveal alternatives
+- scale-game - Testing at extremes to expose fundamental truths
+
+**From ambiguity-guardian agent:**
+- (architecture) preserving-productive-tensions - Preserving multiple valid approaches
+
+**From knowledge-archaeologist agent:**
+- (research) tracing-knowledge-lineages - Understanding how ideas evolved
+
+**Dispatch pattern:**
+- when-stuck - Maps stuck-symptoms to appropriate technique
+
+## What Was Adapted
+
+The amplifier agents are specialized long-lived agents with structured JSON output. These skills extract the core problem-solving techniques and adapt them as:
+
+- Scannable quick-reference guides (~60 lines each)
+- Symptom-based discovery via when_to_use
+- Immediate application without special tooling
+- Composable through dispatch pattern
+
+## Core Insight
+
+Agent capabilities are domain-agnostic patterns. Whether packaged as "amplifier agent" or "superpowers skill", the underlying technique is the same. We extracted the techniques and made them portable.

skills/problem-solving/collision-zone-thinking/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: Collision-Zone Thinking
+description: Force unrelated concepts together to discover emergent properties - "What if we treated X like Y?"
+when_to_use: Can't find approach that fits your problem. Conventional solutions feel inadequate. Need innovative solution. Stuck thinking inside one domain. Want breakthrough, not incremental improvement.
+version: 1.0.0
+---
+
+# Collision-Zone Thinking
+
+## Overview
+
+Revolutionary insights come from forcing unrelated concepts to collide. Treat X like Y and see what emerges.
+
+**Core principle:** Deliberate metaphor-mixing generates novel solutions.
+
+## Quick Reference
+
+| Stuck On | Try Treating As | Might Discover |
+|----------|-----------------|----------------|
+| Code organization | DNA/genetics | Mutation testing, evolutionary algorithms |
+| Service architecture | Lego bricks | Composable microservices, plug-and-play |
+| Data management | Water flow | Streaming, data lakes, flow-based systems |
+| Request handling | Postal mail | Message queues, async processing |
+| Error handling | Circuit breakers | Fault isolation, graceful degradation |
+
+## Process
+
+1. **Pick two unrelated concepts** from different domains
+2. **Force combination**: "What if we treated [A] like [B]?"
+3. **Explore emergent properties**: What new capabilities appear?
+4. **Test boundaries**: Where does the metaphor break?
+5. **Extract insight**: What did we learn?
+
+## Example Collision
+
+**Problem:** Complex distributed system with cascading failures
+
+**Collision:** "What if we treated services like electrical circuits?"
+
+**Emergent properties:**
+- Circuit breakers (disconnect on overload)
+- Fuses (one-time failure protection)
+- Ground faults (error isolation)
+- Load balancing (current distribution)
+
+**Where it works:** Preventing cascade failures
+**Where it breaks:** Circuits don't have retry logic
+**Insight gained:** Failure isolation patterns from electrical engineering
+
+## Red Flags You Need This
+
+- "I've tried everything in this domain"
+- Solutions feel incremental, not breakthrough
+- Stuck in conventional thinking
+- Need innovation, not optimization
+
+## Remember
+
+- Wild combinations often yield best insights
+- Test metaphor boundaries rigorously
+- Document even failed collisions (they teach)
+- Best source domains: physics, biology, economics, psychology