reality-checklisted

Use whenever someone hands you an AI-generated technical plan, recommendation set, setup guide, or tool/config list and says "validate this", "fact-check this", "is this real", "is this accurate", "did it hallucinate", "sanity-check this", "pressure-test this", "is this overkill", or asks whether a plan is feasible and worth doing. Trigger hardest when the content reads as machine-written and is dense with checkable specifics that could be fabricated — repo URLs, CLI flags, file paths, versions, env vars, named "best-practice" patterns, time estimates. The job: pressure-test the thing for hallucinations, factual errors, and unnecessary complexity, then verify every surviving claim against live sources before the user acts on it. Do NOT trigger for a bare dependency question — whether a specific package is real, alive, and maintained is leftpad's registry rung, so "should we add this package" or "is this crate abandoned" goes there. This VERIFIES an existing plan's accuracy and practical value, not choosing be
scoobydrew83/skills · ★ 0 · AI & Automation · score 78

Install: claude install-skill scoobydrew83/skills

# Reality Check Validate AI-generated technical guidance before the user wastes time acting on it. Modern models produce recommendations that are fluent, confident, and structurally perfect — and quietly riddled with invented package names, nonexistent repos, made-up config keys, plausible-but-wrong CLI flags, and "industry-standard patterns" that no one has ever used. On top of that, even the *accurate* parts are often overkill: complexity bolted on for its own sake, reinventing capabilities the user already has. The user's ask is almost always some version of *"is this real, and is it worth doing?"* Answer both. Be brutally honest — a soft, agreeable review is worse than useless here, because the whole point is to catch what the original generator got wrong. ## Core principle: verify, don't vibe The failure mode of this skill is reviewing claims from memory and *sounding* confident. Don't. Memory is exactly what hallucinated a wrong package name in the first place, and your training data goes stale. **For every checkable claim, actually search.** A claim you "recognize" is not a verified claim — version numbers, repo ownership, CLI flags, and tool capabilities all drift. When in doubt, look it up; when a search is cheap and the claim is load-bearing, look it up anyway. ## Workflow ### 1. Frame the artifact and extract discrete claims Identify what you're validating (a plan, a tool list, a config, a step-by-step setup). Then break it into **atomic, individually-checka