@polderlabs/bizar 10.7.0 → 10.7.2

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

@@ -0,0 +1,195 @@
+---
+name: thinking-inversion
+description: When planning work where optimism may be hiding risks, ask "how would I guarantee this fails?" — enumerate failure paths, then turn the top ones into explicit requirements to avoid.
+---
+
+# Inversion Thinking
+
+> **Redirect:** For most risk-anticipation work, prefer `thinking-pre-mortem` — it produces a narrative prospective-hindsight pass that surfaces richer, more specific failure causes than a generic checklist. Use inversion only as a pam failure-mode enumeration on a scoped feature/design; for full plans, launches, or strategic decisions, pre-mortem is the stronger tool.
+
+## Trigger Card
+
+When planning a scoped feature or design where optimism may be hiding risks:
+
+1. **State the goal clearly.**
+2. **Ask: "How would I guarantee this fails?"** — list 10+ concrete failure paths.
+3. **Convert the top 3-5 into explicit avoidance requirements.** (e.g., "No plaintext passwords" → "Use bcrypt with work factor ≥ 12")
+4. **Verify the plan addresses each.**
+
+Skip if the task is small/reversible or if failure modes are already well-covered by existing checks. For full plans or launches, use `thinking-pre-mortem` instead.
+
+## Overview
+Inversion thinking, championed by Charlie Munger and rooted in mathematician Carl Jacobi's principle "Invert, always invert," approaches problems by considering their opposite. Instead of asking "How do I succeed?", ask "How would I guarantee failure?" then avoid those paths.
+
+**Core Principle:** "All I want to know is where I'm going to die, so I'll never go there." — Charlie Munger
+
+## When to Use
+- Planning a new project, feature, or initiative
+- Evaluating a decision before committing
+- Identifying risks that optimistic thinking obscures
+- Stuck on how to achieve a positive outcome
+- Need to challenge assumptions in a plan
+- Writing requirements or acceptance criteria
+
+Decision flow:
+```
+Have a goal? → yes → Can you list ways to achieve it? → maybe → INVERT FIRST
+                                                      ↘ no → Definitely invert
+           ↘ no → Define goal, then invert
+```
+
+## When NOT to Use
+
+- **You're planning a full launch, project, or strategic decision.** Use `thinking-pre-mortem` instead — it produces a narrative prospective-hindsight pass that surfaces richer, more specific failure causes than a checklist enumeration. Inversion is the lighter, faster tool; pre-mortem is the deeper one.
+- The task is small/reversible and failure is cheap — just do it and fix forward.
+- You'd only produce generic boilerplate failure modes ("no tests", "poor naming") that don't apply here; skip if nothing specific surfaces.
+- The failure modes are already well-covered by existing checks (CI, lint, type system); don't re-enumerate what's enforced.
+
+## The Process
+
+### Step 1: Define the Goal Clearly
+State what success looks like:
+```
+Goal: "Ship a reliable authentication system by Q2"
+Goal: "Build a high-performing engineering team"
+Goal: "Launch product with strong user retention"
+```
+
+### Step 2: Invert — Ask "How Would I Fail?"
+List all ways to guarantee failure, ruin, or the opposite of your goal:
+
+```
+Goal: Ship reliable auth system
+Inversions (How to guarantee failure):
+- Skip security review and pen testing
+- No rate limiting or brute force protection  
+- Store passwords in plaintext
+- No monitoring or alerting
+- Skip edge cases in testing
+- No documentation for on-call
+- Single point of failure, no redundancy
+- Ignore compliance requirements
+- No rollback plan
+- Deploy on Friday before vacation
+```
+
+### Step 3: Categorize the Failure Modes
+Group by type and severity:
+
+| Category | Failure Mode | Severity |
+|----------|--------------|----------|
+| Security | Plaintext passwords | Critical |
+| Security | No rate limiting | High |
+| Operations | No monitoring | High |
+| Operations | No rollback plan | High |
+| Process | Skip security review | Critical |
+| Process | No documentation | Medium |
+| Reliability | Single point of failure | High |
+
+### Step 4: Convert to Avoidance Checklist
+Transform each failure mode into a requirement:
+
+```
+Anti-goal: Store passwords in plaintext
+→ Requirement: Use bcrypt/argon2 with appropriate work factor
+
+Anti-goal: No rate limiting
+→ Requirement: Implement rate limiting with exponential backoff
+
+Anti-goal: Deploy Friday before vacation
+→ Requirement: No deploys within 48h of team unavailability
+```
+
+### Step 5: Prioritize by Impact
+Focus on avoiding the failures that would be:
+- Most damaging if they occurred
+- Most likely to occur without explicit prevention
+- Hardest to recover from
+
+## Application Patterns
+
+### For Technical Design
+```
+Goal: Build scalable API
+Invert: How to make it fail under load?
+- No caching → Add caching layer
+- Synchronous everything → Add async where appropriate  
+- No connection pooling → Implement pooling
+- N+1 queries → Eager loading, query optimization
+- No circuit breakers → Add circuit breakers
+```
+
+### For Code Review
+```
+Goal: Merge high-quality code
+Invert: What would make this PR problematic?
+- Introduces security vulnerability
+- Breaks existing functionality
+- No tests for new behavior
+- Unclear intent/poor naming
+- Performance regression
+- Missing error handling
+```
+
+### For Career/Team Building
+```
+Goal: Build successful engineering career
+Invert (Munger's list of what to avoid):
+- Be unreliable
+- Learn only from your own mistakes (ignore others')
+- Give up after first failure
+- Be resentful and envious
+- Stay within comfort zone
+- Avoid difficult conversations
+- Don't learn continuously
+```
+
+### For Project Planning
+```
+Goal: Successful product launch
+Invert: How to guarantee launch failure?
+- No user research → Validate with users
+- No load testing → Load test before launch
+- No rollback capability → Build rollback
+- No success metrics defined → Define metrics upfront
+- Team burnout → Sustainable pace
+- No communication plan → Prepare stakeholder comms
+```
+
+## Combining with Pre-Mortem
+Inversion + Pre-Mortem creates powerful risk identification:
+
+1. **Inversion**: List ways the project could fail (theoretical)
+2. **Pre-Mortem**: Imagine it DID fail, explain why (narrative)
+3. **Synthesize**: Combine both lists, prioritize, mitigate
+
+## Common Inversions for Software
+
+| Domain | Goal | Key Inversions to Avoid |
+|--------|------|------------------------|
+| Security | Secure system | Trusting user input, weak auth, exposed secrets |
+| Performance | Fast system | No caching, blocking calls, no indexes |
+| Reliability | Stable system | No monitoring, no redundancy, no graceful degradation |
+| Maintainability | Clean code | No tests, cryptic names, tight coupling |
+| Team | High performance | Poor communication, no psychological safety, unclear goals |
+
+## Verification Checklist
+- [ ] Goal clearly defined
+- [ ] Listed 10+ ways to fail/achieve opposite
+- [ ] Categorized failures by type and severity
+- [ ] Converted top failures to explicit requirements
+- [ ] Verified plan addresses the most critical inversions
+- [ ] Re-checked the top inversions against the actual design for blind spots
+
+## Key Questions
+- "What would guarantee failure here?"
+- "What mistakes do others commonly make?"
+- "What am I most likely to overlook?"
+- "If this fails spectacularly, what will the postmortem say?"
+- "What would I tell someone else to avoid?"
+- "What would the opposite of success look like, specifically?"
+
+## Munger's Warning
+"It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent."
+
+The power of inversion is in avoiding obvious errors that optimism blinds us to. Simple avoidance often beats clever optimization.

