reality-check

Solid

Pressure-test an AI-generated technical plan, recommendation set, setup guide, or tool/config list for hallucinations, factual errors, and unnecessary complexity, then verify the surviving claims against live sources before the user acts on them. Use whenever the user pastes recommendations, an implementation plan, a tooling/MCP/package list, install commands, or config and says "validate this", "fact-check this", "is this real/accurate", "did it hallucinate", "sanity-check this", "pressure-test this", "is this overkill", or asks whether a plan is feasible and worth doing. Especially trigger when the content looks AI-generated and is dense with checkable specifics (package names, repo URLs, CLI flags, file paths, versions, env vars, named "best-practice" patterns, time estimates) that could be fabricated. This is for VERIFYING the accuracy and practical value of an EXISTING plan, not for choosing between open options or deciding from scratch (use a decision/council skill for that).

AI & Automation 0 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
0
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# 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...

Details

Author
scoobydrew83
Repository
scoobydrew83/skills
Created
1 months ago
Last Updated
today
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Featured

reality-check

Compare a claimed state with observable repository evidence and report concrete gaps. Triggers: "reality check", "what is actually done", "compare claim to repo".

414 Updated today
boshu2
AI & Automation Listed

double-check

Exhaustively validate every claim, number, calculation, code-fact, and command in a document or outbound communication. Extracts all claims into a prioritized ledger (flagging what is NOT covered), validates each by the right method (run the math, run the command, cite the file:line, quote the primary source), then calibrates certainty with CIA Words of Estimative Probability and a provenance tier — and proposes corrected, properly-hedged rewrites for any overclaim. Use before sending a message, filing an issue, committing analysis, or whenever you state exact numbers/assertions others will rely on.

0 Updated 2 days ago
DazzleML
AI & Automation Listed

bs-check

Use before telling a client or stakeholder "this is fixed", before deploying changes to a production site or service, before activating or modifying a live automation/workflow, before claiming an integration works end-to-end, before quoting pricing or API behavior in a comparison, or before running a destructive infrastructure command. Also use when the user says "confidence check", "how confident are you", "validate this", "pressure-test this", "/bs-check", or whenever a confident-sounding claim has not been directly validated by a query, observation, comparison, or quotable source. ALSO covers design-time reasoning audits via subcommands - "bs-check premise" (are we solving the right problem? premise acceptance - Socratic + Steelman), "bs-check approach" (did we commit too fast? - Burden of Proof, Cold Start, Alternatives, Pre-mortem), "bs-check fresh" (all 9 patterns, fresh-context sub-agent). Trigger phrases for those - challenge this, push back, devil's advocate, poke holes, steelman this, are we solving

0 Updated today
GemSpecter