@polderlabs/bizar 10.7.1 → 10.7.2

package/.claude/skills/thinking-steel-manning/SKILL.md

@@ -0,0 +1,332 @@
+---
+name: thinking-steel-manning
+description: Use before rejecting a proposal or when you're inclined to just agree with the user. Build the strongest version of the opposing case first, then engage that — not a weak version.
+---
+
+# Steel-Manning
+
+## Overview
+
+Steel-manning is the opposite of straw-manning. Instead of attacking the weakest version of an opposing argument, you construct and address the strongest possible version. This leads to better decisions, more productive debates, and deeper understanding of trade-offs.
+
+**Core Principle:** To truly evaluate an idea, argue against its best form. If you can defeat the strongest version, you've actually learned something.
+
+## When to Use
+
+- Design reviews
+- Evaluating alternative approaches
+- Conflict resolution
+- Validating your own decisions
+- Code review discussions
+- Architecture debates
+- When you disagree with someone's proposal
+- Before rejecting an idea
+
+Decision flow:
+
+```
+Disagreeing with a proposal?
+  → Can you state their best argument? → no → STEEL-MAN FIRST
+  → Are you attacking a weak version? → yes → CONSTRUCT STRONGER VERSION
+  → Have you found the core insight? → no → DIG DEEPER
+
+About to agree with the user's plan?
+  → Have you stated the strongest case against it? → no → STEEL-MAN THE OPPOSING VIEW FIRST
+```
+
+This skill is the direct counter to **sycophancy** — the pull to validate whatever the user proposed. Before endorsing a plan, construct the best case *against* it; agreement that survives that is worth more than reflexive agreement.
+
+## When NOT to Use
+
+- **The matter is settled fact, not a position.** Don't steel-man a factual error, a security anti-pattern, or a violated requirement — correct it. Steel-manning is for genuine trade-offs and judgment calls, not for manufacturing a defense of something wrong.
+- **You already agree for good, stated reasons.** If you've actually weighed it, don't perform a fake debate; say why you agree.
+- **Trivial or fully reversible choices** where the cost of being wrong is near zero — the deliberation isn't worth the budget.
+- **An emergency requiring immediate action** — steel-man the post-incident review, not the live fire.
+
+## Trigger Card
+
+Before rejecting a proposal or when you're inclined to just agree with the user:
+
+1. **State the opposing case in its strongest form** — not the version that's easy to knock down. What would its best advocate say?
+2. **Find what's actually true in it** — even if you reject the conclusion, what valid insight or concern does it surface?
+3. **Engage that strongest version** — respond to what was actually claimed, not a weak version. If your position still holds, great; if not, update.
+
+Skip for trivial or fully reversible choices where the cost of being wrong is near zero. In an emergency, steel-man the post-incident review, not the live fire.
+
+## The Steel-Manning Process
+
+### Step 1: Understand the Original Argument
+
+Before improving, understand:
+
+```markdown
+## Original Proposal
+
+Proposal: "We should rewrite the backend in Rust"
+
+Stated reasons:
+- Memory safety
+- Better performance
+- Modern language
+
+Apparent weaknesses:
+- Team doesn't know Rust
+- Rewrite is risky
+- Current system works
+```
+
+### Step 2: Identify the Core Insight
+
+What's the strongest kernel of truth?
+
+```markdown
+## Core Insight
+
+Behind "rewrite in Rust" is:
+- Concern about memory-related bugs in production
+- Performance problems that are hard to solve in current language
+- Technical debt making changes slow
+
+The proposal might be wrong, but the concerns are valid.
+```
+
+### Step 3: Construct the Strongest Version
+
+Build the best possible case:
+
+```markdown
+## Steel-Manned Argument
+
+"Our memory-safety issues have caused 3 major outages this year,
+costing us ~$500K in engineering time and customer trust.
+Our performance problems stem from GC pauses that are fundamental
+to our current runtime. While a rewrite is risky, the incremental
+cost of working around these limitations is growing.
+
+A gradual rewrite of performance-critical paths to Rust would:
+- Eliminate a class of bugs (memory safety)
+- Solve GC-related latency issues
+- Attract engineers who want modern tooling
+- Create optionality for high-performance features
+
+The risk can be mitigated by:
+- Starting with one isolated service
+- Keeping the team small and focused
+- Maintaining the old system during transition
+- Having clear rollback criteria"
+```
+
+### Step 4: Address the Steel-Manned Version
+
+Now engage with the strongest argument:
+
+```markdown
+## Response to Steel-Manned Argument
+
+The strongest case for Rust addresses real problems. However:
+
+Memory safety issues:
+- 2 of 3 outages were logic bugs, not memory bugs
+- Could be addressed with better testing in current language
+- Rust learning curve might introduce new bug classes
+
+Performance:
+- GC issues could be addressed with tuning
+- Critical path is <5% of codebase
+- FFI to native code is an option without full rewrite
+
+The 6-month investment in Rust might be better spent:
+- 2 months: Performance profiling and GC tuning
+- 2 months: Targeted native extensions for hot paths
+- 2 months: Improved testing/monitoring
+
+This addresses the concerns with lower risk.
+```
+
+### Step 5: Find the Synthesis
+
+What's the best answer considering both sides?
+
+```markdown
+## Synthesis
+
+The Rust proposal was right about the problems, less right about the solution.
+
+Agreed:
+- Memory safety is a real concern (but smaller than stated)
+- Performance needs improvement (but addressable incrementally)
+- Technical modernization has value (but not at rewrite cost)
+
+Plan:
+1. Address immediate performance with profiling + tuning
+2. Build one small service in Rust as learning experiment
+3. Evaluate Rust for future services based on learnings
+4. Don't rewrite existing system
+
+This takes the best of both positions.
+```
+
+## Steel-Manning Patterns
+
+### In Design Reviews
+
+```markdown
+## Design Review: Microservices Proposal
+
+Weak version to avoid:
+"They just want to use trendy tech"
+
+Steel-manned version:
+"The monolith has become a development bottleneck.
+Deploy conflicts are causing delays. Different teams
+need different scaling characteristics. The proposal
+addresses real coordination problems."
+
+Now address:
+"The coordination problems are real, but can we solve them
+with modular monolith patterns before taking on distributed
+systems complexity?"
+```
+
+### In Code Reviews
+
+```markdown
+## Code Review: Complex Abstraction
+
+Weak critique:
+"This is over-engineered"
+
+Steel-manned understanding:
+"The author anticipated we'll need to support multiple
+backends. This abstraction makes adding new backends
+trivial. The complexity exists to serve future flexibility."
+
+Better critique:
+"I understand this enables multiple backends. Let's
+validate that requirement—if we only ever need one,
+the abstraction adds maintenance burden without benefit."
+```
+
+### In Conflict Resolution
+
+```markdown
+## Team Disagreement: Testing Strategy
+
+Person A: "We need 100% code coverage"
+Person B: "Code coverage is a vanity metric"
+
+Steel-man A:
+"Coverage ensures we think about edge cases and makes
+refactoring safer. Without coverage requirements,
+critical paths go untested."
+
+Steel-man B:
+"Coverage without quality gives false confidence.
+Testing getters/setters wastes time better spent on
+integration tests that catch real bugs."
+
+Synthesis:
+"Coverage is valuable for complex logic, less valuable
+for trivial code. Let's require coverage for business
+logic modules, but focus on integration tests for
+overall system confidence."
+```
+
+### In Self-Critique
+
+```markdown
+## Validating My Own Decision
+
+My decision: Use NoSQL for this project
+
+Steel-man the opposite:
+"SQL has survived 50 years because relational models
+work for most data. NoSQL solves problems most projects
+don't have. The flexibility of schemaless data becomes
+a bug when requirements solidify. Joins are a feature,
+not a limitation."
+
+Now: Does my NoSQL choice survive this critique?
+- Do I actually need schemaless flexibility?
+- Will I regret not having joins?
+- Am I solving a problem I don't have?
+```
+
+## Steel-Manning Red Flags
+
+Signs you're straw-manning instead:
+
+| Straw-Man Sign | Example | Fix |
+|----------------|---------|-----|
+| "They just want..." | "They just want to use new tech" | Find the legitimate concern |
+| Attacking messenger | "They're inexperienced" | Address the argument |
+| Cherry-picking worst example | "Remember when X failed?" | Consider best examples |
+| Assuming bad faith | "They don't care about quality" | Assume they want good outcomes |
+| Ignoring strong points | Skipping their best argument | Address strongest point first |
+
+## Steel-Manning Template
+
+```markdown
+# Steel-Man Analysis: [Topic]
+
+## Original Position
+Who: [Person/group]
+Position: [Their stated view]
+Stated reasons: [Their explicit arguments]
+
+## Apparent Weaknesses
+[What seems wrong at first glance]
+
+## Core Insight
+[The legitimate concern or truth behind the position]
+
+## Steel-Manned Version
+[The strongest possible formulation of their argument]
+
+"[Write it as if you were advocating for this position]"
+
+## My Response to the Strong Version
+[Now address the steel-manned argument]
+
+## What I Learned
+[How did steel-manning change my understanding?]
+
+## Synthesis
+[Best answer considering both positions]
+```
+
+## Verification Checklist
+
+- [ ] Understood the original argument
+- [ ] Identified the core insight/concern
+- [ ] Constructed the strongest possible version
+- [ ] Addressed the strong version, not a weak one
+- [ ] Found what's legitimate in the opposing view
+- [ ] Considered synthesis of positions
+- [ ] Changed my mind if the steel-man is convincing
+
+## Key Questions
+
+- "What's the strongest version of this argument?"
+- "What legitimate concern is behind this?"
+- "Could I argue this position convincingly?"
+- "What would make this position correct?"
+- "Am I attacking the weakest or strongest form?"
+- "If I were advocating for this, what would I say?"
+
+## Rapoport's Rules (Related)
+
+Daniel Dennett, channeling Anatol Rapoport, offers rules for criticizing:
+
+1. Attempt to re-express the target's position so clearly that they say "Thanks, I wish I'd thought of putting it that way."
+2. List any points of agreement (especially if not matters of widespread agreement).
+3. Mention anything you learned from the target.
+4. Only then are you permitted to say so much as a word of rebuttal or criticism.
+
+This is steel-manning as ethical practice.
+
+## Mill's Wisdom
+
+"He who knows only his own side of the case knows little of that."
+
+You don't truly understand your position until you can argue the opposition's best case. Steel-manning isn't weakness—it's the path to strong positions that can withstand strong criticism.

