@polderlabs/bizar 10.7.0 → 10.7.2

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

@@ -0,0 +1,192 @@
+---
+name: thinking-debiasing
+description: In a long trajectory where you're defending a path you committed to early, run a pam self-check for sunk-cost and confirmation bias before continuing — only when evidence is being explained away.
+---
+
+# Cognitive Debiasing
+
+> Usually unnecessary. Current models already avoid the textbook cognitive biases on standard framings, so do not run this checklist by default — it adds friction without lift. It earns its keep in one narrow case: a **long trajectory** where you've committed to an approach early and are now rationalizing past it (sunk-cost) or only collecting evidence that confirms it (confirmation). For everything else, skip it.
+
+## Trigger Card
+
+Only use this skill when you notice one of these patterns in a long trajectory where you've committed to a path early:
+
+| Pattern you notice | Self-check |
+|---|---|
+| "We've already built/spent a lot, so we should continue" | **Sunk cost:** Would I choose this path *starting fresh today*, ignoring work already done? If no, change course. |
+| You keep finding support for your current hypothesis and discounting counter-evidence | **Confirmation:** What single piece of evidence would prove me wrong? Have I actively looked for it? |
+| Unusually high confidence with thin evidence | **Overconfidence:** Widen the estimate; state what I'd expect to see if I'm wrong. |
+
+If the check doesn't change the decision, you're done. Don't name biases without acting on them. For risk anticipation, use `thinking-pre-mortem`; for trade-off analysis, use `thinking-opportunity-cost`; for decision speed, use `thinking-reversibility`.
+
+## When NOT to Use
+- Standard, single-step reasoning — the bias risk is already low; don't pad the answer with a bias audit.
+- Short tasks with no prior commitment to defend — sunk-cost/confirmation can't apply yet.
+- As decoration to look rigorous — naming biases without changing the decision is theater.
+- When a concrete framework already fits (thinking-pre-mortem for risks, thinking-opportunity-cost for trade-offs, thinking-reversibility for decision speed) — use it instead.
+
+## Overview
+Based on Daniel Kahneman, Dan Lovallo, and Olivier Sibony's research on cognitive biases. The sections below are a fuller checklist; for an autonomous agent, treat them as a *reference for the narrow case above*, applied as self-checks (not as roles assigned to a team).
+
+## The 12-Point Decision Quality Checklist
+
+Before approving any significant recommendation, evaluate:
+
+### Self-Interest Biases
+**1. Is there self-interest at play?**
+- Does the recommender benefit from this decision?
+- Would they recommend the same if incentives were different?
+- Are there conflicts of interest?
+
+**2. Is there emotional attachment (affect heuristic)?**
+- Has the team fallen in love with the proposal?
+- Are they dismissing concerns too quickly?
+- Is criticism being taken personally?
+
+### Single-Path Lock-In
+**3. Did I genuinely explore alternatives, or anchor on the first one?**
+- Were competing approaches evaluated, or strawmanned?
+- Did I argue the opposing position in good faith before dismissing it?
+- Is there pressure (deadline, prior statement) pushing me to one answer?
+
+**4. Did I anchor on the first framing of the problem?**
+- Would a different starting framing change the conclusion?
+- Did I re-derive the estimate independently, or just adjust the first number I saw?
+
+### Pattern Recognition Errors
+**5. Are we over-relying on a single analogy (saliency bias)?**
+- Is there one "this is just like X" dominating thinking?
+- Have we sought disconfirming analogies?
+- Are we cherry-picking the comparison?
+
+**6. Are we anchored on an initial number?**
+- Where did the first estimate come from?
+- Would a different starting point change the conclusion?
+- Have we re-estimated from scratch?
+
+### Confirmation Bias
+**7. Were credible alternatives seriously considered?**
+- Did we explore at least 2-3 real alternatives?
+- Were alternatives given fair evaluation?
+- Or were they strawmen to justify the preferred option?
+
+**8. Are we seeking confirming evidence only?**
+- What evidence would disprove this thesis?
+- Have we actively looked for disconfirming data?
+- Are we explaining away contradictory evidence?
+
+### Planning Fallacies
+**9. Is the base case realistic?**
+- Is this more optimistic than similar past projects?
+- What's the base rate of success for similar efforts?
+- Have we adjusted for "this time is different" thinking?
+
+**10. Is the worst case bad enough?**
+- Does worst case assume only one thing goes wrong?
+- What if multiple risks materialize simultaneously?
+- Have we considered tail risks?
+
+**11. Are we discounting sunk costs appropriately?**
+- Would we make this decision if starting fresh?
+- Are we continuing because we've "invested too much"?
+- What would an outsider with no history decide?
+
+### Halo Effects
+**12. Are we assuming success transfers?**
+- Are we trusting this team/approach because of past wins?
+- Were past successes in similar contexts?
+- Are we attributing success to skill when luck played a role?
+
+## Quick Debiasing Techniques
+
+### For Anchoring
+- Generate estimate BEFORE seeing others' numbers
+- Ask: "What if the true number is 2x or 0.5x?"
+- Use multiple independent estimators
+
+### For Confirmation Bias
+- Argue the opposite position yourself, in good faith
+- Ask: "What would make this wrong?" and go look for it
+- Weight disconfirming evidence at least as heavily as confirming
+
+### For Overconfidence
+- Widen confidence intervals (usually too narrow)
+- Use reference class forecasting (base rates)
+- Ask: "How often have similar predictions been right?"
+
+### For Sunk Cost
+- Ask: "Would we start this project today knowing what we know?"
+- Ignore past investment when evaluating future returns
+- Consider opportunity cost of continuing
+
+### For Single-Path Lock-In
+- Generate the strongest case for an alternative before settling
+- Steel-man the option you're rejecting
+- Separate "what the evidence says" from "what I already concluded"
+
+## Decision Quality Audit Template
+
+```markdown
+# Decision Quality Audit: [Decision Name]
+
+## Recommendation Summary
+[Brief description]
+
+## Bias Checklist
+
+### Self-Interest & Emotion
+- [ ] Self-interest checked: [Notes]
+- [ ] Emotional attachment assessed: [Notes]
+
+### Single-Path Lock-In
+- [ ] Opposing position argued in good faith: [Notes]
+- [ ] First framing/anchor questioned: [Notes]
+
+### Pattern Recognition
+- [ ] Multiple analogies considered: [Notes]
+- [ ] Anchoring effects checked: [Notes]
+
+### Confirmation Bias
+- [ ] Alternatives genuinely evaluated: [Notes]
+- [ ] Disconfirming evidence sought: [Notes]
+
+### Planning Realism
+- [ ] Base case reality-checked: [Notes]
+- [ ] Worst case severe enough: [Notes]
+- [ ] Sunk costs ignored: [Notes]
+
+### Halo Effects
+- [ ] Success transfer questioned: [Notes]
+
+## Red Flags Identified
+[List any concerns from checklist]
+
+## Mitigations
+[How will identified biases be addressed?]
+
+## Decision
+- [ ] Proceed as recommended
+- [ ] Proceed with modifications
+- [ ] Requires more analysis
+- [ ] Reject recommendation
+```
+
+## Verification Checklist
+- [ ] Confirmed this is the narrow case (long trajectory + a path being defended) — otherwise skip the skill
+- [ ] Ran the matching self-check (sunk-cost / confirmation / overconfidence)
+- [ ] Identified a concrete piece of evidence that would prove the current path wrong
+- [ ] Re-decided as if starting fresh today, ignoring prior investment
+- [ ] The check actually changed (or affirmed for a stated reason) the decision — not just named a bias
+
+## Key Questions
+- "What would have to be true for this to be wrong?"
+- "How confident am I, and what's driving that confidence?"
+- "What would an outsider with fresh eyes conclude?"
+- "Am I reasoning toward a conclusion I already want?"
+- "What's the base rate of success for decisions like this?"
+- "If I'm wrong, how will I know, and when?"
+
+## Kahneman's Warning
+"We can be blind to the obvious, and we are also blind to our blindness."
+
+You cannot debias through willpower alone. Use checklists, processes, and outside perspectives to catch what your intuition misses.

