菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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 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.
| name | blind-chestertons-fence |
| description | 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. |
G.K. Chesterton (The Thing, 1929, "The Drift from Domesticity"): a reformer finds a fence across a road and says "I don't see the use of this; let us clear it away." The intelligent reformer answers: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
The blind spot is asymmetric visibility: a thing's cost is visible now; its purpose may only be visible under conditions you haven't seen (the leap-year bug, the one enterprise client, the race that happens under load). "I can't see a reason" is a statement about your visibility, not about the reason.
git log -p --follow the lines, read the commit message, linked issue, PR discussion. Search the tracker for the filename. Ask the author if reachable.| Tell | Move |
|---|---|
| "This does nothing" | git log --follow before delete |
| "Weird workaround, probably cargo cult" | Find the bug it worked around; check if fixed upstream |
| Magic sleep/retry/limit | Reconstruct the failure it absorbs |
| "Nobody knows why this exists" | That's a documentation task AND a removal blocker |