blind-skills

Use when tempted to say "I'm being objective", when attributing others' views to bias while trusting your own introspection, or after learning about a bias and concluding it doesn't apply to you. Applies Pronin, Lin & Ross (2002) — the bias blind spot and the introspection illusion.

Use when stating confidence ("I'm sure", "definitely", "99%"), giving confidence intervals, making probabilistic claims, or reviewing a track record of predictions. Applies overconfidence calibration research (Lichtenstein & Fischhoff; Alpert & Raiffa) — subjective certainty systematically exceeds accuracy.

Use before deleting code, removing a check, simplifying a process, dropping a config flag, or removing anything that "serves no purpose" — especially in unfamiliar or legacy systems. Applies Chesterton's Fence (G.K. Chesterton, 1929): don't remove it until you know why it's there.

Use when evidence seems to confirm an existing belief, when research keeps agreeing with the hypothesis, when interpreting ambiguous data, or when a first explanation feels satisfying. Applies Lord, Lepper & Preston (1984) — the one debiasing instruction shown to work: consider the opposite.

Use when writing docs, error messages, onboarding, tutorials, API designs, UX copy, or teaching — or when something you built seems self-explanatory. Applies the curse of knowledge (Camerer, Loewenstein & Weber 1989; Newton's tappers-and-listeners 1990): expertise makes you unable to simulate not-knowing.

Use when operating in an unfamiliar domain, when something "looks right" but hasn't been verified, when confidence is high without external checks, or when evaluating one's own competence at a task. Applies Kruger & Dunning (1999) — the skills needed to perform are the skills needed to judge performance.

Use when testing a hypothesis, debugging, validating a fix, designing experiments or test suites, or when checks keep passing. Applies Popper's falsification and Wason's 2-4-6 task — a test that can't fail isn't a test, and confirming instances prove little.

Use when a problem is stuck when approached directly, when defining success criteria, when designing for reliability/safety, or when a goal is vague ("make it good"). Applies Jacobi's inversion as practiced by Charlie Munger — solve problems backward: avoid the failure instead of chasing the success.

Use when assessing self-knowledge, team dynamics, personal strengths/weaknesses, "how do others see this", or when someone is confident about themselves without external input. Applies the Johari Window (Luft & Ingham, 1955) to locate what others see that you cannot.

Use when a conclusion feels obvious, when debugging why two people see the same facts differently, when "clearly" or "obviously" appears in reasoning, or when tracing how a belief was formed from raw data. Applies Chris Argyris's Ladder of Inference.

Use when making any estimate, forecast, deadline, budget, or "how long will this take" judgment, or when a plan's success case is built from its own specifics. Applies Kahneman & Lovallo's outside view / reference class forecasting against the planning fallacy.

Use before committing to a plan, launch, migration, deploy, estimate, or architecture — especially when the team is confident and aligned. Applies Gary Klein's premortem (prospective hindsight): assume the plan already failed, then explain why.

Use when a group or a single reasoner has reached consensus quickly, when reviewing a plan everyone likes, when unanimous agreement appears, or when security/robustness of a design must be tested. Applies institutionalized dissent — red teaming, devil's advocacy, and Israel's post-1973 "Ipcha Mistabra" unit (the real version of the pop-culture "tenth man rule").

Use when the user invokes /blind (full sweep of all frameworks against the current context) or /blind quick (routed 2-4 framework pass), asks "what am I missing", "what are my blind spots", "poke holes in this", "what could go wrong", or before committing to a plan, decision, architecture, launch, or estimate. Dispatcher that runs a structured blind-spot audit using the companion blind-* framework skills.

Use when disagreeing with a position, dismissing an alternative approach, writing a comparison or decision record, or when an opposing view seems obviously wrong. Applies steelmanning and Bryan Caplan's Ideological Turing Test — you understand a position only when its holders would accept your statement of it.

Use when analyzing metrics, user feedback, success stories, benchmarks, churn, error logs, or any dataset — before drawing conclusions. Applies Abraham Wald's WWII bomber insight: the data you have was filtered by a survival process, and the filter is the finding.

Use when scoping a project, entering an unfamiliar domain, writing a risk register, estimating novel work, or when a plan lists only risks the planner already thought of. Applies the knowledge matrix (known/unknown × known/unknown) from 1960s aerospace risk practice, popularized via Rumsfeld 2002.