package/.claude/skills/thinking-jobs-to-be-done/SKILL.md

@@ -0,0 +1,363 @@
+---
+name: thinking-jobs-to-be-done
+description: Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
+---
+
+# Jobs to Be Done
+
+## Overview
+
+Jobs to Be Done (JTBD), developed by Clayton Christensen, reframes product thinking around the progress customers are trying to make in their lives. People don't buy products; they "hire" products to do a job. Understanding the job reveals what you're really competing against and what success looks like.
+
+**Core Principle:** People don't want a quarter-inch drill. They don't even want a quarter-inch hole. They want to hang a picture of their family.
+
+## When to Use
+
+- Product development and roadmapping
+- Feature prioritization
+- User research and interviews
+- Competitive analysis
+- Market positioning
+- Understanding "surprising" competitors
+- Debugging low adoption of features
+
+Decision flow:
+
+```
+Building/improving a product?
+  → Do you understand the job users hire it for? → no → DISCOVER THE JOB
+  → Are features not being adopted? → yes → CHECK JOB ALIGNMENT
+  → Surprising competitors winning? → yes → IDENTIFY THEIR JOB
+```
+
+## When NOT to Use
+
+- **Skip for execution and infrastructure problems.** If the task is "fix this bug," "make this query faster," "design this schema," "wire up CI" — the job is already known and the work is technical. JTBD adds nothing; route to debugging, theory-of-constraints, or architecture skills instead.
+- **Skip when the job is already well-established** and the open question is purely *how* to build it, not *whether/why*.
+- **Don't use it to retro-justify** a feature decision already made — that's framework theater. Use it before prioritization, to change the decision.
+
+## Trigger Card
+
+When deciding what to build or why a feature isn't adopted:
+
+1. **Identify the job** — what progress is the user trying to make in a specific situation? Frame it as "When [situation], I want to [progress]."
+2. **Map competing solutions** — what do users currently hire to get this job done? Include non-software alternatives.
+3. **Find the underserved job dimension** — where do current solutions fall short? Build for that gap.
+
+Skip if the job is already well-established and the question is purely how to build it. Don't use to retro-justify a decision already made.
+
+## Understanding Jobs
+
+### The Job Formula
+
+```
+When I [situation/trigger]
+I want to [motivation/progress]
+So I can [desired outcome/better state]
+```
+
+**Example:**
+```
+When I [finish a project milestone]
+I want to [notify my team without disrupting their focus]
+So I can [maintain team awareness while respecting their time]
+
+Job: "Keep team informed asynchronously"
+Not: "Use Slack" (that's a solution, not the job)
+```
+
+### Job Dimensions
+
+Every job has multiple dimensions:
+
+| Dimension | Question | Example (Project Management Tool) |
+|-----------|----------|-----------------------------------|
+| Functional | What task needs doing? | Track tasks, assign work, see progress |
+| Emotional | How do I want to feel? | In control, not overwhelmed, confident |
+| Social | How do I want to appear? | Organized, reliable, professional |
+
+### Job Context
+
+Jobs are situation-specific:
+
+```
+Same person, different jobs:
+
+Morning: "Help me triage what needs attention today"
+         → Simple dashboard, prioritized list
+
+Deep work: "Get out of my way, let me focus"
+           → Minimal notifications, distraction-free
+
+End of day: "Help me hand off cleanly so I can disconnect"
+            → Status summary, async update capabilities
+```
+
+## The JTBD Discovery Process
+
+### Step 1: Identify Job Performers
+
+Who is "hiring" your product?
+
+```markdown
+## Job Performers
+
+Primary: Engineering managers
+- Hire product for: tracking team delivery
+- Frequency: daily
+- Stakes: team performance visible to leadership
+
+Secondary: Individual engineers
+- Hire product for: knowing what to work on next
+- Frequency: multiple times daily
+- Stakes: personal productivity and recognition
+```
+
+### Step 2: Derive the Job From Available Artifacts
+
+You usually can't run live user interviews. Instead, **reconstruct the job from the evidence already in front of you** — the PRD, tickets, support transcripts, analytics, and the code itself. Read these and answer the interview questions *from the artifacts*:
+
+```markdown
+## JTBD Evidence Sources (in priority order)
+
+1. PRD / spec / design doc
+   - What problem statement and "success" definition does it state?
+   - What user motivation is asserted (and is it backed by evidence)?
+
+2. Tickets / issues / support threads / sales notes
+   - What trigger made the user reach for this? ("When I…")
+   - What did they try before / complain about? (the switch + the pain)
+   - Recurring phrasings = the real job, in the user's words
+
+3. Usage / analytics / logs
+   - Where do users actually go, and where do they drop off?
+   - Which flows get repeated (real job) vs. abandoned (stated but not real)?
+
+4. The code / config itself
+   - What does the feature actually let a user accomplish today?
+
+Then answer, from that evidence — NOT from a hypothetical interview:
+- Trigger: what situation makes them reach for this?
+- Progress sought: what better state are they after?
+- Switch: what were they using before, and what was wrong with it?
+- Done signal: how do they know the job is finished?
+
+If the artifacts genuinely don't answer these, name the gap explicitly and
+flag that user research is needed — do NOT invent quotes or fabricate a
+persona to fill it.
+```
+
+### Step 3: Analyze Competing Solutions
+
+What else could do this job?
+
+```markdown
+## Competition for "Keep team informed on project status"
+
+Direct competitors:
+- Other project management tools (Asana, Monday.com)
+
+Indirect competitors (same job, different solution):
+- Email updates
+- Slack messages
+- Weekly standup meetings
+- Walking over to someone's desk
+- Spreadsheets
+
+Non-consumption:
+- Just hope everyone knows
+- Let things fall through cracks
+
+Insight: We're not competing with other tools—we're competing
+        with "just send an email" and "bring it up in standup"
+```
+
+### Step 4: Map Job Steps
+
+Break the job into stages:
+
+```markdown
+## Job Map: "Deliver working software on time"
+
+1. Define: Understand what needs to be built
+   - Sub-jobs: Clarify requirements, estimate scope, identify risks
+
+2. Plan: Organize how to build it
+   - Sub-jobs: Break into tasks, sequence work, allocate resources
+
+3. Execute: Build the thing
+   - Sub-jobs: Track progress, remove blockers, adjust course
+
+4. Validate: Confirm it works
+   - Sub-jobs: Test, get feedback, verify acceptance criteria
+
+5. Deliver: Get it to users
+   - Sub-jobs: Deploy, communicate, monitor
+
+Pain points cluster around: #2 (scope conflicts) and #3 (blocker visibility)
+```
+
+### Step 5: Identify Outcome Metrics
+
+What does success look like for the job?
+
+```markdown
+## Desired Outcomes: "Deliver working software on time"
+
+Minimize:
+- Time spent on status reporting
+- Surprises in sprint reviews
+- Blocked time waiting for others
+- Rework from misunderstood requirements
+
+Maximize:
+- Confidence in delivery timeline
+- Clarity on priorities
+- Team awareness of blockers
+- Early warning of issues
+```
+
+## JTBD Application Patterns
+
+### Feature Prioritization
+
+```markdown
+## Feature Evaluation: Job Lens
+
+Feature: Advanced reporting dashboard
+
+Job it serves: "Demonstrate team value to leadership"
+Job performers: ~10% of users (managers reporting up)
+Job frequency: Monthly
+Alternative solutions: Screenshots + slides (works fine)
+
+Verdict: Low priority - job is infrequent, alternatives adequate
+
+---
+
+Feature: Blocker visibility alerts
+
+Job it serves: "Remove obstacles before they delay delivery"
+Job performers: ~60% of users (anyone managing work)
+Job frequency: Daily
+Alternative solutions: Manual check-ins (time-consuming, often missed)
+
+Verdict: High priority - frequent job, poor alternatives
+```
+
+### Competitive Analysis
+
+```markdown
+## Competitive Analysis via JTBD
+
+Our product: Developer documentation tool
+
+Traditional competitive frame:
+- Competitors: ReadMe, GitBook, Docusaurus
+- Differentiation: Features, pricing, integrations
+
+JTBD competitive frame:
+Job: "Help developers integrate our API successfully"
+
+Competitors for this job:
+- Our own code examples (strongest competitor!)
+- Stack Overflow answers
+- Competitor's documentation
+- Direct support from our team
+- Just trying stuff until it works
+
+Insight: Improving code examples in docs might beat any feature work
+```
+
+### Low Adoption Debugging
+
+```markdown
+## Why isn't Feature X being used?
+
+Feature: Automated weekly report generation
+Usage: 3% of target users
+
+JTBD analysis:
+Expected job: "Create status reports efficiently"
+Actual job: "Demonstrate my judgment and insight to leadership"
+
+Problem: Automated reports don't show judgment
+         The PROCESS of creating reports is part of the job
+         They want to curate, not automate
+
+Solution: Change from "generate report" to "draft report for review"
+          Support the curation job, don't replace it
+```
+
+## JTBD Template
+
+```markdown
+# Jobs to Be Done Analysis: [Product/Feature]
+
+## Job Performers
+| Performer | Hire For | Frequency | Stakes |
+|-----------|----------|-----------|--------|
+| | | | |
+
+## Primary Job
+
+When I [situation/trigger]
+I want to [motivation/progress]
+So I can [desired outcome]
+
+### Job Dimensions
+- Functional: [What task]
+- Emotional: [How feel]
+- Social: [How appear]
+
+## Job Map
+1. [Stage]: [Sub-jobs]
+2. [Stage]: [Sub-jobs]
+...
+
+## Competing Solutions
+| Competitor | How it does the job | Where it falls short |
+|------------|---------------------|---------------------|
+| | | |
+
+## Desired Outcomes
+Minimize:
+- [Negative outcome]
+
+Maximize:
+- [Positive outcome]
+
+## Implications
+- Feature should: [Insight]
+- Feature shouldn't: [Insight]
+- Position against: [True competitor]
+```
+
+## Verification Checklist
+
+- [ ] Identified job performers (who hires the product)
+- [ ] Articulated job in When/Want/So format
+- [ ] Considered functional, emotional, and social dimensions
+- [ ] Mapped job steps
+- [ ] Identified all competing solutions (including non-consumption)
+- [ ] Defined measurable desired outcomes
+- [ ] Features traced to specific jobs
+
+## Key Questions
+
+- "What job is the user hiring this product to do?"
+- "What progress are they trying to make?"
+- "What are they switching from? (Including 'nothing')"
+- "What are they giving up by using this?"
+- "What does success look like for this job?"
+- "What surprising competitors exist for this job?"
+
+## Christensen's Wisdom
+
+"People don't want a quarter-inch drill bit. They want a quarter-inch hole."
+
+Actually: They want to hang a picture. Actually: They want to enjoy their family photos. The deeper you go, the more insight you get into what "better" really means.
+
+"The jobs that arise in people's lives are the fundamental causal driver behind everything."
+
+Products don't fail because of features. They fail because they don't help people make progress on jobs they care about. Understand the job, and the features become obvious.