reality-check
SolidPressure-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).
Install
Quality Score: 78/100
Skill Content
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
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".
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.
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