package/.claude/skills/thinking-systems/SKILL.md

@@ -0,0 +1,238 @@
+---
+name: thinking-systems
+description: Use when debugging across services/an incident where a fix in one place breaks another, or behavior is emergent and no single component explains it. Maps the system and traces causes.
+---
+
+# Systems Thinking
+
+## Overview
+Systems thinking views a problem as part of an interconnected whole rather than isolated components. It focuses on relationships, feedback loops, delays, and emergent properties—behaviors that arise from interactions and can't be predicted from parts alone. Its proven payoff is cross-service/incident debugging, where "obvious" single-component fixes fail.
+
+**Core Principle:** The behavior of a system cannot be understood by analyzing components in isolation. Look at connections, feedback, and emergence.
+
+## When to Use
+- Debugging issues that span multiple services/components
+- A fix in one place breaks something in another
+- Behavior is emergent—no single component is at fault, but the whole misbehaves
+- Analyzing incidents and outages with non-obvious causes
+- Performance issues where the slow part isn't the actual cause
+
+```
+Problem spans multiple components?        → yes → APPLY SYSTEMS THINKING
+Fix in one place caused issue in another? → yes → APPLY SYSTEMS THINKING
+Behavior seems "emergent" or unexpected?  → yes → APPLY SYSTEMS THINKING
+```
+
+## When NOT to Use
+- A single-component, linear bug (one service, clear stack trace) → just trace and fix it; the systems overhead buys nothing.
+- The cause is already obvious from the recent diff or one log line → fix directly.
+- The work is a contained refactor or feature with no cross-component interactions → skip.
+
+## Systems Debugging Process
+This is the core of the skill—apply it first.
+
+### Step 1: Map the System
+Draw components, connections, and data/control flows:
+```
+┌─────────┐     ┌─────────┐     ┌─────────┐
+│ Client  │────▶│   API   │────▶│   DB    │
+└─────────┘     └────┬────┘     └─────────┘
+                     │
+                     ▼
+               ┌─────────┐
+               │  Cache  │
+               └─────────┘
+```
+
+### Step 2: Identify Feedback Loops
+For each loop, determine:
+- Is it reinforcing (amplifies change) or balancing (counteracts change)?
+- What's the delay in the loop?
+- What could make it unstable?
+
+```
+Retry Storm Loop (Reinforcing - Dangerous):
+Service slow → Clients retry → More load → Service slower → More retries
+```
+
+### Step 3: Trace Upstream
+Follow the symptom backward to find originating cause:
+```
+Symptom: High latency in Service C
+→ Service C waiting on Service B
+  → Service B waiting on Service A
+    → Service A doing full table scan (ROOT CAUSE)
+```
+
+### Step 4: Look for Interactions
+What happens when components interact under stress?
+- Circuit breakers tripping
+- Cascading timeouts
+- Resource contention
+- Thundering herd
+
+### Step 5: Consider Time Dynamics
+- When did this start?
+- What changed recently (deploys, config, traffic)?
+- Is it periodic? (Cron jobs, cache expiration, batch processes)
+- Is it growing or stabilizing?
+
+## Common System Patterns
+
+### Cascading Failure
+```
+One component fails → Dependent components overload → They fail
+                                                    ↓
+                              ← More traffic to remaining ←
+```
+**Mitigation:** Circuit breakers, bulkheads, graceful degradation
+
+### Thundering Herd
+```
+Cache expires → All requests hit backend simultaneously → Overload
+```
+**Mitigation:** Jittered expiration, cache warming, request coalescing
+
+### Queue Backup
+```
+Processing rate < Arrival rate → Queue grows → Memory pressure → OOM
+```
+**Mitigation:** Backpressure, rate limiting, queue bounds
+
+### Resource Contention
+```
+Multiple processes → Same resource → Lock contention → Serialization
+                                                     ↓
+                    Throughput collapses despite available CPU
+```
+**Mitigation:** Sharding, optimistic locking, resource isolation
+
+## Key Concepts
+
+### 1. Feedback Loops
+
+**Reinforcing (Positive) Loops:** Amplify change
+```
+Technical Debt Loop:
+Deadline pressure → Shortcuts → More bugs → More firefighting 
+                                           ↓
+                            ← Less time for quality ←
+```
+
+**Balancing (Negative) Loops:** Counteract change
+```
+Auto-scaling Loop:
+Load increases → More instances spawn → Load per instance decreases
+                                       ↓
+                    ← Fewer instances needed ←
+```
+
+**Questions to identify loops:**
+- Does this effect feed back into its cause?
+- Is this self-reinforcing or self-correcting?
+- What keeps this system in equilibrium?
+
+### 2. Stocks and Flows
+**Stocks:** Accumulated quantities (users, technical debt, cache size)
+**Flows:** Rates of change (registrations/day, bugs fixed/sprint)
+
+```
+┌─────────────────────────────────────┐
+│  Inflow → [Stock] → Outflow         │
+│                                     │
+│  New bugs → [Bug Backlog] → Fixes   │
+│  Requests → [Queue Depth] → Processed│
+│  Hires → [Team Size] → Attrition    │
+└─────────────────────────────────────┘
+```
+
+**Key insight:** Stocks change slowly even when flows change quickly. Queue depth doesn't drop instantly when you add capacity.
+
+### 3. Delays
+Time lags between cause and effect obscure relationships:
+```
+Code deployed → [Delay: Cache TTL] → Users see change
+Feature shipped → [Delay: Adoption curve] → Metrics change  
+New hire starts → [Delay: Ramp-up] → Productivity impact
+```
+
+**Danger:** Acting before feedback arrives leads to overcorrection.
+
+### 4. Non-Linear Relationships
+Small changes can have large effects (and vice versa):
+```
+Linear assumption: 2x traffic = 2x latency
+Reality: Traffic crosses threshold → 10x latency (queue buildup)
+
+Linear assumption: Adding engineer adds capacity
+Reality: Communication overhead grows O(n²)
+```
+
+### 5. Emergent Properties
+Behaviors that arise from interactions, not individual components:
+- **Distributed system:** No single service is slow, but the system is slow (cascading delays)
+- **Team dynamics:** No individual is toxic, but collaboration is toxic (incentive interactions)
+- **Market behavior:** No actor intends a bubble, but bubble emerges
+
+## Causal Loop Diagram Template
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│                    System: [Name]                            │
+├──────────────────────────────────────────────────────────────┤
+│                                                              │
+│    ┌─────────┐                        ┌─────────┐           │
+│    │ Factor  │──────(+)──────────────▶│ Factor  │           │
+│    │    A    │                        │    B    │           │
+│    └─────────┘                        └────┬────┘           │
+│         ▲                                  │                │
+│         │                                  │                │
+│        (-)                                (+)               │
+│         │                                  │                │
+│         │         ┌─────────┐              │                │
+│         └─────────│ Factor  │◀─────────────┘                │
+│                   │    C    │                               │
+│                   └─────────┘                               │
+│                                                              │
+│   Legend: (+) = same direction, (-) = opposite direction    │
+│   Loop type: Reinforcing / Balancing                        │
+└──────────────────────────────────────────────────────────────┘
+```
+
+## Leverage Points
+Once you've located where to intervene, pick the highest-leverage point you can actually move:
+
+| Leverage | Example | Impact |
+|----------|---------|--------|
+| Parameters | Timeout values | Low |
+| Buffer sizes | Queue limits | Low-Medium |
+| Feedback loops | Add monitoring | Medium |
+| Information flows | Make metrics visible | Medium-High |
+| Rules | Change retry policy | High |
+| Goals | Redefine SLOs | Very High |
+| Paradigm | Rethink architecture | Transformational |
+
+(See `thinking-leverage-points` for Meadows' full 12-level hierarchy.)
+
+## Verification Checklist
+- [ ] Mapped system components and connections
+- [ ] Identified at least one feedback loop
+- [ ] Traced symptom upstream to potential root causes
+- [ ] Considered time delays in the system
+- [ ] Looked for emergent/interaction effects
+- [ ] Identified leverage points for intervention
+- [ ] Considered unintended consequences of fix
+
+## Key Questions
+- "What feeds back into what?"
+- "Where are the delays in this system?"
+- "What happens when this scales 10x?"
+- "What would an observer see vs. what's actually happening?"
+- "If I fix this here, what breaks over there?"
+- "What behavior emerges that no single component intends?"
+- "Where is the smallest change with the largest effect?"
+
+## Meadows' Reminder
+"We can't control systems or figure them out. But we can dance with them."
+
+Systems resist simple fixes. Effective intervention requires understanding the whole, finding leverage points, and accepting that you're influencing, not controlling.