package/.claude/skills/thinking-dual-process/SKILL.md

@@ -0,0 +1,282 @@
+---
+name: thinking-dual-process
+description: Use when an answer arrives too fast on a high-stakes or unfamiliar task. Force one explicit verification pass before committing instead of shipping the first plausible answer.
+---
+
+# Dual-Process Thinking
+
+## Overview
+A language model produces a first answer by fast pattern-completion: the most statistically likely continuation given the prompt. That fast path is excellent for routine, well-trodden tasks and dangerous for high-stakes or unfamiliar ones, where the most *plausible-sounding* answer and the *correct* answer diverge. This skill is the deliberate counterweight: when an answer arrives too easily on a task that matters, force one explicit verification pass before committing.
+
+The framing comes from Kahneman's fast/slow distinction, but the operative idea here is mechanical, not psychological: **fast generation** (the immediate completion) vs. a **deliberate check** (re-deriving, testing, or sourcing the answer).
+
+**Core Principle:** Fluency is not correctness. When the answer came easily *and* the cost of being wrong is high, that combination is the trigger to slow down and verify — not a signal you're done.
+
+## Trigger Card
+
+When an answer arrives instantly on a high-stakes or unfamiliar task, run one verification pass before committing:
+
+1. **Notice:** Did the answer form immediately, with no intermediate steps? High confidence but nothing checked?
+2. **Check triggers:** Is the task high-stakes/irreversible OR the domain unfamiliar? If neither, ship the fast answer.
+3. **Verify:** Re-state the claim → re-derive or test it a second, independent way → check against ground truth (code, docs, data) → reconcile any disagreement → commit.
+
+The trigger is **easy answer + real cost of error.** If the answer was hard-won, you already deliberated. If the task is trivial and reversible, don't over-verify.
+
+## When to Use
+- The task is high-stakes or irreversible (data migration, security, deletion, public commitment) and the answer felt obvious.
+- The domain is unfamiliar or the task is novel — no well-worn pattern to rely on.
+- The answer requires statistical or quantitative reasoning (where fast completion is reliably miscalibrated).
+- You're reviewing work and it "looks fine" on a pam pass.
+- A claim is plausible and convenient but you haven't actually checked it against the code/docs/data.
+
+Decision flow:
+```
+Answer arrived fast? → High stakes OR unfamiliar? → yes → RUN A VERIFICATION PASS
+                                                  ↘ no → fast answer is fine, ship it
+                     ↘ no (had to work for it) → you already deliberated
+```
+
+## When NOT to Use
+- **Routine, reversible, low-stakes tasks.** Renaming a variable, a trivial edit, an obvious lookup — re-verifying everything is wasted budget and invites analysis paralysis.
+- **You already worked through it deliberately.** If the answer was hard-won, a second pass is redundant; the trigger is *easy answer + high stakes*, not every answer.
+- **The verification pass would cost more than the error it prevents.** Match the depth of the check to the cost of being wrong.
+- **You can just run it.** If a test or a pam execution would settle it, do that instead of more reasoning.
+
+## The Two Modes
+
+### Fast generation (the default)
+| Characteristic | Description |
+|----------------|-------------|
+| **Speed** | Immediate — the answer is just the first plausible completion |
+| **Basis** | Pattern-matching to similar prompts seen in training |
+| **Confidence** | Often high *regardless* of correctness — fluency masquerades as certainty |
+
+Fast generation is reliable for:
+- Well-trodden, conventional tasks with a clear standard answer
+- Reformatting, summarizing, and other low-ambiguity transforms
+- Recall of common, stable facts
+- Routine code in a familiar language/framework
+
+Fast generation is unreliable for:
+- Arithmetic and multi-step quantitative reasoning
+- Statistical reasoning and base-rate problems
+- Novel or unfamiliar problems with no template to match
+- Anything where a plausible-sounding answer can be subtly wrong (APIs, version-specific behavior, edge cases)
+
+### Deliberate verification (the override)
+| Characteristic | Description |
+|----------------|-------------|
+| **Speed** | Slower — re-derive, test, or source the answer |
+| **Basis** | Explicit steps, checks against ground truth |
+| **Confidence** | Earned — tied to what was actually verified |
+
+Deliberate verification is worth its cost when:
+- Re-deriving a result a second, independent way
+- Running or tracing the code instead of predicting its output
+- Checking a claim against the actual file/doc/data rather than memory
+- Enumerating edge cases the fast answer glossed over
+
+Its only failure mode is over-use: applying it to trivial, reversible work where the check costs more than the error.
+
+## The Process
+
+### Step 1: Notice the fast answer
+A fast answer announces itself: it's the response forming immediately, before any explicit work. That's normal and usually fine. The thing to notice is *how* you got it.
+
+- Answer formed immediately, no intermediate steps
+- It "obviously" follows from the prompt
+- Confidence is high but nothing was actually checked
+
+```
+Example: "Does this regex match leading zeros?"
+A confident yes/no forms instantly → fast generation.
+Before answering: is this high-stakes or am I sure? If either is shaky, test the regex.
+```
+
+### Step 2: Check the two trigger conditions
+A verification pass is warranted only when BOTH are true enough:
+
+**The answer came easily** (Step 1), AND **the cost of being wrong is real:**
+- Stakes are high or the action is irreversible
+- The domain is unfamiliar or the problem novel
+- It requires arithmetic / statistical reasoning
+- A wrong-but-plausible answer would slip through review
+
+If the answer was hard-won, you already deliberated — stop. If stakes are trivial and reversible, the fast answer is fine — stop.
+
+### Step 3: Run the verification pass
+When both conditions hold, do exactly one disciplined check:
+
+```
+1. RE-STATE  - Write the claim/answer explicitly
+2. RE-DERIVE - Reach it a second, independent way (or test/run it)
+3. CHECK     - Against ground truth: the code, the docs, the data, the math
+4. RECONCILE - If the two paths disagree, the fast answer was wrong — find out why
+5. COMMIT    - Ship the verified answer
+```
+
+Watch for these fast-answer red flags specifically:
+- It's the most common/canonical answer but the prompt has an unusual twist
+- It depends on a version, config, or edge case you didn't actually confirm
+- It's the convenient answer that lets you stop early
+- It restates the user's assumption back to them without testing it
+
+### Step 4: Match effort to stakes
+
+| Situation | Process |
+|-----------|
+| Fast answer + low stakes | Ship it; don't manufacture doubt |
+| Fast answer + high stakes | Run the verification pass above |
+| Already deliberated | Done — no second pass needed |
+
+## Fast-Generation Failure Modes
+
+### Question substitution
+Fast generation answers an easier nearby question instead of the one asked:
+```
+Asked: "Is this O(n) or O(n log n)?"
+Answered: "Does this look like efficient code?"  (vibe, not analysis)
+
+Asked: "Does this migration preserve all rows?"
+Answered: "Does this migration look correct?"  (plausibility, not verification)
+```
+The fix is to re-state the *exact* question (Step 3) so the substitution becomes visible.
+
+### Pattern-matched errors
+
+| Pattern | What it does | When it fails |
+|-----------|--------------|---------------|
+| Canonical-answer pull | Returns the textbook answer | The prompt has a non-standard twist |
+| Base-rate neglect | Reasons from the salient detail | Ignores how common the outcome actually is |
+| Anchoring | Builds on a number in the prompt | The anchor was arbitrary or wrong |
+| Confirmation | Surfaces support for the framing given | Misses evidence the framing is wrong |
+| Sycophantic agreement | Echoes the user's stated assumption | The assumption was the bug |
+
+### WYSIATI (What You See Is All There Is)
+Fast generation builds the most coherent answer from *only* what's in the prompt, and does not flag what's missing:
+```
+Given: "the function returns the user"
+Concludes: "so the happy path works"
+Missing: the 404 path, the timeout, the null case — none mentioned, so none considered
+```
+Coherence of the answer is not coverage of the territory. Explicitly ask "what would I need to look at that isn't in front of me?"
+
+## Fluency Is Not Correctness
+
+A smooth, confident, well-formatted answer *feels* more trustworthy — to the reader and in the generation itself. That fluency signal is independent of whether the answer is right.
+
+| Fluent answer | Verified answer |
+|---|---|
+| Reads cleanly, high apparent confidence | Confidence tied to a specific check that passed |
+| Risk: accepted without scrutiny | Risk: only over-use on trivial tasks |
+
+**The trap:** the more polished the fast answer, the *less* it gets challenged — exactly backwards from what stakes should dictate. On a high-stakes task, treat a too-clean answer as a reason to run the verification pass, not a reason to ship.
+
+## Application Examples
+
+### Code Review
+```
+Fast answer: "This looks fine" (matches familiar-looking code)
+Verification pass (high-stakes change):
+- Trace the actual logic line by line, don't pattern-match the shape
+- Enumerate the edge/error paths the diff doesn't mention
+- Check the change against the contract it must uphold (callers, tests)
+```
+
+### Reporting a Fact or API Behavior
+```
+Fast answer: "Use method X, it takes these args" (canonical recall)
+Verification pass (unfamiliar/version-sensitive):
+- Confirm the method exists in the version in this repo
+- Check the signature in the actual source/docs, not from memory
+- If unsure, say so or look it up rather than assert
+```
+
+### Architecture / Tech Choice
+```
+Fast answer: "Use [the obvious default]" (most-common completion)
+Verification pass (high-stakes):
+- State the actual requirements, then check the default against them
+- Name one alternative and why it loses, so the choice is reasoned not reflexive
+```
+
+### Debugging
+```
+Fast answer: "It's probably X" (first plausible hypothesis)
+Verification pass:
+- List the candidate causes, not just the first
+- Find the evidence that would distinguish them, and look at it
+- Resist committing to X until the logs/repro actually point there
+```
+
+## Integration with Other Thinking Skills
+
+### With Debiasing
+Fast generation is where most bias-shaped errors enter; the verification pass is where you catch them. Run the debiasing checklist as the content of Step 3 on high-stakes calls.
+
+### With Bayesian Reasoning
+Fast answers neglect base rates; the verification pass restores them:
+```
+Fast: "Positive test result = probably has the condition"
+Verified: state the base rate first, then update (see thinking-bayesian)
+```
+
+### With First Principles
+The fast answer reasons by analogy ("everyone does X"); the verification pass asks whether the constraint is real:
+```
+Fast: "Competitors do X, so we should too"
+Verified: "What's the fundamental requirement? Does X actually meet it?"
+```
+
+### With Pre-Mortem
+The fast answer is optimistic by default; the verification pass adds the failure view:
+```
+Fast: "This plan will work"
+Verified: "Assume it failed — what's the most likely reason?"
+```
+
+### With OODA Loop
+Under genuine time pressure (an incident), act on the fast answer at ~70% confidence and re-observe — don't stall on verification. Reserve the full pass for after, or for the irreversible step within the incident.
+
+## When the Fast Answer Is Trustworthy
+
+The fast path is not the enemy — it's correct most of the time, and over-verifying is its own failure. Lean on the fast answer when:
+
+1. **The task is conventional** — a standard transform or a common, stable fact
+2. **The pattern fits cleanly** — no unusual twist in the prompt
+3. **It's cheaply reversible** — a wrong answer is caught and fixed at near-zero cost
+4. **You can confirm it trivially if challenged** — the check is one step away
+
+```
+Fine to ship fast:
+- "Convert this JSON to YAML"
+- "What HTTP status means 'not found'?"
+- A rename or a comment fix
+
+Verify first:
+- "Will this SQL touch every shard?"
+- "Is this auth check actually enforced on the server?"
+- Anything version-, edge-case-, or money-sensitive
+```
+
+Ask: "If this is wrong, how and when do I find out — and how much does it cost?"
+
+## Verification Checklist
+- [ ] Noticed whether the answer arrived fast or was worked through
+- [ ] Checked BOTH triggers: easy answer AND real cost of error
+- [ ] If both true, ran one disciplined verification pass against ground truth
+- [ ] Re-derived or tested the result a second, independent way
+- [ ] Did NOT over-verify a trivial, reversible task
+- [ ] Confirmed version/edge-case-sensitive claims rather than asserting from memory
+- [ ] Matched the depth of the check to the cost of being wrong
+
+## Key Questions
+- "Did this answer come too easily — and does that matter here?"
+- "Is this a conventional task or one with an unusual twist?"
+- "What would a second, independent derivation show?"
+- "Is my confidence tied to an actual check, or just to how clean the answer reads?"
+- "What's missing that isn't in front of me (WYSIATI)?"
+- "If this is wrong, how and when do I find out?"
+
+## The Core Warning
+A fluent, confident answer reflects the coherence of the completion, not the quality of the evidence behind it. The most polished answers get challenged the least — which is exactly backwards when the stakes are high. When an answer comes easily on something that matters, that ease is the trigger to verify, not the signal you're done.