bs-check

bs-check: reason it, then prove it

AI bullshits fluently, confidently, and without receipts. This skill checks.

You've seen it. Give Claude a task and it solves exactly that task, even when the real problem is one level up. Hand it a shaky plan and it executes the shaky plan brilliantly, with compliments. It will find any way to do what you asked before it will ever ask whether you should. And when it reports back: "Fixed!" and it isn't. "All tests pass" and they never ran. "That endpoint exists" and it doesn't.

None of that is lying. It's bullshit in the technical sense: fluent, confident, and indifferent to whether it's true or whether it was the right problem to begin with. Claude Code can run commands, query systems, and fetch sources, which means the receipts are always available. bs-check is the skill that makes collecting them mandatory, and that questions the assignment before doing the work.

It audits two things: your thinking and your claims. Two lanes, six modes, handing off to each other:

The handoff is the point. A reasoning audit that surfaces a load-bearing factual claim doesn't get to assert it. It flags it for the verification lane, which goes and checks.

Install

git clone https://github.com/GemSpecter/bs-check.git ~/.claude/skills/bs-check

That is the whole install. Claude Code picks the skill up on your next session. To scope it to one project instead of every project, clone into .claude/skills/bs-check inside that project.

Requirements: Claude Code. The premise, approach, fresh, quick, and direct modes need nothing else. full mode wants a blind web judge and prefers the Perplexity MCP server; without it the skill dispatches a fresh subagent with the built-in WebSearch / WebFetch tools instead, and declares the substitution in its output banner.

Usage

/bs-check premise <decision>
/bs-check approach <decision>
/bs-check fresh <decision>
/bs-check <claim>
/bs-check direct <claim>
/bs-check quick <claim>

What it looks like

Verification defaults to a tight verdict, not a report. Example of a direct run on a claim that did not hold up:

/bs-check direct "the auth fix is deployed to staging"

🛑 BLOCKED - sub-claim #2 (deployed build) at 35%

📡 Direct-Obs mode (4 commands run against live system)

Why: The commit is merged to main, but staging is serving a build from six
days before it landed. Merged is not deployed.

Validate before acting:
1. `ssh staging "docker ps --format '{{.Image}}'"` to confirm the running tag
2. Re-run the deploy pipeline, then re-check

Full breakdown available - say "show full" or write to a file for the audit trail.

A PASS is the same shape with the gate line inverted. Reasoning audits (premise, approach, fresh) never emit a gate; they return a reframe or a proceed.

The modes

Each mode targets a class of unchecked confidence. The examples are single instances, not the scope.

premise: is this the right problem? Treats the problem statement itself as a claim that can be wrong, before any work happens. Example: asked to optimize a function because "the app feels slow," it checks whether the function is the bottleneck at all. It wasn't; a network call was.

approach: is this the right way to solve it? Audits a chosen solution for premature commitment: were real alternatives ever weighed? Example: hand-rolling auth gets compared against the battle-tested library you never considered.

fresh: high stakes, fresh eyes. Runs every pattern in a clean context that never saw your reasoning, because the reasoning that built a plan will defend it. Example: tonight's production migration gets a pre-mortem from an auditor with no investment in the plan.

quick / full / direct: is this claim actually true? Three verification depths: a five-second inline gut check, a cross-judged web-verified audit, or real commands run against your live systems. Example: "the fix is deployed" gets checked against the server, which is still running last week's build.

Natural phrasing routes too: "are we solving the right problem?" reaches premise, "pressure-test this" reaches fresh, "is this actually true?" reaches verification.

Best practices

1. Confident is not correct. Audit reports are articulate whether right or wrong. Don't bank a reasoning-lane conclusion until the verify lane confirms its load-bearing facts.
2. Reason it, then prove it. The reasoning lanes tell you which fact the conclusion hinges on. Run the verify on that fact.
3. Aim it at confident artifacts: finished plans, another model's output, your own settled opinion. Polished is exactly what slips through unquestioned.
4. Let it disagree with you. If it only ever validates your framing, it's broken.
5. fresh is the tiebreaker. Fresh context means agreement is independent confirmation, not an echo.

Design principles

• Context isolation. The fresh auditor and the verification judges never see the reasoning that produced the thing under review. The reasoning that built a decision will defend it.
• Modality shift beats self-critique. Where possible, claims are checked by running commands, not by generating more text about them.
• Lanes don't blend. Reasoning audits end in reframe/proceed; only verification gets to say PASS/BLOCKED. The verification judge scores only. It never generates alternatives, because mixing generation with judging reintroduces the self-preference bias the pipeline exists to kill.
• Earned agreement. "The plan holds" is a legitimate verdict, but it must be earned: the strongest counter-case stated in full, with its specific failure point named. Empty agreement and manufactured objections are both failures; fabricated findings corrode an audit skill's credibility as fast as sycophancy does.

Research foundations

The reasoning protocols implement techniques from public research:

• Socratic-method prompting: Chang 2023 (arXiv:2303.08769)
• Chain-of-Verification: Dhuliawala et al. 2023, Meta AI (arXiv:2309.11495)
• Prompt-pattern catalog: White et al. 2023, Vanderbilt (arXiv:2302.11382)
• Devil's-advocate prompting: Wang et al. 2024, EMNLP (arXiv:2405.16334)
• Pre-mortem analysis: Klein 2007, Harvard Business Review
• Multi-agent verification patterns (context isolation, structural gates): 2024-2026 research on LLM self-preference and verifier design

The protocol text is an original implementation written from the source research. The two-lane architecture, the verification pipeline, the lane rule, and the reasoning-to-verification handoff are original to bs-check.

License

MIT